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

List:       kwin
Subject:    Re: BoxSwitch Effect extended by a Flip 3D mode
From:       Cristian Tibirna <tibirna () kde ! org>
Date:       2008-01-24 21:21:29
Message-ID: 200801241621.34107.tibirna () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


First and foremost, I managed to configure my (meager) laptop for kwin 
composition and I must say I was blown away. Lubos, you and your helping 
hands deserve a prize for the most impressive and most disciplined and 
structured advancement of KDE technologies towards 4. Congratulations and a 
huge THANK YOU!

Le Thursday, 24 January 2008, Lubos Lunak a écrit :
> On Thursday 24 of January 2008, Martin Graesslin wrote:
> > Am Montag, 21. Januar 2008 schrieb Lubos Lunak:
> > > Hmm, this is yet another case of conflicting effects. I think we should
> > > have API for temporary claiming some functionality, like Compiz has
> > > (they call it 'grab'). I can't think of a good name, but let's call it
> > > just grab().
> > >
> > >  Does that look ok? Any better ideas?
> >
> > I think that would work. Although I think it could become a real problem
> > if KDE has a lot more effects than now. It will become very difficult to
> > know which effects do not work together and than there would be lots of
> > grab() and ungrab() parts.
>
>  But is there a better solution? 

I believe that escalating the solving of potential conflicts to a 
preprocessing/management stage would do it.

While testing "Explosion" and "Fall apart" effects, I was puzzled by their 
very similar functionality (?) and their potential conflict.

I also noticed the (healthy) tendency towards a (still non-formal) grouping of 
effects.

I believe that rendering grouping of plugins mandatory and reflected in the 
base class(es) API, would allow for kwin to manage activation/deactivation of 
plugins belonging to a same mandatory group in a mutually exclusive manner.

Examples of "natural" mandatory groups:
- effects for window appearence (fade in, zoom in, fly in etc.);
- effects for window closing (fade out, zoom out, fly out etc.);
- effects for focus keyboard switching ("alt-tab");
- etc.

Of course, groups should be imposed by convention and configurable at runtime 
(kwin start) by text config files.

Provision of a "non-conflicting" group would perhaps be handy (although I fail 
to see for what -- but only because of my ignorance);

Sorry for providing just words and no code (yet).

Thanks again


-- 
Cristian Tibirna
KDE developer .. tibirna@kde.org .. http://www.kde.org

["signature.asc" (application/pgp-signature)]

_______________________________________________
Kwin mailing list
Kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin


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