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@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
