[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Qt4 Themes
From:       Luciano Montanaro <mikelima () cirulla ! net>
Date:       2006-06-28 13:07:57
Message-ID: 200606281507.57177.mikelima () cirulla ! net
[Download RAW message or body]

On Wednesday 28 June 2006 14:17, Sandro Giessl wrote:

>
> Hm... I see a major problem: As soon as we do use things like
> KStyleControlElements and KStyleComplexControls, KDE can't use pure
> QStyle styles anymore.
> At the moment (as far as I can see), no KDE widget/application does
> depend on KStyle, and instead only the QStyle API is used.

I don't think we should depend on a KStyle. 
The way I fixed in XYSelector was to use the QStyle Api to find a suitable 
border instead of using the hard-coded qt function to draw embossed 
borders. - this way, a style can still change the look of the widget 
border. 

I think this could cover many cases, but it may not work everywhere. I think 
that if KDE specific primitives are needed, the widget should be able to 
check if the style knows about them [maybe with style->inherit("KStyle") ], 
and if not, draw the elements itself. This could be done with some helper 
function in the kdeui library - like a drawFancyPE() that tries to use the 
style and if it is missing, does the work on its own. 

We should also consider the case where Qt applications want to use KDE 
widgets, and there is no guarantee a KStyle is always loaded. 

>
> > The other problem is many applications assume borders have a certain
> > (small) size. For the highcontrast style, this is a problem because the
> > border can be made quite thicker than usual.
> >
> > By the way: pixelMetric() should be a quick method to call, if we want
> > it used pervasively. But current KStyle pixelMetrics is used to convert
> > the Qt enum to its own enum, and call another function.
>
> I can't imagine that speed is a problem here, since KStyle4 metric values
> are stored and accessed in a relatively fast two dimensional QVector.
> Anyway, no matter how KStyle will look in KDE 4, IMHO we are talking
> about a "detail" of the KStyle4-helper-class (wrapping switches to other
> switches to make style coding easier). Although I like the current
> solution, I do not absolutely stick to it. I'm merely happy that there is
> something decent I can work with. But me, not having an extremely strong
> vision about the class, might be happy with something different if it
> gets concrete.... dunno.

Well, to access the vector, it first calls a function... but where is it 
said that pixel metrics are fixed in stone? for example, the pixel metrics 
for the checkmark (or any of the icon-like elements) could be dependant on 
the widget text size. With a lookup table this will not work.

>
> > I'd just reserve a range of metrics values for KDE use, and use the
> > original method everywhere.
>
> But this discussion triggered a question which I think is much more
> important: Should KStyle4 be a (a) helper-wrapper-class, or should we (b)
> introduce an extended style API for KDE4 widgets/apps to style their
> look?
>
> (a) is what we had in KDE3 and what's on the way with KStyle4 currently.
> It doesn't make it possible to e.g. add new widget types. Everything
> either needs to use the QStyle API for painting, use a different theming
> system, or do hardcoded painting...
>
> (b) might be able to solve this. The downside is that these KDE apps
> won't be able to use QStyles anymore because the special
> KStyleControlElements and KStyleComplexControls won't be implemented
> there.
>
> > QStyle has the advantage of documentation, at
> > least.
> >
> > As an aside, there is also the famous issue of the mythical "user
> > interface guidelines". At least part of it can and should be
> > implemented in KStyle. I think the right time to have a look at them
> > would be now.
>
> Aren't these guidelines more high-level? At least I can't think of a rule
> which could be implemented/encouraged by KStyle.
> I can only think of a HIG-style relation as e.g. what Aaron Seigo
> suggested somewhere, like a rule "Splitter handles should not draw their
> own borders" (to avoid 'double' borders - from splitter and the aligning
> widget which have own borders)".
>

I don't know - I have yet to read this famous HIG. But I remember Aaron 
writing of "HIG compliant" styles, so I imagined at least part of the HIG 
could be implemented in a base class for KDE styles.
  

> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >> unsubscribe <<

-- 
./.. ../ /./. .. ./ /. ///   // /// /. / ./ /. ./ ./. /// ././. //
                                                            \\ //
                                             www.cirulla.net \x/
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]