projecthamster / hamster-shell-extension

Shell extension for hamster
http://projecthamster.org
GNU General Public License v3.0
217 stars 92 forks source link

Support for GNOME 45 #362

Closed mwilck closed 7 months ago

mwilck commented 1 year ago

We need to add support for GNOME 45.

I've pushed pushing my code with GNOME 45 support to the 362-support-for-gnome-45 branch branch in this repository.

The branch seems to work. I'm using it right now. Please test and please post any issues here.

mwilck commented 1 year ago

@hedayat for information.

hedayat commented 1 year ago

Thanks for starting the work. I didn't know about that, but I'll most likely upgrade to latest Fedora Beta tomorrow, which comes with gnome 45. So, I'll try to help as much as I can (might not be much though, at least for a few days).

mwilck commented 1 year ago

I've just pushed an update.

Good news

The extension is displayed in the panel, and the pop-up shows and works as far as I've tested. Screenshot from 2023-09-24 23-36-39a

The settings can be opened from the GNOME extensions tool and look ok-ish

image

Not-so-good news

The settings aren't applied correctly yet. The "global hotkey" entry doesn't work at all. (Note that I basically had to re-write the preferences dialog from scratch, copying code from the "window-list" standard extension).

hedayat commented 1 year ago

Thanks a lot. Unfortunately, I've not yet started using Gnome 45, and cannot test the code till tomorrow. But I guess it's completely working till then :sweat_smile:

mwilck commented 1 year ago

The settings dialog works now, too. It's still necessary to logout and relogin to apply the settings, and one day we should fix that, but it's no different from the current behavior until GNOME 44 and earlier.

I've created #363 in preparation of a GNOME 45 PR. Anyway, even if testing by you and hopefully other people is successful, we need to discuss how to proceed further. GNOME 45 support is exclusive and means that no prior GNOME shell version can be supported. Therefore I suppose the develop branch will keep supporting the older versions for some time to come, and will create a gnome-shell-45 branch.

mwilck commented 1 year ago

Re-pushed the branch to 6d31a9b, as I'd made a mistake rebasing it.

hedayat commented 1 year ago

Thanks a lot! :)

Therefore I suppose the develop branch will keep supporting the older versions for some time to come, and will create a gnome-shell-45 branch.

I suggest the other way around: create a branch for older versions (e.g. gjs-version or pre-gnome-shell-45) and let develop contain latest code.

hedayat commented 1 year ago

Well, just so that we have a now almost meaningless master branch too. If we want to keep that around, I think it can contain current develop branch which is compatible with 44 and below, and then develop branch can contain gnome-shell 45 compatible code until it is considered release quality.

mwilck commented 1 year ago

Right. I thought the original idea was to have master in line with e.g.o. But both have bitrotted so much now that it's kind of meaningless.

If we follow your suggestion, I could actually create a PR against develop, which would simplify the review process on GitHub. So yeah, I am in favor of it.

mwilck commented 1 year ago

