patches for custom styleelements, kcapacitybar

[Thomas Lübking]

Am Thursday 16 October 2008 schrieb Maksim Orlovich:
> Sorry for delay, had a bunch of TA responsibilities and was too exhausted
> to think stuff through.
Nevermind - took me some time as well this time...
Attached are new attempt patches. (The oxygen patch is still nothing but a 
proof of concept)
I found one typo and some copy & paste bugs

> The simpler the better. The CC_/CE_/PE_ split is one of the reasons that
> styles are such a mess.
ok, simpler version: SH, CE, SE - this covers the complete functionality (i.e. 
it's possible to have the style layout multielement items like comboboxes) and 
if you don't need extended features, you can just drop them (didn't choose CC
to avoid widgets having to use QStyleOptionComplex - thus not being able to 
make use of many prefabbed optiontypes)

> May be the best solution would be to use Qt's MOC functionality to mark
> the style as supporting the functionality, e.g. something like
> Q_CLASSINFO("X-KDE-CustomProps", true).
yupp, cool idea. (i assume this would not have impact on the binary 
compatibility for the existing KDE styles? or is there no "fixed ABI" policy 
for them?)
I however still rely on the widget objectName usage (though less weired) to 
cover the "custom app falsely calls our stylehint and crashes on invalid 
styleoption usage" situation

> > elements predefined in KStyle (what i wanted to avoid) or depend on
> > silent number agreements, what's imho little more prone than strings.

> There is no reason for anything a KDE application uses not to have the
> element defined in KStyle.
i don't mind adding elements to the KStyle enums, but i'd like this to be 
rather flexible (especially for 3rd party apps and plain qt apps. also this way 
we can prevent bloating kstyle with dead enums in case an element won't be 
accepted by style developers or users because the only using app is hardly 
used)

> It's ugly and not needed if you do the sensible thing and simplify.
now simplified... to some degree. (and so the #defs are gone)

on being ugly:
why not just choose a nicer color for preproc statements (scnr :-P)

> No, it's not OK for any code I am responsible for. It has 2 side-effects
> in a single line.
grummelgrummjajaja.... ok.

Just for the records: /I/ want to stress that /personally/, /I/ find 

j = ++i;

much easier to read than 

++i; 
j = i;

Well, i guess that won't help me too much here ;-)

<ffwd>
>> Well, i guess that won't help me too much here ;-)
> No.
I knew you'd say that..
</ffwd>

> Thanks,
Thanks back,
for input, help and assistance on improving my code quality

Thomas






-------------- next part --------------
A non-text attachment was scrubbed...
Name: customelements.kstyle.diff
Type: text/x-patch
Size: 9109 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20081021/1979d9aa/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: customelements.kcapacitybar.diff
Type: text/x-patch
Size: 1976 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20081021/1979d9aa/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: customelements.oxygen.diff
Type: text/x-patch
Size: 1255 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20081021/1979d9aa/attachment-0002.bin>