Hello, On Wednesday 21 August 2013 10:41:06 Hugo Pereira Da Costa wrote: > On 08/20/2013 10:31 PM, Kevin Ottens wrote: > > My understanding of the current situation is that: > > a) the current KStyle is overengineered and does way too much; > > yes. > > > b) we need a KStyle to enforce some of the user settings consistently > > across> > > the styles we produce (it's actually more important than before as some of > > the stuff we controlled on the widget side will be controlled on the > > style side now). > > true.
Pfew! I'm not on crack! ;-) > > So I think the best thing to do there is to severely trim down KStyle. I'd > > propose we copy KStyle as it is now into KDE4Support under the name > > K4Style. And then we empty KStyle as much as possible I really see the > > need for it to only have reimplemented: polish/unpolish, styleHint, > > eventFilter (likely different code than the current one though) and > > *maybe* a few pixelMetrics and standardIcons. All the rest looks to me as > > overkill which makes style developers life miserable anyway. > > I agree this could work. > pixelMetrics I'm unsure but in any case as long as these are just > re-implementation of the base class methods, this can always be bypassed > downstream. so no objection. Exactly. > standardicons, works for me (in fact I copied the kstyle code unchanged > when I switched to QCommonStyle). Right. > What we really should avoid (and what kstyle does right now) is to > define new methods (new API) for drawing stuff, that use different > arguments, different enumerations, etc. and call QCommonStyle > internally, in the sake of making things easier because truth is, they > just make things harder to debug. (one example is the attempt at > simplifying Tabbar drawing in kstyle, which simply fails). Yep, it's really insane right now. I think all of that should go away. > Concerning event filter, it must really be kept minimal. Oxygen already > has its own, implemented on some types of widgets, and I can easily > imagine conflicts between the two. (merging one class event filter with > its parent's filter is not trivial, if you want everything to behave as > expected, iirc) Well, so far going for eventFilter in KStyle is really the last measure when we don't have a way to do things differently. So it'll be as small as we can... > > Does it sound acceptable to you? If yes we can start on our side, and once > > trimmed down I'd like a review from you to see if anything still makes > > your life more complicated than necessary as a style developer. > > Sounds like a plan. I can review the the diffs, make oxygen re-derive > from kstyle instead of QCommonStyle locally, and look for regressions if > any. Excellent, I added the corresponding tasks at the end of the clean up page: http://community.kde.org/Frameworks/Epics/kdelibs_cleanups Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