There are 2 problems: current master is not an ancestor of develop, so we can't fast-forward it (the differences are few and mostly related to commit messages, but they aren't zero). Also, IIRC, @elbenfreund has locked the master branch, so that nobody except himself can do merges or other updates to the branch (I haven't tried in a long time, though) [^json].

Notifying all members of @projecthamster/gnome-shell-extension here for follow-up discussion.

[^json]: I found that our past team discussions are now only available in an awkward json format, which is very hard to read.

hedayat commented 1 year ago

Well, maybe its time to create a main branch if @elbenfreund is not available. :D

matthijskooijman commented 1 year ago

I've tried a few times over the past few years to send @elbenfreund e-mail asking for some changes or transferring some rights, but have not received any reply to those. I wonder if it might be worth considering migrating to a new and separate organization to work around such limitations, but that's probably something to discuss elsewhere (maybe organisation-wide, though organisations do not seem to have (public) discussion options).

benjaoming commented 1 year ago

This is always a huge problem, not to mention that the extension doesn't even have a proper official package on Gnome. I've followed the conversation and all the issues over the years and I could totally get behind a reboot, mainly in terms of governance and distribution. I think renaming the project[1] would help to free up various namespaces in the distribution chain.

[1] for instance to a similar animal that likes running around in wheels, example: "chinchilla"

mwilck commented 1 year ago

I wonder if it might be worth considering migrating to a new and separate organization to work around such limitations

I thought the same.

but that's probably something to discuss elsewhere (maybe organisation-wide, though organisations do not seem to have (public) discussion options).

This project doesn't have GitHub discussions, because @elbenfreund would need to enable it, and we're back at square one.[^disc]

[^disc]: We used to have "team discussions" but GitHub has dropped the feature in favor of the new GitHub discussions, that's where the "awkward json" mentioned above comes from.

I guess we agree that if we move to a different organization, we should move the entire project (at least the currently active repos, i.e. "hamster" and "hamster-shell-extension").

About changing the name: I'm unsure if that's a good idea. People will be looking for "hamster", both on e.g.o and elsewhere. AFAICS, nobody owns the name "hamster", and if anyone did, it would probably be @tstriker. IMO we could simply fork the active repos and keep using the name "hamster", as long as we keep true to the spirit of the project (which I think we have done so far).

tstriker commented 1 year ago

the name 'hamster' ('project hamster', specifically) is not copyrighted and nobody owns it so please keep using it if you want - the name was a reference to the hamster wheel and is a tongue-in-cheek reference to 9-to-5 work.

if elbenfreund has gone missing, you might want to reach out to github support - they might allow transferring the project ownership to a new team. until then you can also just abandon 'master' as github deprecated those in favor to 'main' a while ago anyway.

alternatively, of course, you could make a fork org and leave a message somewhere pointing to it but that might be messier.

Note: i unfortunately don't have extra cycles so i won't be monitoring this nor any other conversations relating to project hamster; i've now set up an auto-filter to keep these out of my inbox.

Good luck!

mwilck commented 1 year ago

Thanks a lot, Tom!

Wrt reaching out to github support, I see that as a last resort. Even if @elbenfreund has turned silent, his contributions are massive and still very valuable, and I wouldn't want to be rude to him. I'd strongly appreciate if he voluntarily assigned someone else (one or more of the currently active people) a maintainer role in this repository though. If he can't or doesn't want to do that, I'd rather move to a fork. That's my personal PoV.

matthijskooijman commented 1 year ago

To prevent further digressing this issue, I've created https://github.com/projecthamster/hamster/issues/730 for further discussion about regaining access to the repositories and organization.

I suggest moving this issue back to supporting gnome 45, and what branches to use (within the current limitations we have wrt repo access).

mwilck commented 1 year ago

Thanks, @matthijskooijman. I suppose the general discussion about the future of the project will take some more time.

Meanwhile, once @hedayat has ultimately approved #363, I will create a PR for merging into master (as we'll certainly won't be able to force-push to master, this will require some manual, local merging on my part). Then we'll see if we can merge into master at all. If not, we can still try to create a "main" branch, but we won't be able to change the fact that "develop" is currently the default branch.

mwilck commented 1 year ago

I pushed another commit to the 362-support-for-gnome-45 branch, fixing an issue that occured when disabling the extension.

hedayat commented 1 year ago

Well, I finally got to test this, but I need to see if I can fix hamster python 3.12 compatibility first...

hedayat commented 1 year ago

OK, I'm finally able to use the extension under Gnome 45, and so far so good :) At least all functionality I used before are working fine. Thanks!

hedayat commented 1 year ago

Well, there is one thing. When I select "Add earlier activity", it opens the dialog with the current time selected as the start time, which is an inconvenience sine you almost always want to change it. It's better to remain like previous version: with no start time so that we can write the desired number right away (for me, usually start with time diff; e.g. -120)

mwilck commented 1 year ago

I haven't changed anything in this respect. The version from the master branch behaves the same.

mwilck commented 1 year ago

The "add earlier activity" button just executes the equivalent of

busctl --user call org.gnome.Hamster.WindowServer \
    /org/gnome/Hamster/WindowServer \
    org.gnome.Hamster.WindowServer \
    edit i 0

which also comes up with the current time as start time. So this must be a change in hamster itself, I think.

hedayat commented 1 year ago

Oh, yeah, thanks!

So the behavior has changed. Previously, it was either empty, or the current time was selected so that you could type what you wanted right away. I'll try to find-out when it has changed in hamster itself!

nmaggioni commented 1 year ago

This branch is working fine for me too on GNOME 45, thanks for your efforts.

mawe42 commented 1 year ago

I'm using this branch under GNOME 45 and it's working fine. Thanks a lot for maintaining this extension, I use it every day!

yobuntu commented 12 months ago

hello, thank you for this great work (for the extension in general and this particular PR). Is there any chance to see this merged on main soon ? (Gnome 45 is the current gnome version on archlinux, and it would be great if i could update the aur package with this work)

mwilck commented 11 months ago

Sorry for the long delay. As discussed previously, I have now created #364.

lefterav commented 10 months ago

I am using the GNOME 45 version and I get some errors. Can somebody advise, where to get the logs, so that I submit the respective issues here?

jacek-pliszka commented 10 months ago

Hi! I am also using GNOME 45 and I had some errors at the beginning but they somehow disappeared later. Ensure that your hamster runs correctly without the gnome shell extension first.

mwilck commented 10 months ago

I am using the GNOME 45 version and I get some errors. Can somebody advise, where to get the logs, so that I submit the respective issues here?

Can you be a bit more specific? If you "get some errors", you must have seen something going wrong. What?

Wrt logs, journalctl -b --user is your friend.

lefterav commented 10 months ago

Sure, so every now and then the hamster widget disappears. The message at journal is

Jan 13 15:43:37 nubi gnome-shell[1020865]: Shutting down hamster-shell-extension.
Jan 13 16:20:11 nubi gnome-shell[1020865]: Shutting down hamster-shell-extension.
Jan 13 16:59:35 nubi gnome-shell[1020865]: Shutting down hamster-shell-extension.
Jan 13 17:29:06 nubi gnome-shell[1020865]: Shutting down hamster-shell-extension.

Then I went to extension manager, I disabled and re-enabled the hamster extension from the switch. The Extension manager displayed a red dead-end sign and the switch became inactive, displaying the following error:

image

at the same time, the journal reported the following:

Jan 13 18:10:54 nubi gnome-shell[1020865]: Window manager warning: Trying to remove non-existent keybinding "show-hamster-dropdown".
Jan 13 18:10:54 nubi gnome-shell[1020865]: Shutting down hamster-shell-extension.
Jan 13 18:10:54 nubi gnome-shell[1020865]: JS ERROR: Extension contact@projecthamster.org: TypeError: this.panelWidget is null
                                           _removeWidget@file:///home/elav01/.local/share/gnome-shell/extensions/contact@projecthamster.org/extension.js:278:13
                                           disable@file:///home/elav01/.local/share/gnome-shell/extensions/contact@projecthamster.org/extension.js:191:14

I haven't found another way to make the widget visible apart from logging out of the gnome session and logging in again.

mwilck commented 10 months ago

@lefterav: I can't reproduce this. I can disable/enable the extension just fine. This must be caused by the extension being shut down in your environment. Maybe you can shed some light on why this happens?

Anyway I think this should be tracked in a separate issue.

jacek-pliszka commented 10 months ago

In my case:

  1. there were 2 other extensions breaking it
  2. I had problems with flatpack version - once I build rpm and installed it - it worked fine
lefterav commented 10 months ago

I also just received the following message, but Hamster applet is still running image

lefterav commented 10 months ago

@lefterav: I can't reproduce this. I can disable/enable the extension just fine. This must be caused by the extension being shut down in your environment. Maybe you can shed some light on why this happens?

Anyway I think this should be tracked in a separate issue.

Starting a separate issue

365

hedayat commented 7 months ago

OK, I'd say this issue and related PR has been lingering too much, now that Gnome 46 is also released. And while I guess we didn't expect, it has breaking changes again. So, I guess we should move on, and have a tagging/branching strategy for each time we break compatibility.

matthijskooijman commented 7 months ago

Didn't we formulate a branching strategy for this already a long time ago?

In any case, merging would still be useful so we have a version that supports gnome 45 and not just gnome 46, but maybe it should be merged to another branch, then.

hedayat commented 7 months ago

Didn't we formulate a branching strategy for this already a long time ago?

TBH, I don't remember. If we have, then everything's fine :)

