Window stacking

[Michal Suchanek]

On 16 September 2011 11:18, Giovanni Campagna <scampa.giovanni at gmail.com> wrote:
>

>> Sorry, I also assume any "task manager" will just be part of the
>> compositor process. The problem is that the user of the "task manager"
>> probably wants an icon in there that says "GIMP" even though there are
>> perhaps 2 image windows that are raised by it. The best way I can see to
>> do this is to have dummy windows that you can also send all the requests
>> and notifys to. GIMP would create this, and requests to raise this dummy
>> window would instead raise all the real ones.
>
> GNOME Shell already groups by pid, and allow for actions that affect the
> whole group, without worrying about the group leader window.

Group by pid is not portable. The client should be able to define
window groups of windows that logically fit together, be they all (or
some  - eg. when running through a proxy)  windows of a single client
going through a single connection or windows of multiple clients going
through multiple connection participating in a single apparent
application by way of plugins of whatever.

If windows grouping support is wanted then it should be implemented
such that the client can say to which group it belongs. Then a window
group is something that a client should be able to create and it
should be able to pass some handle to other clients so that they can
join the group which goes back to managing resources and security.

> In any case, the problem with duplicating the actions client-side is
> that you don't have the complete picture and don't know the effects. For
> example, let's say you click on "GIMP" and as a result the client asks
> to raise both image windows.
> What if one of them is an another workspace? In current mutter, this
> results in the demands-attention state (which in the shell is translated
> to a "GIMP is ready" notification).

You also may or may not want to raise the other parts of gimp. In OS X
there are two operations avaialble - raise window and raise
application. And both have its uses on hopelessly cluttered desktop.

> Current shell solves this by activating the last window when selecting
> an app, but that's a just one possibility. In GNOME Panel, IIRC, there
> was an option that brought all windows to the current workspace when
> activating a group.
>

In general the WM is in the position to manage windows because it
knows what windows are actually present on the desktop and what user
asked to do with which windows and what window management preferences
are set and applications are in the position to hint how their windows
fit together (or not) and what kind of windows they are.

For seamless experience there needs to be some cooperation between the
two sides, neither has the full picture.

Thanks

Michal