vivid, utopic and trusty unity (7.3.1+14.10.20140811-0ubuntu1) launcher addition through gsettings isn't picked up

Bug #1364070 reported by Didier Roche-Tolomelli
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
GLib
Expired
Medium
Unity
Invalid
Medium
Unassigned
unity (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

As discussed on IRC, I tried to change the favorites key, and 3 trials on 10 didn't make any change in what the launcher displays. seb128 reproduced it as well. (just be aware that we just create the .desktop file just before).

The exact same code seems to work 100% of the time on trusty.

So, we:
1. create the desktop file
2. from gi.repository import GLib, Gio
gsettings = Gio.Settings(schema_id="com.canonical.Unity.Launcher", path="/com/canonical/unity/launcher/")
then, get the favorites list and add the desktop file.
3. gsettings.set_strv("favorites", new_launcher_list)
-> No launcher icon added from new launcher list.
However, a "$ gsettings get" shows that desktop file (which is present.
Note that changing the list and changing it back works.

This was first experimented on June 2014 and reported on IRC.

Changed in unity (Ubuntu):
status: New → Confirmed
Changed in unity:
status: New → Confirmed
description: updated
description: updated
Stephen M. Webb (bregma)
Changed in unity:
importance: Undecided → Medium
Changed in unity (Ubuntu):
importance: Undecided → Medium
summary: - utopic unity (7.3.1+14.10.20140811-0ubuntu1) launcher addition through
- gsettings isn't picked up
+ utopic and trusty unity (7.3.1+14.10.20140811-0ubuntu1) launcher
+ addition through gsettings isn't picked up
Changed in unity:
milestone: none → 7.3.2
Andrea Azzarone (azzar1)
Changed in unity:
assignee: nobody → Andrea Azzarone (andyrock)
Changed in unity (Ubuntu):
assignee: nobody → Andrea Azzarone (andyrock)
summary: - utopic and trusty unity (7.3.1+14.10.20140811-0ubuntu1) launcher
+ vivid, utopic and trusty unity (7.3.1+14.10.20140811-0ubuntu1) launcher
addition through gsettings isn't picked up
Andrea Azzarone (azzar1)
Changed in unity:
milestone: 7.3.2 → 7.3.1
status: Confirmed → In Progress
Changed in unity (Ubuntu):
status: Confirmed → In Progress
Revision history for this message
Andrea Azzarone (azzar1) wrote :

That's probably glib/gio's fault. When this happens g_desktop_app_info_new returns NULL when it should return a valid GDesktopAppInfo. It's likely a timing issue that should be fixed in glib/gio or in the script (adding a small timeout after moving the file in the directory). Correct me if I'm wrong.

Revision history for this message
Allison Karlitskaya (desrt) wrote :

Yup. This is a GIO issue. We register a file monitor and don't bother checking if desktop files changed until we see the file monitor has fired. Due to inotify implementation issues, this usually happens about ~1s later.

We will need to add a mechanism to force a reload and/or do it automatically in case we see a lookup failure.

Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

Thanks Andrea for looking deeper into this! Opened the upstream bug for it.

Changed in unity:
status: In Progress → Incomplete
Changed in unity (Ubuntu):
status: In Progress → Incomplete
Changed in unity:
status: Incomplete → Invalid
Changed in unity (Ubuntu):
status: Incomplete → Invalid
Changed in glib:
importance: Unknown → Medium
status: Unknown → New
Andrea Azzarone (azzar1)
Changed in unity:
milestone: 7.3.1 → none
assignee: Andrea Azzarone (andyrock) → nobody
Changed in unity (Ubuntu):
assignee: Andrea Azzarone (andyrock) → nobody
Changed in glib:
status: New → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.