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

List:       kwin
Subject:    Re: Updates to effects
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2007-06-04 15:51:26
Message-ID: 200706041751.26815.l.lunak () suse ! cz
[Download RAW message or body]

On Sunday 03 of June 2007, Philip Falkner wrote:
> Sorry for the long silence.
>
> I have some patches I'd like some input on.
>
> First, is an updated BoxSwitch.  It's one lump patch right now, but I'd
> separate it out before committing.

 Just in case you have it already split into smaller patches and combined it 
together only for this mail, then please don't.  Smaller patches are much 
easier to read.

> I've added some features like animation, following color settings, etc.

 I'm not quite sure I like the animation. IMHO it makes finding a window to 
select harder. But Compiz has it too, doesn't it? Hmm ... config option :-/ ?
 
> But the real meat, is an updated 
> api for effects replacing the tabbox.  It's a bit more verbose, but covers
> I think what most replacements would want to do.  I also think it can be
> extended to allow for new tabbox modes without disturbing existing effects.

 Ok. There's one more thing related to this I'd like to handle somehow: 
Currently DesktopPresentEffect has the nice window filtering feature that got 
quite some people drooling, but I don't think it really belongs there. I see 
no reason why Alt+Tab shouldn't be able to do the same, even in the 
non-composited mode. The same way DesktopPresentEffect should probably also 
be able to, among other things, to go forward/backward in the focus chain. 
It'd be nice to share this functionality. Do you have any idea how feasible 
this would be? If I'm getting it right with your tabbox API it is tabbox.cpp 
that decides many things and I wonder if that wouldn't be too limiting for 
the effects (although I admit I don't completely understand the API).

> It doesn't substantially change how the tabbox itself works.  Also, the
> changes to toplevel.cpp and deleted.cpp are simply to stop kwin from
> sending windowDamaged events for windows whose effectWindows have been
> deleted.

 I don't understand this, and the change seems to be wrong. The EffectWindow 
object is passed from the original window to Deleted and only Deleted 
eventually destroys it.

 Also, note that "delete point_that_is_null;" is valid, so there's no need to 
check the pointer for validity.

> Second is a new Fade.  Unashamedly taken from the compiz fade, it can now
> fade between any changes in opacity/saturation/brightness.  That is, it can
> handle fading for other effects.  The question I have is, do we want this? 
> It gives us a single place for the user decide whether they want things
> fading in and out, and how quickly.  On the other hand, maybe effects are
> better off with different speeds for different purposes, e.g. should the
> fade in PresentWindows be able to be a different speed than the fade in
> DialogParent? I think the centralised way is better, but I'm open to being
> told that's wrong. :)

 I think only practice will tell. Let's give it a try :).

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@suse.cz , l.lunak@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
_______________________________________________
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]