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

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

Qt also provides native looks for Windows and MS X users. I don't think
they will not cry ;). Also there are Plastique and CleanLooks styles.

Wednesday 28 June 2006 23:47, Remi Villatel wrote:
The question is: Who will cry if we lose the Windows95 (c)(TM)(R) and
Motif styles provided by Qt? I won't
I'd miss the motif style, and I'd miss the platinum style even more.

Friday 30 June 2006 15:37, Gary L. Greene Jr. wrote:
Friday 30 June 2006 15:39, Boudewijn Rempt wrote:
Wednesday 28 June 2006 23:47, Remi Villatel wrote:
The question is: Who will cry if we lose the Windows95 (c)(TM)(R)
and Motif styles provided by Qt? I won't

I'd miss the motif style, and I'd miss the platinum style even
more.

And yes, I would miss the Windows looking one.

Jumping in late Why the heck do we want to dump QStyle anyway? The
central philosophy of QStyle is that you theme widget elements, not the
widgets themselves. KDE widgets should be painting themselves with
these elements. There will undoubtedly be some special widgets that
can't, but they aren't sufficient excuse to make a QStyle-incompatible
KStyle. In an ideal world, we wouldn't even need KStyle.

David Johnson wrote:

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

I'd miss the motif style, and I'd miss the platinum style even
more.

>And yes, I would miss the Windows looking one.

Jumping in late Why the heck do we want to dump QStyle anyway? The
central philosophy of QStyle is that you theme widget elements, not the
widgets themselves. KDE widgets should be painting themselves with
these elements. There will undoubtedly be some special widgets that
can't, but they aren't sufficient excuse to make a QStyle-incompatible
KStyle. In an ideal world, we wouldn't even need KStyle.

LL! Please everybody, stop overreacting. We were only thinking out
loud. Nobody has even started to touch KStyle sources. :-)

Especially, I was thinking out loud as a style developer. In a perfect
world for me, we'd have a clearly defined central place to intercept all
the drawings.

In this not-so-perfect world, fighting against hardcoded colors
and hardcoded drawings would be a good enough step in the right
direction. A place where we can intercept all the drawings already
exists, it's the event filter. Although it requires a lot of work,
that's enough for the control maniacs like me.

There's already enough work to do on the widgets themselves. We
shouldn't need to touch KStyle unless there's nothing else to do to
make style coding easier.

Everybody seems to forget it but that's why KStyle exists. Here's a
comment extracted from "kstyle.h":

* Simplifies and extends the QStyle API to make style coding easier.

Moving the (current) drawing of the KDE specific widgets like
KColorButton, KColorCombo, KKeyButton, KPopupTitle maybe some
other ones-- wouldn't make any difference for KDE/Qt but a big
difference for the style developers. That's what I was thinking of
before to start daydreaming about what *I* would like.