Re: [EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

["Mark Tiefenbruck" <mark fluxbox org>]

Tuomo Valkonen wrote:
> The model I propose, where override-redirect windows are not messed
> with by the compositing manager unless additional information is
> available, is precisely one where the information at the highest
> level is abstract, but more fine-grained hints may be provided.
> But what the folks here want is that apps must always provide
> the high-specific EWMH information for the CM to not arbitrarily
> mess with their override-redirect windows.

While I agree with you from an engineering standpoint, it's just not
that simple. User expectations do, in fact, trump design simplicity.
The vast majority of override-redirect windows should be managed
windows or child windows, but they're not, and we can't do anything
about that. We can add text to the relevant specs, but it will be
years before it's hard to find apps not following it. I think we
should do that, but we need another solution in the meantime.

Nathaniel Smith wrote:
> The problem is... which composite effects are you talking about?

Well, not to say wobbly windows and a cube-shaped desktop aren't
incredibly useful, but they're not exactly what I had in mind.

> Wobbly windows, so WMs should start exposing "estimated velocity of
> window movement" via EWMH-hints?

Surely the CM can do this itself by noting the position of the window.

> Windows on the face of a see-through cube, so we need
> to start exposing "3d geometry of virtual desktop layout" through
> EWMH, I guess as some kind of triangle-mesh?

I haven't thought about this one thoroughly, but I'm not sure the WM
needs to know how the CM is displaying its workspaces/viewports. There
might need to be some interaction with the window dragging, but this
is already under discussion in the VMWare thread. Perhaps something
useful will come out of it.

> I don't think it makes sense to draw a bright line and say WMs and CMs
> are different, and always shall be.  (And more to the point, I don't
> think it's a spec like EWMH's job to draw that line.)  Compositing is
> really just another primitive in our display model; if the WM is the
> best place to use that primitive to achieve certain effects, then so
> be it.

I'm not saying they have to be separate, but I think they can be, and
we would have a lot to gain if they were. Or at least somebody who
wrote a good one should expect to gain a lot of attention. And I think
it is this spec's job to make that interaction possible.

Also, I think the "if the WM is the best place ... then so be it"
attitude is wrong-headed. It reminds me of certain apps that think
they should be managing their own windows. We're aiming for
standardization and compatibility here, so a feature can be shared
without everybody implementing it themselves.

  Mark