GNOME Bugzilla – Bug 307693
gnome-open should respect workspaces
Last modified: 2020-11-06 20:06:47 UTC
Scenario: Two active workspaces, one for work, one for leisure. Work has an open web browser window, for work. Leisure has IM and RSS reader open, but no browser. Web browser is set to open clicks in tabs. A click on a link in workspace Leisure should spawn a new browser window in the workspace Leisure, not open a tab (if that is the choice) in the browser window in workspace Work. Why? a) People use workspaces to keep things separated. This too. b) usability-wise: clicking on a link should get a reaction. This action has no visible reaction. A tab opens in a window user can not see. Only way to know where it went is to check all workspaces, which of course is tedious and a waste of time. Didn't find a better place to file this, please move where appropriate.
What browser to you use? There has been some discussion about gtk_window_present that might be relevant. Moving to metacity. It should probably moved to the webbrowser, but general is way bad.
In my case I'm using FireFox. Did some testing, seems like Mozilla and Epiphany don't let you open clicks from other programs in tabs at all, so this is not an issue. Opera opens in tabs and does the same as FireFox. Didn't check Galeon, Konqueror, or others. Somehow I don't think the browser is to blame since it doesn't know very much about GNOME workspaces (correct me if I'm wrong here), and therefore it should be GNOME that adapts to allow for this functionality. Also, one's choice of browser shouldn't affect the choice of using workspaces.
The problem here is that the web browser implements this behavior on its own. A new instance of the browser is started when you click on the link, which, if left to its own devices would end up as a new window on your current workspace. The problem is that firefox, in order to save resources, forwards the request to any existing instance of itself then exits, without opening any windows. The window manager thus never sees any part of any of this interaction. In order to do this we'd need some sort of specification for cross-process request-forwarding that would provide the necessary hints to the window manager to be able to get this "right" automatically, and the spec would have to be implemented by all of window managers, toolkits, and applications. A tall order, in other words, but perhaps worth it.
I understand your concerns... Although it would be great, it seems like a heck of a lot of work, and frankly, even I as the submitter see bugs that are higher up the priority list. But I have a suggestion that should be relatively easy to implement and at the same time make the situation a bit better for users like me: Switch the workspace. Yes, it does seem weird at first, but the user has chosen the link as the action, and expects a browser window to show up. This way, he will me moved to the workspace where Firefox resides, and everything is good. The user then sees that something has happened, and hopefully figures out how to move both the browser and feed reader to the same workspace, and is able to continue. Liferea has a similar feature already with the notification area icon: click on the icon from a workspace where Liferea is NOT, and the workspace is switched. Works great. Not sure if it's a Liferea feature or Metacity, but you get the idea.
*** Bug 336142 has been marked as a duplicate of this bug. ***
As I wrote in "duplicate" #336142 (I'm not seeing it duplicating much or anything), SeaMonkey and Firefox DO include a method to provide visual feedback when they open new tabs. Mozilla 1.7 could do this too (using openurl() syntax, possibly not present in wrapper for the particular distro or sth) at the time Sergej wrote comment #2. Firefox and SeaMonkey make their buttons in window list applet blinking/flashing. It's not their fault it's not visible right away. Like I wrote in #336142, opening a new window or switching desks (workspaces, work areas or how do you call them) immediately shows flashing SeaMonkey button. So it's NOT the browsers' fault, it's something in Metacity or the window list applet. So, the thing you're talking about in your b) argument (lack of any sign of activity) IS a bug somewhere in GNOME. Still, whole this bug I read as "Firefox should open window on current workspace if its window is somewhere else, but open tabs if I already have a window on my current workspace", which is request for feature in Firefox, not bug in GNOME. It is NOT the same as real bug mentioned in #336142, which IMO should be reopened instead and this one closed with "not our business". I repeat, Firefox DOES notify the WM about new tabs opening in it, this one here is not a bug. The bug is somewhere in GNOME, making this notification invisible until I force window list applet to show it to me.
Leszek: You're talking about a totally different bug than the one in here or bug 336142. Bug 336142 IS a duplicate; but the bug annoying you is bug 317541.
What if the workspace switcher applet square blinked just as the button in the window switcher does, can it be done? Will it solve some of these problems? If so - should I file a new bug about it and close this one?
There's a libwnck bug about that as well as for the window selector applet; I believe there's a patch for one of the two as well...
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.