Skip to content

Fix #14 missing icon in GNOME 3.32#15

Open
crazygolem wants to merge 1 commit intosimonthechipmunk:masterfrom
crazygolem:patch-1
Open

Fix #14 missing icon in GNOME 3.32#15
crazygolem wants to merge 1 commit intosimonthechipmunk:masterfrom
crazygolem:patch-1

Conversation

@crazygolem
Copy link

Admittedly should be "Quickfixes #14"...

Admittedly should be "Quickfixes #14"...
@simonthechipmunk
Copy link
Owner

Hi,
thanks for helping with this issue. I'd like to merge this but I have absolutely no clue why this is necessary, what the code does or why there's suddenly a problem at all.

I tried looking at the documentation but it doesn't make sense (I wasn't expecting anything else from the gnome dev hub to be honest):
https://developer.gnome.org/gio/stable/GIcon.html#g-icon-new-for-string

We are now de-serializing a textual representation of a gicon instance that has never been serialized in the first place and therefore shouldn't exist? Sorry, I honestly don't get this.

I can't even tell whether this will break compatibility with older Gnome Shell versions or not. That's not your fault. It seems the gnome desktop is becoming worse with every release. So many dumb decisions lately and I'm really losing my patience.

@crazygolem
Copy link
Author

I tried a few times getting into gnome extensions development, but so far my efforts were mostly fruitless. With this preamble in mind: don't worry, it doesn't make much more sense to me =)

I think I got this solution mostly by chance, trying out a few things based on outdated code I found around; an implementation of _createActionButton and an old so post.

From system.js:

    _createActionButton(iconName, accessibleName) {
        let icon = new St.Button({ reactive: true,
                                   can_focus: true,
                                   track_hover: true,
                                   accessible_name: accessibleName,
                                   style_class: 'system-menu-action' });
        icon.child = new St.Icon({ icon_name: iconName });
        return icon;
    }

That method you use simply creates an St.Icon with the specified icon_name, without the possibility to set something else (like gicon). My "fix" replaces that with an St.Icon which was created with a gicon instead.

Frankly, I have no clue what a "gicon" is, so I cannot explain why a method named "from_string" takes a path as argument and produces an image. I suspected that the "string" in "from string" meant "path as a string", but the documentation you pointed to, mentioning "serialization" and stuffs is making me doubt that interpretation now. Technically, an image file is a "serialization of the image object on disk", but if that's the explanation then the guy who wrote the doc did it to win a bet :/

However I've looked around a bit more and seen that other well-known extensions do it in a similar way (so can it even be wrong? (yes it can, nobody can know with gnome-shell)), e.g. Activities Configurator:

this._activitiesIconButton._iconBin.child = new St.Icon({ gicon: Gio.icon_new_for_string(iconPath) });

So why did the previous behavior change? I have no idea and don't even know where I would start looking. Why did it even work before? I mean the icon_name you used which corresponded to a file in the extension's directory structure was quite arbitrary. How did gnome-shell know to look in the icons/ directory in the first place? Maybe they changed something in the lookup algorithm, or you have now to register the extra resources explicitly.

@maweki
Copy link

maweki commented May 1, 2019

You could try to augment the search path like we do (https://github.com/maweki/twitchlive-extension/blob/master/extension.js#L364) but we also load our icons using the gicon from_string (https://github.com/maweki/twitchlive-extension/blob/master/extension.js#L364)

@crazygolem
Copy link
Author

Thanks for the hint @maweki, but actually turnoffdisplay already augments the search path in its own init() function.
Is there a reason why you still load icons with from_string even when you augment the search path?

@maweki
Copy link

maweki commented May 1, 2019

Now that you ask: I don't know either. An angel PR by @oae did that. I think we had it before like you do. Maybe search path for icons no longer works in 3.32.

gnome-shell documentation is abysmal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants