Comments on: Know all men by these presents…

By: Ben

Ben — Mon, 17 Nov 2008 20:35:27 +0000

Is there a way I can hack Pidgin to go back to the way it was? It infuriates me like no other that when I click the Pidgin tray icon, it does not bring up my buddy list. And when I click a blinking tray icon, it does not show the new IM.

By: Thiago

Thiago — Mon, 10 Nov 2008 00:04:54 +0000

Well, it’s not a question of burden on the users vs. on the developers. The proposed “gtk_window_present(tag, default_behavior)” function keeps *both* in control:

default_behavior – lets developers pick what they think is best.
central configuration GUI to alter the behavior table – lets the users who are bothered by the default behavior pick whatever they prefer.

I think everyone agrees that an over-reaching window-matching approach is a bad idea. Applications should have good defaults, and window matching should be used only to allow users to tweak things to their liking (but shouldn’t be required).

By: Thomas Thurman

Thomas Thurman — Sun, 09 Nov 2008 22:59:06 +0000

This is window matching; see http://blogs.gnome.org/metacity/2008/11/02/window-matching/ for why we haven’t done it.

Even if we did allow window matching, I’m surprised you think that putting this much of a burden on every user is a better solution than putting it onto the developers.

By: Thiago

Thiago — Sun, 09 Nov 2008 22:48:57 +0000

This really ought to be a configurable setting, with a single configuration GUI for all apps. That is, you can change “gtk_window_present()” to “gtk_window_present(tag, default_behavior)” and keep a user-configurable table:

app, tag, behavior
pidgin, message window, pulse
firefox, link opened from elsewhere, summon
etc…

Otherwise, you end up with each developer choosing a default behavior, which is often inconsistent with other apps. Also, this way the developer doesn’t have implement a user-configurable setting, make an interface, keep state, etc.

By: Patrys

Patrys — Fri, 07 Nov 2008 18:56:50 +0000

By allowing apps to specify the behavior (as opposed to just “user interaction” versus “computer-generated event”) we will end up with zero consistency. I don’t think most users care about summoning if we choose to visit in case of user actions and just blink in other cases. Those who care would be free to change the default for “interactive” mode from visit to summon. An app that feels it needs to move a window between desktops should do it on its own and then raise it, not rely on the WM moving it automatically. The two apps that come to mind are Nautilus (where being able to open the same folder on two desktops would actually be useful) and Totem (that insists on having just one instance open for no apparent reason which often forces me to launch mplayer just to be able to compare two videos).

By: Thomas Thurman

Thomas Thurman — Fri, 07 Nov 2008 18:32:55 +0000

@Nicholas:

I really think we need, as well as rethinking the default case, a way for an app to say “And actually what I mean by this is ‘summon’ or whatever”.

(It’s not really much of my concern or business what Compiz does– it’s nothing to do with GNOME. If they want to change to be more like metacity, good for them. :) )

By: Nicholas J Kreucher

Nicholas J Kreucher — Fri, 07 Nov 2008 18:31:38 +0000

BTW — I like Wolki’s idea of allowing apps to specify the mode. Also, as clean and elegant as metacity’s options set is, as Wolki also suggests, this may warrant a “default” setting addition (Summon/Visit/Pulse).

By: Nicholas J Kreucher

Nicholas J Kreucher — Fri, 07 Nov 2008 18:25:51 +0000

See https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/207744 for an example of a bug resulting from Ubuntu’s patch of metacity.

I’m strongly in favor of the GNOME default (Summon). It’s extremely frustrating to click on a notification icon and have basically nothing happen. Same for tomboy… select a note thats already open elsewhere and seemingly nothing happens.

BTW — it’s easy enough to remove the patch from Ubuntu’s metacity to revert back to the GNOME default, but what about users of compiz?

By: David

David — Tue, 28 Oct 2008 12:29:55 +0000

I’m still thinking about it and I think that Spatial Nautius could open more than one window per directory but, only one per workspace.

Also, right now, when a directory is open, it’s icon change to an “open state” icon. This should also be changed; the icon should change only when viewing it from a workspace where the folder is open. Other workspace would still see the normal icon.

Use case 1: You have the same directory ~/Data open on workspace 1 and workspace 2. Each workspace have his own view on the directory (including: scrolling position, selected files, list of expanded sub-folders, …). You move the window from workspace 1 to workspace 2. Then, the window on workspace 2 is replaced with the one from workspace 1.

With this kind of behavior, a notion of “Copy this window to workspace X” (Actually, there is only “Move window to workspace X) could be implemented on the window management system. I don’t think that the “Copy window to workspace X” would work with all applications but it does make sense for some. For such a think, applications would have to be adapted.

By: Metacity Journal, 2008-10-23 - …for the adult in you

Metacity Journal, 2008-10-23 - …for the adult in you — Fri, 24 Oct 2008 02:10:57 +0000

[...] still haven’t come to much of a consensus over the present() issue, so it may need an overview of the overview. Your chronicler suspects that the ultimate solution [...]