Ubuntu
unity package

How do I run a second instance of an application from the unity launcher?

Asked by Rocko

In the unity launcher, Firefox has the following entries on right-mouse click:

* Open a new window
* Firefox web browser
* Keep in launcher
* Quit

"Open a new window" will open another instance of Firefox rather than switch to the existing instance.

But how do I do this for other applications? For instance, if I run VirtualBox and start up a VM but close the VirtualBox control window, how do I get the Virtual control window back using the launcher? The only options that appear are "Oracle VirtualBox" (which switches to the running VM), "Keep in launcher", and "Quit".

An obvious workaround is to run it from the dash searcher, but this is much harder than dockbarx or AWN, which let you re-launch the original program from the launcher.

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu unity Edit question
Assignee:
No assignee Edit question
Solved by:
Eliah Kagan
Solved:
Last query:
Last reply:
Revision history for this message
Best Eliah Kagan (degeneracypressure) said : 		#1

Click the application's icon with the middle mouse button (which, on most mice, is the button that also acts as the scroll-wheel).

Revision history for this message
Rocko (rockorequin) said : 		#2

The first time I tried it, it crashed unity so badly I had to restart gdm. :)

Otherwise, it works fine (it's just not that intuitive) except that there is no effect (eg pulse) to show that you have run it.

Revision history for this message
Eliah Kagan (degeneracypressure) said : 		#3

"The first time I tried it, it crashed unity so badly I had to restart gdm."

Ubuntu 11.04 is still in beta, and some bugs are to be expected. Did you report the crash? Also, when you say you had to restart gdm, what do you mean? gdm provides the login screen? Do you mean you had to restart your login session (logging out and back in again)?

Revision history for this message
Rocko (rockorequin) said : 		#4

Yes, the compiz-unity combination makes for the most buggy Ubuntu beta I have ever seen! At least in terms of 'catastrophic bugs' where the entire desktop hangs meaning you lose any unsaved work.

The 'crash' I experienced was a complete lock-up of the X session - not even the mouse was responding - except that I could still get to a tty console. To restart gdm, I typed 'sudo restart gdm' in the tty console. (As I understand it, gdm provides the X session - see http://en.wikipedia.org/wiki/GNOME_Display_Manager - and gdm-greeter provides the login screen.)

Unfortunately there were no crash files generated and nothing in the syslog, so I can't provide any meaningful information for a bug report. Perhaps this crash was related to the bug that completely locks the session when you change certain ccsm parameters in a unity session (https://bugs.launchpad.net/ubuntu/+source/unity/+bug/685552).

Revision history for this message
Eliah Kagan (degeneracypressure) said : 		#5

"(As I understand it, gdm provides the X session - see http://en.wikipedia.org/wiki/GNOME_Display_Manager - and gdm-greeter provides the login screen.)"

Since that, and also killing the GDM process, causes a login session to immediately terminate (in this latter case, the virtual terminal that had X11 gets Plymouth instead, like during startup and shutdown), I'd say you're right--thanks for the correction.

"Unfortunately there were no crash files generated and nothing in the syslog, so I can't provide any meaningful information for a bug report."

You should be able to report this bug by pressing Alt+F2 and running:

ubuntu-bug compiz

That's assuming the bug actually is in compiz. It probably is...but in case it's not, you might prefer to instead run ubuntu-bug without arguments, and answer the questions. I'm not sure which of the two approaches is better for this situation. I would probably go with the former approach, as it ensures that compiz-specific information gets attached. I can always attach additional information later as requested by Ubuntu developers / bug triagers.

Either way, you should then make sure to attach the relevant log files to your bug report, which in this case are .xsession-errors and .xsession-errors.old in your home directory, as well as Xorg.0.log and Xorg.0.log.old in /var/log. (There may be other files relevant to this situation and not automatically attached by Apport, but I don't know what they would be. Please note also that some of these four files might be automatically attached by Apport, so you should look through your bug's list of attachments before attaching them. Finally, usually the .old files are not attached to bug reports...but this didn't just happen, so I think you're more likely to attach information documenting the compiz/unity hang you experienced if you attach them as well.

(If you are able to look through these files and know for sure that some do not contain relevant information, then you needn't include those.)

If you're able to reproduce this bug, then you should definitely do so immediately before reporting it as described above, but even in that case I think you need to attach the .old files, because when you log back in to report the bug, you have a new session with new log files.

Normally I'd say to make sure to read https://help.ubuntu.com/community/ReportingBugs before filing the bug report, but since you've reported many bugs, I needn't mention that. But perhaps it has recently been revised to include advise about reporting hard-to-report interface bugs like this one--it might be worth checking. And of course, you should try searching for this bug before reporting it (if you haven't already), as always.

Revision history for this message
Eliah Kagan (degeneracypressure) said : 		#6

"Perhaps this crash was related to the bug that completely locks the session when you change certain ccsm parameters in a unity session (https://bugs.launchpad.net/ubuntu/+source/unity/+bug/685552)."

Perhaps so, but do you have any reason to think the bug you've experienced is a crash (rather than a hang, which seems more consistent with the interface perpetually not responding or otherwise changing)?

Revision history for this message
Rocko (rockorequin) said : 		#7

I used the term 'crash' loosely. It might have been a crash, but might also have been a hang. Switching back from the tty console didn't free it from the hang, though (sometimes it does), so it was a quite catastrophic hang.

Unfortunately, I can't reproduce this particular hang and I've had to restart the session several times since then so the .xsession-errors files from then have been overwritten. But I'll take care to make copies of them next time.