oxygen vs kstyle

[Hugo Pereira Da Costa]

On 08/20/2013 10:31 PM, Kevin Ottens wrote:
> Hello,
>
> On Tuesday 20 August 2013 21:27:52 Hugo Pereira Da Costa wrote:
>> There is some traffic on the frameworks list concerning implementing new
>> features in kstyle.
>> It might be useful to mention that the current oxygen code (KDE's
>> default widget style) derives from QCommonStyle and not kstyle, so that
>> none of the modifications to KStyle will be available to oxygen, as it
>> is now.
> Yep, heard about that.
>   
>> The switch from KStyle to QCommonStyle happened a couple of years ago
>> and was motivated by the fact that the extra complexity added by
>> deriving from kstyle was higher than the benefit oxygen would get out of
>> it (complexity being: a lot of method re-implemented, as well as a lot
>> of enumerations, some workaround in kstyle that where obsolete and
>> unmaintained, and quite some code duplication). This switch resulted in
>> about 30% less code with no loss of functionality, and an easier code to
>> read and debug (if only by having one less class to track in the
>> dependency tree).
>>
>> Suggestions about where to go from this situation are welcome.

Hi Kevin,

> 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.
>
> 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.

standardicons, works for me (in fact I copied the kstyle code unchanged 
when I switched to QCommonStyle).

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).

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)

> 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.

Best,

Hugo

> Regards.
>
>
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130821/65e9f744/attachment-0001.html>