patches for custom styleelements, kcapacitybar

[Maksim Orlovich]

Sorry for delay, had a bunch of TA responsibilities and was too exhausted
to think stuff through.

> however, you can have this support for as few or many element types as you
> wish (as it could turn out a custom widget makes use of case dependent
> subcontrols, having CC would be pretty nice)
> just for kcapacitybar, it would be complete overhead - yes.

The simpler the better. The CC_/CE_/PE_ split is one of the reasons that
styles are such a mess.

> my first attempt was (considered) more "hackish" but is rather solid as
> well and includes passing widgets with adjusted objectnames instead of a
> KStyleOptionCustomElement (if you don't worry about this, an upgraded
> kstyle
> patch is attached)
> if then an application really uses this stylehint alongside a widget named
> PE_whatever and it will get an unexpected stylehint: selber schuld ;-P

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

This would be very clean, and avoid any risks.

>> And if you do that, then you can get rid of typo-prone string-based API
>> in
> the first place.
> if you get rid of the typo-prone string-based API, you'll be either stuck
> with
> 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.

>
>> Anyway, the addSupportFor method should return the ID; returning a
>> single
> yes, wasn't happy either. renamed the function now returning the value.

Thanks.

> check (#define'ing function prototypes is hopefully ok, otherwise you're
> free
> to multiply the code yourself - i'm soooo lazy ;-P

It's ugly and not needed if you do the sensible thing and simplify.


> (i hope "id = ++d->element_counter[KStylePrivate::PrimitiveElement]" is
> ok?
> c'mon, that's not too complex + the code got simpler in that area anyway
> ;-)

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

Thanks,
Maks