oxygen vs kstyle

[Kevin Ottens]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130821/875ad930/attachment.sig>