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

List:       kwin
Subject:    Re: [Kwin] KWin brekage: client_popup removal
From:       Lubos Lunak <l.lunak () sh ! cvut ! cz>
Date:       2002-09-03 12:47:12
[Download RAW message or body]

On Tuesday 03 September 2002 14:36, Karol Szwed wrote:
> On Tuesday 03 September 2002 10:07 pm, Cristian Tibirna wrote:
> [snip]
>
> >I believe the right way to fix this is to revert the popup_client patch,
> > fix the apps/situations where popup_client mechanism doesn't satisfy, and
> > _finally_ write an explanatory note about this design choice.
>
> There's also the small issue of not being able to cleanly implement
> double-click to close on menu buttons anymore with this patch afaik.

 And the problem is? I didn't notice any.

>
> >Hey! What about the following? Put a moratory on kwin code until after
> > KDE-3.1 (with extensions as needed) and thus getting some time to write
> > down a DESIGN paper note. I know about a (very few) of KWin's internals.
> > Matthias knows more. Let's put all this knowledge in written. And finally
> > have a solid base for discussion before major architectural changes.

 This could probably start with an explanation of the client_popup vs 
active_client madness. I really don't know what to do with it now (besides 
reverting my change, but that won't fix everything).

>
> It sounds like a very good idea - the only problem is that it can get quite
> messy documenting all the little quirks that are worked around, and the
> document probably won't be that non-technical either. How in-depth should
> this paper be? A broad overview probably won't help anyone much.
>
> Perhaps we should look at this from a different perspective:
> 1. Document kwin's internals with more liberal comments. (One could argue
> that the code is mostly self-documenting though)
> 2. Anything that's confusing/we don't understand should be brought up and
>    discussed on this list, and after coming to an agreement, becomes
>    documented in the code or otherwise.
> 3. Have a document outlining all workarounds and reasoning (eg java
>     workaround).
>
> >(This will even eventually drive us towards a Kwin v.3, with a goal in
> > code file modularity and clean-up).
>
> It would be nice if this document contaned some planned additions /
> modifications so we know where kwin should head in future. First thing I
> would do for v.3 is a full NetWM audit in kwin imho.

 I'm considering adding full NETWM support and making KDE work flawlessly with 
at least one other WM to the KDE3.2 TODO list. It would make rejecting all 
those crazy feature requests easier. I just didn't find the courage to 
actually do the commit ;).

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/



_______________________________________________
Kwin mailing list
Kwin@mail.kde.org
http://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]