GNOME 42 Support

[freddyw]

The panel worked on gnome 42 alpha, but after an update to gnome 42 beta ( gnome-shell-42~beta-2.fc36.x86_64 to be exact) the panel is not working and this error appears in the journal: Object 0x14b6bd21bbb8 is not a subclass of GObject_Object, it's a Object So I guess it needs a bit of work for the upcoming Gnome 42. Wish I had the knowledge to fix is myself.

[pkkid]

Can we just take a moment to appreciate the phrase, Impossible to enumerate trash children. :laughing: Also, I am getting a very similar error in gnome-shell 41.3 on Ubuntu 22.04.

[crosser]

FWIW I started to get the same error on jammy with gnome-shell from the distro: ii gnome-shell 41.3-1ubuntu1, when I try to use dash-to-panel from the distro (45-1) or locally built from the current master likewise. It makes me suspect that it it triggered by an upgrade of some library (libglib?)

[philippun1]

I also have the same error on the latest jammy build with gnome-shell 41.3. Probably since the upgrade to gjs 71.1. My spontaneous guess would be the Utils.defineClass method is no longer compatible with the latest gjs version?

[miigotu]

FWIW I started to get the same error on jammy with gnome-shell from the distro: ii gnome-shell 41.3-1ubuntu1, when I try to use dash-to-panel from the distro (45-1) or locally built from the current master likewise. It makes me suspect that it it triggered by an upgrade of some library (libglib?)

I'm on jammy also.

[irenegr]

Same problem, gnome-shell version 41.3, gnome version 42.beta (jammy)

[thuandt]

Ubuntu 22.04 and have same issue :)

[fcole90]

On Ubuntu 22.04, I get the following error:

JS ERROR: Extension dash-to-panel@jderose9.github.com: TypeError: Object 0x2834251a0878 is not a subclass of GObject_Object, it's a Object
_patchContainerClass/containerClass.prototype.add@resource:///org/gnome/shell/ui/environment.js:61:14
_createPanel@/home/fabio/.local/share/gnome-shell/extensions/dash-to-panel@jderose9.github.com/panelManager.js:404:18
enable@/home/fabio/.local/share/gnome-shell/extensions/dash-to-panel@jderose9.github.com/panelManager.js:84:34
_enable@/home/fabio/.local/share/gnome-shell/extensions/dash-to-panel@jderose9.github.com/extension.js:106:18
enable@/home/fabio/.local/share/gnome-shell/extensions/dash-to-panel@jderose9.github.com/extension.js:66:5
_callExtensionEnable@resource:///org/gnome/shell/ui/extensionSystem.js:167:32
loadExtension@resource:///org/gnome/shell/ui/extensionSystem.js:350:26
_onInstallButtonPressed@resource:///org/gnome/shell/ui/extensionDownloader.js:283:35
Async*addButton/<@resource:///org/gnome/shell/ui/dialog.js:136:41
Caused by: Error: This JS object wrapper isn't wrapping a GObject. If this is a custom subclass, are you sure you chained up to the parent _init properly?

This happens when attempting to install the extension. Installation works, but then the extension is loaded and GS throws this error and no panel is shown at all.

To get panels, I uninstall the extension from https://extensions.gnome.org/local/ then log out and log back in.

[fcole90]

Just compiled from source, same issue.

[fcole90]

Is there any resource with the list of changes? :blush:

[miigotu]

This is the patch that caused this, in gjs: https://mail.gnome.org/archives/commits-list/2019-September/msg00008.html

[philippun1]

I've made a draft PR #1584 At least the panel is visible again, but many things don't work yet, i.e., Utils.hookVfunc. If someone has any ideas on that, please let me know. Tested on Ubuntu Jammy.

[miigotu]

Anyone else not have a top bar anymore? So annoying since the update all my indicators and time missing smh

[Ra72xx]

In Ubuntu 22.04, try disabling (!) extensions. This works for me to get at least the top panel back.

[bakuii]

I also have the same error on the latest jammy build with gnome-shell 41.3. I follow philippun1 hint about downgrading gjs. I downgrade gjs to 1.70.1-1 and this error gone.

[crosser]

JFYI, I filed a launchpad bug for jammy

[jhpratt]

Anything someone (me) who has never touched gnome extensions can do to help?

[crab2313]

Hi guys, I have fixed it myself based on @philippun1's prior work.

gnome42.tar.gz

[crosser]

@crab2313 does it continue to work with gnome 41? If yes, should it be "shell-version": [ "41", "42" ], in metadata.json?

