Add an option to the LauncherAPI to override the behaviour of the LauncherEntry
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Unity |
Triaged
|
Wishlist
|
Unassigned | ||
unity (Ubuntu) |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
For emesene, we would like to bring up an already started instance (hidden in the Messaging Menu) through the LauncherEntry, not a new instance. It would be nice if we could use the LauncherAPI to do this. The custom quicklist etc. already work, so it already knows emesene is running. We just need to have an option to override the default onclick LauncherEntry behaviour.
We don't want to make emesene single-instance, because we allow multiple instances with multiple sessions. That is also the reason why we don't want to change the desktop file. The user should still be able to start a new instance through the dash.
If this would be the new default behaviour for all apps using the Messaging Menu, that would be good too.
Changed in unity (Ubuntu): | |
importance: | Undecided → Wishlist |
Changed in unity: | |
importance: | Undecided → Wishlist |
Changed in unity (Ubuntu): | |
status: | New → Confirmed |
Changed in unity: | |
status: | New → Confirmed |
Changed in unity (Ubuntu): | |
status: | Confirmed → Triaged |
Changed in unity: | |
status: | Confirmed → Triaged |
I suspect the ideal thing to do here is to optimise for the common-case (from the users' point-of-view).
For instance, the way that Firefox handles a related situation (it can be raised from the Launcher, or from other applications when the user clicks on a URL) to raise its existing instance. Thus the common case is:
firefox
and the uncommon-case is:
firefox -new-window
I think this would power-user the opportunity to run/open multiple instances/windows (the power-user is more likely to know how to search, read --help or manpages) while giving a better experience for the normal messaging user.