unity-2d

[dash] Single instance applications are not focused/raised when clicked on

Bug #702057 reported by Ugo Riboni on 2011-01-12

This bug affects 3 people

Affects		Status	Importance	Assigned to	Milestone
	unity-2d	Invalid	Medium	Unassigned
	unity-2d (Ubuntu)	Invalid	Undecided	Unassigned

Bug Description

There are some applications that when launched more than once will just activate the existing instance instead of opening a new one. Totem is an example of this kind of applications.

When one such application is started from the dash by clicking on its icon, the interaction is quite confusing for the user.

What should happen is that the dash is hidden and the existing instance is given focus.
However right now the dash remains visible and if it's closed manually the existing instance of the app is not focused.

Since the dash normally hides itself on focus loss, the root cause of this problem is likely that, when activated from the dash, the new instance fails to cause the existing instance to be focused.

Steps to reproduce:
1. Launch totem
2. Focus another application
3. Go to the dash and find the totem entry
4. Click on totem

Expected result:
The existing totem window receives the focus and the dash disappears.

Current result:
The existing totem window's urgency flag is set and the dash does _not_ disappear.

See original description

Tags:

Revision history for this message

Ugo Riboni (uriboni) wrote on 2011-01-12:

FYI, it seems that the single instance feature of Totem is handled via libunique, so fixing the issue for Totem will likely fix it for all apps that use this library.

description:

updated

Florian Boucault (fboucault) on 2011-01-13

summary:	- Single instance apps have confusing interaction with the dash + [dash] Single instance applications are not focused/raised when clicked + on
description:	updated
Changed in upicek:
status:	New → Confirmed
milestone:	none → 0.6
importance:	Undecided → High

Florian Boucault (fboucault) on 2011-01-17

affects:	upicek → unity-2d
Changed in unity-2d:
milestone:	0.6 → none
milestone:	none → 3.4

Florian Boucault (fboucault) on 2011-01-17

visibility:

private → public

Florian Boucault (fboucault) on 2011-01-17

Changed in unity-2d:
assignee:	nobody → Aurélien Gâteau (agateau)

Florian Boucault (fboucault) on 2011-01-24

Changed in unity-2d:
milestone:	3.4 → 3.6

Florian Boucault (fboucault) on 2011-01-31

Changed in unity-2d:
milestone:	3.6 → 3.8

Florian Boucault (fboucault) on 2011-01-31

Changed in unity-2d:
assignee:	Aurélien Gâteau (agateau) → nobody

Florian Boucault (fboucault) on 2011-03-02

Changed in unity-2d:
milestone:	3.8 → none

Florian Boucault (fboucault) on 2011-03-23

Changed in unity-2d:
importance:	High → Medium

Revision history for this message

Timo Kluck (tkluck) wrote on 2011-04-16:

Here's a bug that is probably so much related that I don't want to open a separate bug report:

Steps to reproduce (unity-2d version 3.8.2-0ubuntu1):
* open a terminal window
* gedit &
* alt+tab to the terminal window
* gedit

from now on, the launcher will not hide anymore. The same thing can be done with other single instance applications: I've tested totem and clementine.

This is a more serious issue than the one originally reported, as it makes the part of the screen that is covered by the launcher unusable.

Revision history for this message

Timo Kluck (tkluck) wrote on 2011-04-16:

unity-2d-visibility.patch Edit (530 bytes, text/plain)

This patch seems to solve the issue I just reported. Both launcher.qml (target: applications onApplicationBecameUrgent) and launcherlist.qml (target:urgentAnimation onRunningChanged) call beginForceVisible().

I am not very familiar with the code, so please check that this does not break any other things.

Revision history for this message

Timo Kluck (tkluck) wrote on 2011-04-16:

By the way: I cannot reproduce the original bug. I am very sorry for polluting this bug report in the way I just did. Let me know if I should open a new bug report for the issue I just described.

Revision history for this message

Olivier Tilloy (osomon) wrote on 2011-04-18:

@Timo: thanks for the report. This is a separate issue, unrelated to the issue described originally, and it is tracked by bug #763116, for which a fix has just been committed.

By the way, your analysis of the root cause of the issue was correct (congratulations!), although the fix is slightly more complex due to other considerations.

Didier Roche-Tolomelli (didrocks) on 2011-05-31