Version: SVN (using Devel) OS: Linux KMyMoney uses a KPageWidget as it's main widget to display the application's different views. We have started using KPageWidget since porting to KDE4 back in the KDE3 days we where using KJanusWidget. After porting to KDE4 we needed somehow to accommodate our custom header widget with KPageWidget. Since KPageWidget doesn't suport changing it's header widget we worked around this by hiding the header of KPageWidget (first by setting the header title to "" then by overwriting KPageVie::showPageHeader) and adding our custom heade at the top of all the application's views. I'd say this solution is working well in almost all the situations. The only case when this solution is causing troubles is while page switching. This is because while switching the header is shown for a brief period and if the page switch takes a while due to loading some data this results in the application's view bouncing - first it goes down to accommodate the header then it goes up again as the header is being hidden by the KPageWidget. Another side effect is that when the application view is at it's minimum vertical size the showing then hiding of the header increases the main window's size (by the height of the header). This means trouble on small screen devices like netbooks. We have an ugly workaround for this (remove the KPageWidget header from the layout manually) but the cleanest solution would be that KPageWidget would allow setting it's header widget. This would also solve the now quirky way of hiding the header. Reproducible: Always Steps to Reproduce: Run KMyMoney from extragear/office and switch from the home view to the ledger view. Actual Results: The application view down then up. Expected Results: A smooth transition without the movement is expected.
You can checkout BUG 257761 to see the ugly workaround that we'll use in KMyMoney to fix this.
Could you summarize the reasons why you need a custom header in the first place? I would prefer adding missing features, instead of allowing a custom header.
Do we need a reason for wanting a custom header? Well the only one I have is that KMyMoney had a custom header before it was using KPageWidget and I wouldn't want to remove it just because KPageWidget can't handle it. And as I've said it is possible already to use a custom header but in a hackish way. That's what this wish is for to support it in a straight forward way in the future. Isn't allowing a custom header a "missing feature"?
> Do we need a reason for wanting a custom header? Yes, please. I have no intention to support custom widgets without knowing the reason. Supporting custom sub widgets is always a nightmare, because you have to be prepared for all kinds of (mis)behavior the widget shows. Additionally, the feature could potentially be useful for other applications, so I really prefer to add missing features instead. For example, if you need the custom header only for aesthetics, why not let other applications share the improvement?
(In reply to comment #4) > > Do we need a reason for wanting a custom header? > > Yes, please. I have no intention to support custom widgets without knowing the > reason. Supporting custom sub widgets is always a nightmare, because you have > to be prepared for all kinds of (mis)behavior the widget shows. Sorry but I'm starting to not understand what you are saying. Didn't I just said that we need the custom header because we already have it? Isn't that a reason? > Additionally, the feature could potentially be useful for other applications, > so I really prefer to add missing features instead. For example, if you need > the custom header only for aesthetics, why not let other applications share the > improvement? That why I made this a whish list item so that other applications could benefit from the possibility to set a custom header. If it's not needed just drop this one, I was just trying to be constructive. Yes we need it just for aesthetics but I don't think other application would like to use the *same* header style as KMyMoney since that's the whole idea of it: to give the application a unique look.
> > to be prepared for all kinds of (mis)behavior the widget shows. > > Sorry but I'm starting to not understand what you are saying. Let me explain. KPageView uses a KTitleWidget for the header, and uses its functions to set the text and icon. I am pretty sure when you are speaking of a custom widget, you are not talking about a class derived from KTitleWidget, but any QWidget. Now if you allow this, people start using all its features, like mouse handling, etc. and you cannot be sure the application handles text/icon changes properly. > the whole idea of it: to give the application a unique look The idea of predefined widgets in a toolkit is to give applications a common look and feel, but I understand that this is old-fashioned thinking (newer toolkits such as QML don't even have predefined widgets). See also http://www.osnews.com/story/24218/ One correct way to implement a customizable header would be to implement some kind of delegate, which has sizeHint() and paint() methods. Another possible way would be to allow styles to implement the KTitleWidget rendering (frame, background, icon and text placement, etc.) using the KStyle extension mechanism. Then you could change header appearance using a proxy style overriding only the KTitleWidget related elements. A third way would be some setHeaderStyleSheet() method that the page widget passes to the header widget. I keep this wish open with these ideas in mind, waiting for other opinions.
It's now possible to hide the header, see https://phabricator.kde.org/D15099