Re: [EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

[Tapani Pälli <tapani palli nokia com>]

ext Mark Tiefenbruck wrote:
> Nathaniel Smith wrote:
>   
>> Umm, Tuomo, wtf.  AFAICT in regards to _EFFECT vs. override-redirect,
>> you're arguing *against* having clients provide fine-grained
>> information to the WM (i.e., letting the WM distinguish between "I am
>> a legacy override-redirect window, which could have any number of
>> intended semantics" and "I am *this sort* of override-redirect
>> window").  This approach gives the WM strictly more ability to make
>> intelligent and flexible policy decisions.  What you would prefer is
>> to take away that information, and then to handle the use case stated,
>> you want the spec to impose the one policy (!) that should be used for
>> o-r windows in all cases.  And this is in the name of abstraction and
>> fostering alternatives?  I don't get it.
>>     
>
> I agree with you entirely, though some points have been made (or
> almost made, at least) that should not be ignored. The window manager
> should not be concerned with override-redirect windows at all, and
> these composite manager features really have no business in the
> wm-spec. Composite managers should have their own spec.
>
> For that matter, why are window managers being made with composite
> managers built in, anyway? The world would be a much better place if
>   

I believe this is because they both need same information (stacking,
window types etc.) and this is quite a lot of code to duplicate in 2
processes. Also some people might say it's more efficient
performance-wise to have them in one process... however I'm not very
convinced of that argument as it adds more blocking functions which
means that WM operations have to take more time (unless multiple threads).

> people could choose composite effects independently from the window
> manager (you wouldn't believe how often I get asked "can I use fluxbox
> in beryl/compiz?"). With that goal in mind, what information is the
> composite manager relying on that it can't get from EWMH? Making this
> information available should be our primary focus, IMO.
>
>   Mark
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>   

// Tapani