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

List:       kde-devel
Subject:    Re: Qt4 Themes
From:       Sandro Giessl <sandro () giessl ! com>
Date:       2006-06-28 12:17:42
Message-ID: 200606281417.43288.sandro () giessl ! com
[Download RAW message or body]

On Wednesday 28 June 2006 11:17, Luciano Montanaro wrote:
> On Wednesday 28 June 2006 06:12, Remi Villatel wrote:
> > Sandro Giessl wrote:
> > > BTW: KStyle is still work-in-progress. E.g., some widgets still need to
> > > be implemented and there is not too much code which depends on it yet.
> > > Thus, I guess we are interested in and open for input from other style
> > > devs.
>
> Oops! I almost missed this message, it has been marked as spam by my
> provider. I have just picked it out of the trash! Bleah! :)
>
> > I'm developing Serenity style and I'm interested in porting it to
> > Qt4/KDE4 of course but I'm waiting for the man in the middle: KDE4.
> >
> > Any way, here is my list to Santa...  ;-)

I mostly agree that the things you listed are valid problems, I experienced 
most them, too... who hasn't ever used things like qt_cast<> and similar 
hacks in order to special-case some widget drawing just because things like 
PE_HeaderSection got abused?

Would you be interested in getting yourself an SVN account and "scratching a 
bit your itch"? ;) We style devs should then plan something everyone would be 
satisfied with, and do something about it...

> > One thing that must absolutely disappear from KDE is all the
> > QDrawShadeThingies and --worst-- the fact that some widgets draw
> > themselves mimicking this look. We're in the 21st century, ain't we?
> >
> > In fact, all drawings should be transmitted from the widgets to the
> > style. For this, the KStylePrimitive enum and KStyle can be extended to
> > all widgets that don't directly use Qt primitives. Eventually, adding
> > some KStyleControlElements and KStyleComplexControls should be
> > considered. I think that makes sense.
>
> I agree completely. Do you have a list of widgets that need work?
> I fixed the Color selector some time ago, what is still missing? The color
> button?

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.

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

> 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)".
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]