On 16 September 2011 11:18, Giovanni Campagna <scampa.giova...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel