Summary: | KPageWidget problems when using a custom header | ||
---|---|---|---|
Product: | [Frameworks and Libraries] kdelibs | Reporter: | Cristian Oneț <onet.cristian> |
Component: | kdeui | Assignee: | kdelibs bugs <kdelibs-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | wishlist | CC: | cfeck |
Priority: | NOR | ||
Version: | SVN | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Cristian Oneț
2010-11-24 09:26:24 UTC
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 |