I am going to test your patches momentarily

[crab2313]

@crab2313 does it continue to work with gnome 41? If yes, should it be "shell-version": [ "41", "42" ], in metadata.json?

I am going to test your patches momentarily

I think the difference is about gjs.

[crosser]

Aand it works for me! (In jammy source package, I've put the patches into debian/patches and rebuilt, as simple as that.)

Thanks a lot @crab2313 for your effort!

Any chance to make this into an PR?

[nexryai]

Hi guys, I have fixed it myself based on @philippun1's prior work.

gnome42.tar.gz

Excellent!!! This patch worked perfectly in my environment (openSUSE Tumbleweed + Gnome42 RC).

[nename0]

Does not work for me on jammy. I get: proto[Gi.gobject_prototype_symbol] is undefined

[miigotu]

@crab2313 does it continue to work with gnome 41? If yes, should it be "shell-version": [ "41", "42" ], in metadata.json?

I am going to test your patches momentarily

Does that include 42.beta?

[jackmawer]

This patch does indeed work on 42 - it's nice to see the dock again! Notable issues include the click handlers for the task icons not working properly - left clicking to toggle seems to work, but previews only appear on hover, and right click is broken. Also, after locking and unlocking, everything goes a bit crazy and the panel stops displaying properly. Possibly relevant syslog entries:

Mar 16 13:44:49 aiden gsd-media-keys[4785]: Couldn't lock screen: Timeout was reached
Mar 16 13:44:50 aiden gnome-shell[118810]: Can't update stage views actor <unnamed>[<MetaWindowGroup>:0x5599b41dc350] is on because it needs an allocation.
Mar 16 13:44:50 aiden gnome-shell[118810]: Can't update stage views actor <unnamed>[<MetaWindowActorX11>:0x5599b6121ad0] is on because it needs an allocation.
Mar 16 13:44:50 aiden gnome-shell[118810]: Can't update stage views actor <unnamed>[<MetaSurfaceActorX11>:0x5599b61234b0] is on because it needs an allocation.
Mar 16 13:45:00 aiden gnome-shell[118810]: Spurious clutter_actor_allocate called for actor 0x5599b558f5b0/<unnamed>[<StBin>:0x5599b558f5b0] which isn't a descendent of the stage!
Mar 16 13:45:00 aiden gnome-shell[118810]: JS WARNING: [/home/jack/.local/share/gnome-shell/extensions/dash-to-panel@jderose9.github.com/panel.js 952]: Too many arguments to method Clutter.Actor.allocate: expected 1, got 3
Mar 16 13:45:00 aiden gnome-shell[118810]: JS WARNING: [/home/jack/.local/share/gnome-shell/extensions/dash-to-panel@jderose9.github.com/panel.js 952]: Too many arguments to method Clutter.Actor.allocate: expected 1, got 3

[crosser]

IIRC right click on panel icons was broken some time before the extension stopped to load.

It is annoying, but probably a matter for a separate ticket.

Edit: I confirm that the panel is broken after locking and unlocking

[crab2313]

Confirmed. Please try the new patch set below.

gnome42-v2.tar.gz

IIRC right click on panel icons was broken some time before the extension stopped to load.

It is annoying, but probably a matter for a separate ticket.

Edit: I confirm that the panel is broken after locking and unlocking

[freddyw]

Confirmed. Please try the new patch set below.

gnome42-v2.tar.gz

IIRC right click on panel icons was broken some time before the extension stopped to load. It is annoying, but probably a matter for a separate ticket. Edit: I confirm that the panel is broken after locking and unlocking

This new patch set works for me on Fedora 36 (surviving a lock/unlock). Thanks for all your efforts guys! FWIW, right click works for me on Fedora 35, it stopped working on Fedora 36.

[crab2313]

The issue of right clicking seems to be caused by this error.

Mar 16 23:53:18 yoga14s gnome-shell[91650]: JS ERROR: TypeError: super[func] is not a function
                                            callParent@/usr/share/gnome-shell/extensions/dash-to-panel@jderose9.github.com/utils.js line 94 > eval:1:199
                                            _init@/usr/share/gnome-shell/extensions/dash-to-panel@jderose9.github.com/appIcons.js:1463:14
                                            C@/usr/share/gnome-shell/extensions/dash-to-panel@jderose9.github.com/utils.js line 94 > eval:1:46
                                            popupMenu@/usr/share/gnome-shell/extensions/dash-to-panel@jderose9.github.com/appIcons.js:645:26
                                            vfunc_button_press_event@resource:///org/gnome/shell/ui/appDisplay.js:3146:18

[crosser]

Confirmed. Please try the new patch set below.

gnome42-v2.tar.gz

Works for me (not broken after lock now). :+1:

[hf29h8sh321]

@crab2313 There's an issue I'm experiencing. If I hover over something on the panel, the hover effect (preview, color, tooltip, etc) stays if I move my mouse up. The only way to get it to go away if to move mouse sideways to an empty part of the panel.

[philippun1]

I have added the patches from @crab2313 to my MR: #1584

[miigotu]

@crab2313 There's an issue I'm experiencing. If I hover over something on the panel, the hover effect (preview, color, tooltip, etc) stays if I move my mouse up. The only way to get it to go away if to move mouse sideways to an empty part of the panel.

This happens in other extensions with gnome42 also, dash-to-dock, etc.

[IceTrayz]

https://discourse.ubuntu.com/t/update-for-dash-to-panel-package/27346/1

dash-to-panel package likely to be removed from Ubuntu repositories.

[nexryai]

I have tried this MR and Intellihide does not appear to be working. The taskbar is always visible instead of hidden.

[nexryai]

@crab2313 There's an issue I'm experiencing. If I hover over something on the panel, the hover effect (preview, color, tooltip, etc) stays if I move my mouse up. The only way to get it to go away if to move mouse sideways to an empty part of the panel.

Oddly enough, I am encountering the same glitch with popup notifications: up until 41, hovering over the popup notification and then moving the cursor to another location would close the popup, but in 42, nothing happens when I move the cursor. So it appears that this is not an extension-specific issue, but rather a glitch in the processing that is triggered by "mouse away" in Gnome 42.

[miigotu]

https://discourse.ubuntu.com/t/update-for-dash-to-panel-package/27346/1

dash-to-panel package likely to be removed from Ubuntu repositories.

Most people install from extensions.gnome.org anyway. We don't need it in the package center. Imo, most people don't even use the package center, or snaps. I completely removed snaps, and use apt entirely, or gnome extensions website.

Maintainer could very well provide their own ppa, and push releases to it automatically with GitHub actions.

[IceTrayz]

@miigotu

Maintainer could very well provide their own

As it stands it doesn't look like we have one as @jderose9 no longer has time for the project and @charlesg99 hasn't bothered to tell us what is happening with the project, he removed the paypal donation link and applied a couple of commits months ago and that's about it.

[psarraf]

@crab2313 There's an issue I'm experiencing. If I hover over something on the panel, the hover effect (preview, color, tooltip, etc) stays if I move my mouse up. The only way to get it to go away if to move mouse sideways to an empty part of the panel.

This happens in other extensions with gnome42 also, dash-to-dock, etc.

This appears to be an issue with mutter. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2321

[crosser]

Most people install from extensions.gnome.org anyway. We don't need it in the package center.

Please do not make decisions based on this reasoning. Every additional source from which software can be installed increases the user's attack surface. In this respect, having the package removed from the distro's deb repo is rather bad news.

[philippun1]

Yes, dash-to-panel being removed from Ubuntu packages is sad indeed. But with Extension Manager on Flathub there is a very convenient way now to get extensions and keep them up to date. https://flathub.org/apps/details/com.mattjakeman.ExtensionManager

[miigotu]

@miigotu

Maintainer could very well provide their own

As it stands it doesn't look like we have one as @jderose9 no longer has time for the project and @charlesg99 hasn't bothered to tell us what is happening with the project, he removed the paypal donation link and applied a couple of commits months ago and that's about it.

I could very well fork and maintain a clone if there were enough support and code contributions. I'm not interested in just keeping another stale repository on my profile though.

Very well likely that the extension is not whitelisted because it is no longer maintained and cannot be guaranteed to work with the current release. With a well managed and maintained repo we could bring a similar extension back into the distribution repositories.

[miigotu]

Most people install from extensions.gnome.org anyway. We don't need it in the package center.

Please do not make decisions based on this reasoning. Every additional source from which software can be installed increases the user's attack surface. In this respect, having the package removed from the distro's deb repo is rather bad news.

That's just incorrect. Separate source locations that are trusted limits the reach any single attack can achieve. Mostly everyone adds at least one external software repository on their daily use machine unless they are disallowed by policy. If an extension has any attack surface at all, it is the extensions implementation at fault, not the extension.

[philippun1]

@charlesg99 If you do not have the time at the moment, you can add me to the team and I can help. And @miigotu as well, he is willing to maintain it. I will keep contributing code.

[IceTrayz]

@miigotu @philippun1

It might be worth starting a new thread on the future of this project in case this one gets closed.

[jderose9]

As it stands it doesn't look like we have one as @jderose9 no longer has time for the project and @charlesg99 hasn't bothered to tell us what is happening with the project, he removed the paypal donation link and applied a couple of commits months ago and that's about it.

If it is helpful, I'd offer to coordinate releases by reviewing pull requests, gathering the translations, release notes, etc. and deal with packaging issues, as I was doing before, but that's quite a bit of effort itself. Realistically I don't have time to keep up with all the breaking changes on every Gnome release as well. I can try to reach out to @charlesg99 and see if he wants to add me back to the project.

When a breaking change happens upstream, it's not generally sufficient to hack around it. The reason for the upstream change needs to be understood (as sometimes they were unintentional and get rolled back), all of the features and configuration permutations that might be affected in dash-to-panel need to be addressed, and backwards compatibility needs to be considered. So, someone else will need to volunteer to own that process.

[miigotu]

As it stands it doesn't look like we have one as @jderose9 no longer has time for the project and @charlesg99 hasn't bothered to tell us what is happening with the project, he removed the paypal donation link and applied a couple of commits months ago and that's about it.

If it is helpful, I'd offer to coordinate releases by reviewing pull requests, gathering the translations, release notes, etc. and deal with packaging issues, as I was doing before, but that's quite a bit of effort itself. Realistically I don't have time to keep up with all the breaking changes on every Gnome release as well. I can try to reach out to @charlesg99 and see if he wants to add me back to the project.

When a breaking change happens upstream, it's not generally sufficient to hack around it. The reason for the upstream change needs to be understood (as sometimes they were unintentional and get rolled back), all of the features and configuration permutations that might be affected in dash-to-panel need to be addressed, and backwards compatibility needs to be considered. So, someone else will need to volunteer to own that process.

Ideally a workflow should exist that compiles releases on tags pushed that reference a tag on master. It should be built and released to extensions.gnome.org, Github packages, a ppa, and any other endpoint we can provide and maintain... automatically. Everything should be merged to a devel or even a nightly branch between releases, and release a nightly/devel package automatically for people to try when things aren't working for them.

After that, we should find a way to better track changes in gnome-shell/gjs. Even if we have to build a custom tool to track commits to their repository and check diffs for what symbols/items we need to hook into.

[jderose9]

Ideally a workflow should exist that compiles releases on tags pushed that reference a tag on master. It should be built and released to extensions.gnome.org, Github packages, a ppa, and any other endpoint we can provide and maintain... automatically. Everything should be merged to a devel or even a nightly branch between releases, and release a nightly/devel package automatically for people to try when things aren't working for them.

After that, we should find a way to better track changes in gnome-shell/gjs. Even if we have to build a custom tool to track commits to their repository and check diffs for what symbols/items we need to hook into.

Those things mostly exist. Still, someone has to decide which changes will make it in a release, notify translators of an upcoming release, review translations, review outstanding pull requests, test multiple permutations of configurations compatibility with multiple versions of multiple distros.

GNOME extensions monkey patch the running desktop environment. Any changes upstream can potentially break the extension because it is essentially replacing the guts of private classes. There's close to no code-freeze time period up-stream and as I mentioned, even a minor release of gnome can break the extension. It can be only a couple of days between commit and hitting the machines of arch and tumbleweed users.

The biggest issue is that someone has to fix the problem, with code that maintains backward compatibility, test it, and send it through the manual GNOME extension review process. It sounds nice to say that the community can review the development branch, but generally speaking, people on an LTS distro don't test the development branch, and people on a rolling distro don't test for backward compatibility, so someone needs to make sure it happens. Otherwise, the stable distro machines will break as they all get their extensions from the same source (e.g.o).

[IceTrayz]

Great to see you back jderose9, Thanks for trying to keep your project going even though it sounds like there isn't a clear way forward with the way gnome keeps changing things about and breaking dash-to-panel.

Couldn't some of the dash-to-dock commits be used as a base to fix dash-to-panel?

[philippun1]

@jderose9 The biggest problem at the moment is not to fix the problems. I.e., the gnome 42 fixes are ready (for a while now), but they are not being merged into the main branch. There are also enough eyes on the Pull Requests to find (most) bugs and regressions. But someone has to merge the branches and create the versions.

So in my opinion the team has to grow or the project will ultimately be forked at some point. Gnome 42 has been released and many people are waiting for a release...