In any case, merging would still be useful so we have a version that supports gnome 45 and not just gnome 46, but maybe it should be merged to another branch, then.

Yeah, maybe I didn't communicate my intention correctly. I said this issue/PR is lingering too much, I meant that we should merge it ASAP. And as you said that we already have a branching strategy, let's follow it and properly have a merged Gnome 45 support code, and then go with reviewing Gnome 46 PR.

hedayat commented 7 months ago

@mwilck Sorry, I guess I missed something. Shouldn't we also have a separate tag for gnome shell 45? I doubt the current develop works on 45 (but I've not tested).

andypost commented 7 months ago

@hedayat for 45 it needs to patch

--- metadata.json
+++ metadata.json
@@ -9,9 +9,7 @@
     ],
     "gettext-domain": "hamster-shell-extension",
     "settings-schema": "org.gnome.shell.extensions.project-hamster",
-    "shell-version": [
-        "46"
-    ],
+    "shell-version": ["45", "46"],
     "url": "https://github.com/projecthamster/hamster-shell-extension.git",
     "uuid": "contact@projecthamster.org"
 }
hedayat commented 7 months ago

@andypost And... does it actually work? I intentionally removed 45 from metadata.json, since some APIs were changed and I doubt they also exist in gnome shell 45 (unless gnome 45 provides both old and new APIs).

