GNOME Bugzilla – Bug 647105
Don't show "new window" for single window apps
Last modified: 2014-08-01 09:46:59 UTC
Currently dash provides a "new window" submenu if you right click an icon. This is great and necessary for the terminal, and for firefox. However, why is it present and usable for liferea and empathy as well? And what does it do when I use it repeatedly on Rhythmbox? Right now I have 2x rhythmbox icons in my tray, and that's not very coherent.
Furthermore, the New Window menu entry is present on all apps unless the developer is able to change or suppress it, and if someone clicks on it when the app is running, it opens a new copy of the app. With some apps, this does not result in a new window but a new system tray icon with a menu associated with it.
Renaming for clarity.
I know it is probably worth to open another bug for this but for "multi-window apps" the current behaviour to just open the current open window is most of the time now what I meant. I have two examples (and probably I have to report bugs for these applications, but I am not sure, so I post it here). * Empathy: When I type "<Super> Empa<enter>" I expect always the window list to open. But if the window list is closed, and I have a chat conversation the conversation opens, which is bad IMHO, when I wanted to open the chat conversation I had typed the name of the person with who I am chatting with (which does not work btw, this opens the contact program, which is surely another bug), not the name of the program. Right click on the empathy icon in the dash shows indeed "New window", probably this should be removed and replaced with the always available: "Open contact list" * Virtualbox: Similar to the empathy issue: when I open virtualbox (by clicking on it, or by typing virtualbox), I expect the virtualbox manager to open, not the virtual machine I happen to have running. If I wanted to show the virtual machine I would have typed the name of the VM (which does not work btw, in my example it only finds an iso named the same way).
(In reply to comment #3) > I know it is probably worth to open another bug for this but... Hi Nathan. Yes, this is not the right place to comment on that issue. I've had a quick search for a report for this bug but cannot find one. Please have a look too and create a report if you can't find it.
(In reply to comment #3) > I have two examples (and probably I have to report bugs for these applications, > but I am not sure, so I post it here). > > * Empathy: > When I type "<Super> Empa<enter>" I expect always the window list to open. > But if the window list is closed, and I have a chat conversation the > conversation opens [...] See bug 658043
How is Gnome Shell supposed to know that an application is "single-window"? To my knowledge, there's currently no way for Gnome Shell to identify the different types of interaction and so it seems that either the applications need to be designed differently, or Gnome Shell needs some means of gathering this kind of information.
(In reply to comment #6) > How is Gnome Shell supposed to know that an application is "single-window"? > I think Gnome Shell should simply treat each app as a multi-window app. Then it's the job of the app de prevent more windows to be opened if it is supposed to be a single-window app (using libunique for example).
(In reply to comment #7) > I think Gnome Shell should simply treat each app as a multi-window app. Then > it's the job of the app de prevent more windows to be opened if it is supposed > to be a single-window app (using libunique for example). As I said in bug 650030, the problem is that starting a new app which uses libunique (GtkApp today) takes some time to create a new window: see what happens when you click on a URL outside of Firefox. This would mean there's a delay between the click, the immediate zoom out of the overview, and the opening of the new window. It would be hard for users to understand why raising a window takes one or two seconds. (OK, you said there's no delay to restart Rhythmbox on your laptop, but try with Evolution for example, even on a very fast laptop.) Bug 609707 has some discussion about single/multiple window apps, but towards a different problem.
> As I said in bug 650030, the problem is that starting a new app which uses > libunique (GtkApp today) takes some time to create a new window: see what > happens when you click on a URL outside of Firefox. This would mean there's a > delay between the click, the immediate zoom out of the overview, and the > opening of the new window. It would be hard for users to understand why raising > a window takes one or two seconds. > > (OK, you said there's no delay to restart Rhythmbox on your laptop, but try > with Evolution for example, even on a very fast laptop.) > Well, I guess that's a bug in Evolution then, and it is totally orthogonal to the current bug. Never fix a bug by creating a new one to compensate.
We also need to be able to tell if an app is single window only for bug 646506.
I guess a possible solution would to have a "single-window" keyword in the .desktop files. if the keyword in set, then clicking on the launcher icon would raise the currently running window (and modal dialogs). If the keyword is not set, clicking on the launcher icon would open a new window, and you would have to use the overview to switch to the window you seek.
(In reply to comment #11) > I guess a possible solution would to have a "single-window" keyword in the > .desktop files. if the keyword in set, then clicking on the launcher icon would > raise the currently running window (and modal dialogs). If the keyword is not > set, clicking on the launcher icon would open a new window, and you would have > to use the overview to switch to the window you seek. Or, if you want to be more conservative, if the keyword is not set, clicking on the launcher icon would raise the currently running window(s), but the "new window" entry would be present in the launcher's popup menu (but not if the keyword is set).
Totally agree here. Seems like the best solution is to have a keyword in the .desktop file that indicates it's a single-window application. That would solve the issue here with the "New Window" menu item that doesn't do anything, and, like Allan Day said it's also needed to resolve bug 646506. Also it would solve the problem for bug 650030, as you can see much the same discussion is going on there.
This might be a good use for desktop actions (which we now support with GIO). We could just always remove this and expect applications to add it back for themselves via a desktop action if they support it.
*** Bug 732606 has been marked as a duplicate of this bug. ***
Thanks for taking the time to report this bug. This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed. It should be solved in the next software version. You may want to check for a software upgrade. *** This bug has been marked as a duplicate of bug 722554 ***