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

List:       kde-devel
Subject:    Re: Qt4 Themes
From:       Remi Villatel <maxilys () tele2 ! fr>
Date:       2006-06-28 21:47:17
Message-ID: 44A2F8E5.9080306 () tele2 ! fr
[Download RAW message or body]

Sandro Giessl wrote:

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

I would be really happy to have an SVN account but right now all I would 
do would be "scratching my itches" within KDE 3.5.x to try to fix what's 
fixable without breaking everything. Before to work on KDE4, we 
--somebody-- must decide which road we're gonna take.

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

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

The question is: Who will cry if we lose the Windows95 (c)(TM)(R) and 
Motif styles provided by Qt? I won't...

> 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 think you're wrong. What would be the point in having KStyle if 
nothing depends on it? They are (a few) widgets drawn only by KStyle. 
What would be the Control Center without KPE_ListViewExpander or KMix 
without KPE_Slider*?

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

Good question!

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

(a) isn't that bad --except the hardcoded painting part. It just need to 
handle a few more widgets to ease the work of the style developers and 
as a way to add new widgets.

(b) is good and ambitious. KStyle4 could be a layer above Qt to handle 
all the drawings. That would leave us with only one way to draw widgets: 
the KDE way. That's can be that bad. The problem as Thomas says (later 
in this thread) is that we have to patch Qt.

(b) By the way, I was talking about KStyleControlElements and 
KStyleComplexControls just because I thought that some widgets were too 
complex to be called "primitive elements".

I think we can stick with solution (a) until Qt5/KDE5 so we won't have 
to break more things than what's already broken by Qt4.

>> QStyle has the advantage of documentation, at 
>> least.

This isn't a problem. We just need to tie a few people to their 
keyboards and we'll have our documentation too.  ;-)

-- 
==================
Remi Villatel
maxilys_@_tele2.fr
==================
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]