andypost commented 7 months ago

I did switch to 46 and it was working

hedayat commented 7 months ago

Oops, sorry if I wasn't clear enough. I mean, does the latest code, which works on 46, also work on 45 correctly if 45 is added to metadata.json? The new code might not be compatible with gnome shell 45.

mwilck commented 7 months ago

My bad, I overlooked the fact that you put 46 instead of 45 rather than just adding it.

I'll push an update pretending to support both. Because I had a similar change in another extension, I'm rather confident it will work with both GNOME 45 and 46. But it would be very nice if someone could test that.

mwilck commented 7 months ago

I just pushed this to the "develop" branch to fix my previous mistake. Please test under GNOME 45. If any issues appear, we'll need to branch once more.

hedayat commented 7 months ago

Thanks! Hope it works in 45 too.

matthijskooijman commented 7 months ago

Please test under GNOME 45

I'm still on 45, so I tested develop (I was previously running the branch from #364 without problems). Seems to mostly work, but the list of todays activities is displayed empty in the popup:

image

In the journal I get these when I open the popup, which I think are related:

apr 04 23:28:33 dottie gnome-shell[3036550]: ../clutter/clutter/clutter-actor.c:8802: Actor '<unnamed>[<StScrollBar>:0x5fa74a918780]' tried to allocate a size of 8,00 x -8,00
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<StBoxLayout>:0x5fa74a91b960] is on because it needs an allocation. 
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<StWidget>:0x5fa74a91c880] is on because it needs an allocation.    
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<StLabel>:0x5fa746695b50] is on because it needs an allocation.     
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<ClutterText>:0x5fa748136950] is on because it needs an allocation.
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<StLabel>:0x5fa74851f9a0] is on because it needs an allocation.    
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<ClutterText>:0x5fa74aa9f590] is on because it needs an allocation.
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<StLabel>:0x5fa74603d990] is on because it needs an allocation.    
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<ClutterText>:0x5fa7485ced50] is on because it needs an allocation.
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<StButton>:0x5fa7471e9ad0] is on because it needs an allocation.   
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<StIcon>:0x5fa749c6f9f0] is on because it needs an allocation.      
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<ClutterActor>:0x5fa745893850] is on because it needs an allocation.
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<StLabel>:0x5fa74ac94300] is on because it needs an allocation.     
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<ClutterText>:0x5fa74baa0b10] is on because it needs an allocation. 
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<StLabel>:0x5fa745760f10] is on because it needs an allocation.     
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<ClutterText>:0x5fa7453d6660] is on because it needs an allocation.
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<StLabel>:0x5fa747a378e0] is on because it needs an allocation.    
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<ClutterText>:0x5fa748070750] is on because it needs an allocation.
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<StButton>:0x5fa74aad03d0] is on because it needs an allocation.   
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<StIcon>:0x5fa746091cd0] is on because it needs an allocation.     
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<ClutterActor>:0x5fa746af3ee0] is on because it needs an allocation.
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<StButton>:0x5fa747e06360] is on because it needs an allocation.    
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<StIcon>:0x5fa74aaa1df0] is on because it needs an allocation.      
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<ClutterActor>:0x5fa74561fb80] is on because it needs an allocation.
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<StLabel>:0x5fa748a880b0] is on because it needs an allocation.     
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<ClutterText>:0x5fa748063400] is on because it needs an allocation. 
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<StLabel>:0x5fa7481489b0] is on because it needs an allocation.    
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<ClutterText>:0x5fa74548c680] is on because it needs an allocation.
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<StLabel>:0x5fa74804eae0] is on because it needs an allocation.    
apr 04 23:28:33 dottie gnome-shell[3036550]: Can't update stage views actor <unnamed>[<ClutterText>:0x5fa74593ace0] is on because it needs an allocation.

I looked around the mutter 45.0 source code a bit and it seems like add and add_child are pretty much equivalent really (add is defined on in clutter-container.c, but pretty much only calls add_child defined in clutter-actor.c), but maybe I'm looking at entirely the wrong code...

I might see if I can pinpoint what line in the 46-fix breaks this, but I probably won't have time now to get to the bottom of this...

mwilck commented 7 months ago

Too bad...

@hedayat, to my understanding the replacement of .add_actor() by .add_child() should be well backward compatible. But you also replaced some .add() instances by .add_child(). Did you find this necessary? @matthijskooijman, can you try reverting just the .add() hunks and see if that fixes the issue?