<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 08/20/2013 10:31 PM, Kevin Ottens
      wrote:<br>
    </div>
    <blockquote cite="mid:1638150.zC6Lx9lW7l@wintermute" type="cite">
      <pre wrap="">Hello,

On Tuesday 20 August 2013 21:27:52 Hugo Pereira Da Costa wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
Yep, heard about that.
 
</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
    </blockquote>
    <br>
    Hi Kevin,<br>
    <br>
    <blockquote cite="mid:1638150.zC6Lx9lW7l@wintermute" type="cite">
      <pre wrap="">
My understanding of the current situation is that:
 a) the current KStyle is overengineered and does way too much;</pre>
    </blockquote>
    yes. <br>
    <blockquote cite="mid:1638150.zC6Lx9lW7l@wintermute" type="cite">
      <pre wrap="">
 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).</pre>
    </blockquote>
    true.<br>
    <blockquote cite="mid:1638150.zC6Lx9lW7l@wintermute" type="cite">
      <pre wrap="">

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.
</pre>
    </blockquote>
    I agree this could work. <br>
    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.<br>
    <br>
    standardicons, works for me (in fact I copied the kstyle code
    unchanged when I switched to QCommonStyle).<br>
    <br>
    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).<br>
    <br>
    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)<br>
    <br>
    <blockquote cite="mid:1638150.zC6Lx9lW7l@wintermute" type="cite">
      <pre wrap="">
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.
</pre>
    </blockquote>
    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. <br>
    <br>
    Best,<br>
    <br>
    Hugo<br>
    <br>
    <blockquote cite="mid:1638150.zC6Lx9lW7l@wintermute" type="cite">
      <pre wrap="">
Regards.
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Kde-frameworks-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kde-frameworks-devel@kde.org">Kde-frameworks-devel@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/kde-frameworks-devel">https://mail.kde.org/mailman/listinfo/kde-frameworks-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>