[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-07-17 14:08:47
Message-ID: 200707171608.47244.l.lunak () suse ! cz
[Download RAW message or body]


 Sorry for ignoring this thread, it's somehow gotten repeatedly off my radar.

On Monday 25 of June 2007, Philip Falkner wrote:
> On Monday 04 June 2007 11:51:26 Lubos Lunak wrote:
> > On Sunday 03 of June 2007, Philip Falkner wrote:
> > > 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 :-/ ?
>
> I'm not happy with the quality of the animation itself, but the fact of the
> animation is a workaround for a different problem.  With the previous code,
> if you have tons of windows and alt-tab, the windows shrink and shrink and
> shrink.  Eventually they'll get too small to see.  An upper bound on the
> number shown would keep them visible, but what do you do when you have more
> windows than the upper bound?

 I see. Ok.

> >  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).
>
> In a sense, the tabbox already has a non-optional filtering mechanism,
> dealing with modal windows and such.  What if we allow effects to add to
> that?
>
> I'm thinking that effects could have a "filtering function"
> (effects->windowListFilter?).  Tabbox::createClient/DesktopList() then
> calls that function, passing a QList; effects deal with the list as they
> like.  The final QList is returned to the tabbox, which would only then
> call
> windowListChanged(), etc.
>
> This would mean each effect (and the non-composited tabbox) that wanted
> as-you-type filtering would have to implement it independently, though.

 Hmm, I don't quite like this, but I have no better idea at the moment.

> > > 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.
>
> ~Deleted() deletes effectWindow(), but then ~Toplevel() is called, which
> calls discardWindowPixmap(), which calls addDamageFull(), which calls
> windowDamaged() with effectWindow() which, at this point, is deleted but
> not NULL.  In theory, it should be set to NULL in ~Deleted(), but
> effect_window is private to Toplevel.

 I see. But there still is a bug in the patch - ~Toplevel() should not always 
delete effect_window, because it's passed to Deleted but it's not reset in 
the original object - this means the original object would delete an object 
that it passed to Deleted.

> If the way I wrote it doesn't appeal, we could make effect_window
> protected; then ~Deleted() could set it NULL no problem.

 That's seems ok. I'd probably only make a protected deleteEffectWindow() 
instead of making the data itself protected, just in case.

> By the way, almost unrelated, is there any practical reason why effects
> shouldn't use KConfigXT vs. the KConfig stuff in EffectsHandler?

 No. The only practical reason why there's no KConfigXt in KWin anywhere is 
that nobody has put it yet there. I'm not aware of any reasons against.

-- 
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]