Closed mwilck closed 7 months ago
@hedayat for information.
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).
I've just pushed an update.
The extension is displayed in the panel, and the pop-up shows and works as far as I've tested.
The settings can be opened from the GNOME extensions tool and look ok-ish
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).
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:
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.
Re-pushed the branch to 6d31a9b, as I'd made a mistake rebasing it.
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.
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.
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.
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.
Well, maybe its time to create a main
branch if @elbenfreund is not available. :D
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).
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"
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).
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!
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.
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).
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.
I pushed another commit to the 362-support-for-gnome-45 branch, fixing an issue that occured when disabling the extension.
Well, I finally got to test this, but I need to see if I can fix hamster python 3.12 compatibility first...
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!
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)
I haven't changed anything in this respect. The version from the master branch behaves the same.
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.
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!
This branch is working fine for me too on GNOME 45, thanks for your efforts.
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!
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)
Sorry for the long delay. As discussed previously, I have now created #364.
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?
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.
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.
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:
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.
@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.
In my case:
I also just received the following message, but Hamster applet is still running
@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
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.
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.
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.
@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).
@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"
}
@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).
I did switch to 46 and it was working
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.
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.
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.
Thanks! Hope it works in 45 too.
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:
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...
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?
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.