After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 746219 - Some applications appear as "..." in the app grid
Some applications appear as "..." in the app grid
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.15.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 746739 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-03-14 22:05 UTC by Cosimo Cecchi
Modified: 2015-03-25 13:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screenshot (571.25 KB, image/jpeg)
2015-03-14 22:05 UTC, Cosimo Cecchi
  Details
StIcon: split loading of pending texture in separate function (2.35 KB, patch)
2015-03-14 22:46 UTC, Cosimo Cecchi
reviewed Details | Review
StIcon: add a fallback-icon-name property (5.66 KB, patch)
2015-03-14 22:46 UTC, Cosimo Cecchi
accepted-commit_now Details | Review
ShellApp: use st_icon_set_fallback_icon_name() to specify app fallback (1.21 KB, patch)
2015-03-14 22:46 UTC, Cosimo Cecchi
accepted-commit_now Details | Review

Description Cosimo Cecchi 2015-03-14 22:05:00 UTC
Created attachment 299419 [details]
screenshot

See attached screenshot; that application is actually Google Chrome beta.
Comment 1 Florian Müllner 2015-03-14 22:22:34 UTC
That probably means that the .desktop file specifies an icon name (so no fallback to 'application-x-executable'), but it cannot be resolved to an actual icon. The empty icon texture is supposed to have the correct size anyway, but something's failing ...
Comment 2 Cosimo Cecchi 2015-03-14 22:46:42 UTC
Created attachment 299421 [details] [review]
StIcon: split loading of pending texture in separate function

This will be more useful later.
Comment 3 Cosimo Cecchi 2015-03-14 22:46:46 UTC
Created attachment 299422 [details] [review]
StIcon: add a fallback-icon-name property

This can be used when the lookup for the specified icon fails, in case
the client doesn't want an empty texture.
Comment 4 Cosimo Cecchi 2015-03-14 22:46:50 UTC
Created attachment 299423 [details] [review]
ShellApp: use st_icon_set_fallback_icon_name() to specify app fallback

We can now safely pass a NULL GIcon to st_icon_set_gicon(), and specify
a more generic fallback using the new API we just introduced.
Comment 5 Cosimo Cecchi 2015-03-14 22:48:01 UTC
(In reply to Florian Müllner from comment #1)
> That probably means that the .desktop file specifies an icon name (so no
> fallback to 'application-x-executable'), but it cannot be resolved to an
> actual icon. The empty icon texture is supposed to have the correct size
> anyway, but something's failing ...

An empty icon texture wouldn't be much better to be fair... I implemented a more generic fallback to application-x-executable in the attached patchset.
Comment 6 Florian Müllner 2015-03-15 00:24:43 UTC
Review of attachment 299421 [details] [review]:

Not sure about this one - the new function looks misnamed to me, and the split seems completely irrelevant for the following patches.

::: src/st/st-icon.c
@@ +394,3 @@
     }
 
+  load_pending_texture (icon);

... except that it's more setup_stuff_to_replace_icon_texture_when_ready, the actual loading was already done above?
Comment 7 Florian Müllner 2015-03-15 00:24:50 UTC
Review of attachment 299422 [details] [review]:

LGTM
Comment 8 Florian Müllner 2015-03-15 00:24:56 UTC
Review of attachment 299423 [details] [review]:

Nice!
Comment 9 Cosimo Cecchi 2015-03-15 00:32:41 UTC
Attachment 299422 [details] pushed as c7185d5 - StIcon: add a fallback-icon-name property
Attachment 299423 [details] pushed as f812e9b - ShellApp: use st_icon_set_fallback_icon_name() to specify app fallback

Yeah, the patchset still works without that patch.
I pushed the other two to master.
Comment 10 Florian Müllner 2015-03-25 13:49:18 UTC
*** Bug 746739 has been marked as a duplicate of this bug. ***