kwin clients - virtual colorsSupported()?

Lubos Lunak l.lunak at suse.cz
Thu Nov 29 13:20:04 GMT 2007


On Tuesday 27 of November 2007, Matthew Woehlke wrote:
> Lubos Lunak wrote:
> >  There would be a flag saying whether the client supports announcing it
> > at all. If it's not set, do whatever should be the (backwards-compatible)
> > default.
>
> ...which means that we need a wrapper API if other programs (i.e. the
> kcm) are going to have a nice way to query the client. IOW, I would much
> prefer 2a to this, the only caveat of course being B(I)C.

 I don't think there are any special needs for nice API that would be used in 
only one place. Besides, with supports(), there's not anything particularly 
ugly:

 KDecorationFactory* factory = getDecorationFactory( kwin_client_name );
 if( !factory->supports( KDecoration::AbilityAnnounceColors ))
     return whatever_the_default_should_be;
 QList< ColorType > supported;
 foreach( ColorType color, all_colors )
    if( factory->supports( colortype_to_ability[ color ] ))
        supported << color;

 You can even go with "static_cast< KDecoration::Ability >( color - DIFF )" if 
you'd be too lazy to write the conversion table, but that's more ugly :).

On Tuesday 27 of November 2007, Matthew Woehlke wrote:
> Lubos Lunak wrote:
> >  I would actually prefer 1, since that's exactly what supports() was
> > designed for and should be the one place for it. But I don't insist.
>
> I would prefer 1 also, except that you:
> = have to change all clients else have broken stuffs

 I think making all clients announce what they support (if there's no 
reasonable default that'd work with current styles) is not a big deal.

> ...or...
> = have an "understands 'supports(Color*)'" ability, and either:
>    - have a wrapper function to hide that from callers, or
>    - have to check both in callers

 I don't know what you mean here - is this what I wrote above?

> ...or do I miss something? If you're OK with changing all clients, then
> I'm OK with 1.

 Note that it seems I've managed to move KCommonDecoration out of the way, so 
it should be possible again to add new virtuals to KDecoration by subclassing 
and adding them there. That is, there should be no need to hurry and add 
anything now just because of BIC.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz




More information about the kde-core-devel mailing list