Comments on: Window matching http://blogs.gnome.org/metacity/2008/11/02/window-matching/ "Many window managers are like Marshmallow Froot Loops; Metacity is like Cheerios." Sun, 08 Nov 2009 05:22:41 +0000 http://wordpress.org/?v=2.8.6 hourly 1 By: Hongli Lai http://blogs.gnome.org/metacity/2008/11/02/window-matching/comment-page-1/#comment-576 Hongli Lai Tue, 18 Nov 2008 22:31:21 +0000 http://blogs.gnome.org/metacity/?p=171#comment-576 For point (1), I think that there are only a few reasons not to use an out-of-process window matcher: 1. Usability, ease and simplicity. The user doesn't have to install/configure a separate software package. However, this can be solved at the distributor level by integrating the window matcher by default. 2. Efficiency. Integrating a window matcher in Metacity might save you a few hundred KB of memory. The question is of course whether this is worth it. On a single user desktop, probably not. On a server which serves dozens of desktops to thin clients, maybe. 1 is easily solvable, so unless 2 is important, it would make more sense to have an out-of-process window matcher. As for the other points, wouldn't it be a good idea to apply to the window matching rule only if Role is set? Just ignore all clients that don't set Role and treat them like before. I don't think anybody would be annoyed by "different" Firefox windows (whatever the definition of that might be) appearing at the same place. For point (1), I think that there are only a few reasons not to use an out-of-process window matcher:
1. Usability, ease and simplicity. The user doesn’t have to install/configure a separate software package. However, this can be solved at the distributor level by integrating the window matcher by default.
2. Efficiency. Integrating a window matcher in Metacity might save you a few hundred KB of memory. The question is of course whether this is worth it. On a single user desktop, probably not. On a server which serves dozens of desktops to thin clients, maybe.

1 is easily solvable, so unless 2 is important, it would make more sense to have an out-of-process window matcher.

As for the other points, wouldn’t it be a good idea to apply to the window matching rule only if Role is set? Just ignore all clients that don’t set Role and treat them like before. I don’t think anybody would be annoyed by “different” Firefox windows (whatever the definition of that might be) appearing at the same place.

]]> By: Killerkiwi http://blogs.gnome.org/metacity/2008/11/02/window-matching/comment-page-1/#comment-558 Killerkiwi Mon, 03 Nov 2008 03:38:10 +0000 http://blogs.gnome.org/metacity/?p=171#comment-558 Pulse audio is going to need to tie into some thing like this long term... being able to set volume for the active window with a global key combo.. mouse wheel while on the windows title bar would be cool Second the freedesktop.org idea Pulse audio is going to need to tie into some thing like this long term… being able to set volume for the active window with a global key combo.. mouse wheel while on the windows title bar would be cool

Second the freedesktop.org idea

]]> By: Thomas Thurman http://blogs.gnome.org/metacity/2008/11/02/window-matching/comment-page-1/#comment-556 Thomas Thurman Mon, 03 Nov 2008 01:15:33 +0000 http://blogs.gnome.org/metacity/?p=171#comment-556 That's pretty much it, yes. It would make life easier for Devil's Pie etc even if we didn't move its function into Metacity (which we might not do anyway for reasons given above). That’s pretty much it, yes. It would make life easier for Devil’s Pie etc even if we didn’t move its function into Metacity (which we might not do anyway for reasons given above).

]]> By: Robin http://blogs.gnome.org/metacity/2008/11/02/window-matching/comment-page-1/#comment-555 Robin Mon, 03 Nov 2008 01:03:30 +0000 http://blogs.gnome.org/metacity/?p=171#comment-555 Maybe a freedesktop.org specification could be created/extended to clarify what these three properties should look like with some examples. And I think making it a GNOME Goal would also be a good idea. So when all applications would correctly set these three properties, window matching wouldn't be considered as black an art as it is now, right? Or are there other problems? Maybe a freedesktop.org specification could be created/extended to clarify what these three properties should look like with some examples. And I think making it a GNOME Goal would also be a good idea.

So when all applications would correctly set these three properties, window matching wouldn’t be considered as black an art as it is now, right? Or are there other problems?

]]>