vivid, utopic and trusty unity (7.3.1+14.10.20140811-0ubuntu1) launcher addition through gsettings isn't picked up
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | GLib |
New
|
Medium
|
||
| | Unity |
Invalid
|
Medium
|
Unassigned | |
| | unity (Ubuntu) |
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(
then, get the favorites list and add the desktop file.
3. gsettings.
-> 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 |
| 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 |
| 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 |
| Changed in unity: | |
| milestone: | 7.3.2 → 7.3.1 |
| status: | Confirmed → In Progress |
| Changed in unity (Ubuntu): | |
| status: | Confirmed → In Progress |
| Andrea Azzarone (azzar1) wrote : | #1 |
| Allison Lortie (desrt) wrote : | #2 |
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.
| Didier Roche (didrocks) wrote : | #3 |
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 |
| Changed in unity: | |
| milestone: | 7.3.1 → none |
| assignee: | Andrea Azzarone (andyrock) → nobody |
| Changed in unity (Ubuntu): | |
| assignee: | Andrea Azzarone (andyrock) → nobody |


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.