EOPKG Updates Panel Indicator - GNOME Extension

PaperTiger

I'm interested in knowing how to make a GNOME extension for updates, specifically for Solus. It would be similar to the Fedora/Arch/Ubuntu updates indicator that sits on the top panel.

So the question is, how difficult would it be to build, especially for someone with little to no programming experience? I'm thinking something along the lines of forking one of the mentioned indicators and modifying it specifically for Solus.

Additionally, do you think there would be strong interest within the Solus community something like this?

Clintre

PaperTiger Right now I have on Solseek a service that checks for updates and does notifications. It doesn't have an indicator, although I have thought about adding that as it just runs as a background systemd service. Just never got around to making one that would work on all the desktop environments we use.

You can look at the code at https://github.com/clintre/solseek
packages/share/solseek/core/pkg_functions just look at the check_updates() function where you will see the call to pkcon which use to check for updates. I had to use that as you can really check for updates easily using eopkg without sudo. Most of the code here is in bash still, so not too difficult to follow.

Then back in packages/share/solseek/ you will see a uc.service and uc.timer. These are the services that run in the background to check periodically for updates.

For an indicator it would not be much different.

Sebastian

PaperTiger I took your inquiry as inspiration to vibe code a Solus Updates-Indicator. But not as GNOME extension. Because with extensions, you run into trouble each time there is an update for GNOME, and they work on GNOME only. So I created an python script. In theory, I have tested in on GNOME, Budgie an Xfce.
It shows a monochrome Solus logo when no updates are available and a logo with color when updates are available. It also shows a list of available updates and can launch a terminal with sudo eokg up to install updates.
For now it expects ptyxis terminal. But this can be changed in the script to the desired terminal. Also, whenever any eopkg instance is running, it will not check for updates and waits for eopkg to be finished to avoid conflicts. This is also true for eopkg history. It will check for updates once per hour. You can also trigger a manual check.

You find the script here
Just save it for instance as solus-updates-indicator.python and run it via python solus-updates-indicator.python.

You can add this to an autostart script to have it launch at login.

Please let me know if it's working for you.

Edit: to test the script if your system is up-to-date just run in terminal sudo eopkg it https://packages.getsol.us/polaris/n/nano/nano-8.7.1-211-1-x86_64.eopkg to install old nano version. Then click on check for updates now to see if it indicates presence of updates.

I should also mention: this version of the script expects you to be on stable repository

PaperTiger

Clintre Will check it out now. Thanks for sharing.

Harvey

A notification for gnome extension updates wouldn't have anything at all to do with eopkg or packagekit since the overwhelming majority of gnome extensions are not and will not be packaged by Solus.

PaperTiger

Harvey Got you. I was thinking of having the extension in the GNOME extensions store, not necessarily having it packaged specifically for Solus, in a similar way that most other GNOME extensions are made available.

PaperTiger

Sebastian Man, this is absolutely super!!! You have created the perfect indicator that is desktop agnostic. This is really thoughtful of you. I made the following three minor tweaks for my own situation.

Firstly, since I use ghostty as my terminal I adjusted the script accordingly.
Secondly, my preferred shell is zsh so that too was adjusted.
Finally, I adjusted the update command so that when update process is finished the user is prompted to click enter to close.

Everything works perfectly and I have it running as a systemd user script. Thanks a million, as I believe these small tweaks can assist in making Solus a breeze for new users.

Sebastian

PaperTiger Thank you. The script isn't perfect, but it works actually fine.
The one thing that bothers me the most is: it might slightly change position in panel, because the list with packages wasn't showing in Budgie panel and the solution was to somehow reload the entire indicator menu / reregister the indicator.
Meanwhile: there was a packagekit update that removed pkcon in favor of pkgcli. The first version of the script relied on pkcon for getting info about updates.
So I reworked the script that it keeps working with the new packagekit/pkgcli.
Your script will have stopped working by now.

I also had noticed when testing the script that the list with the packages wasn't scrollable in niri with dankmaterialshell. And that scrolling a list in the panel with many packages to update might suck, while it is handy when there are only a few updates available, which might be the case on unstable, when you update frequently.
So, the new version of the script works without modifications on stable and unstable repo.
And I added an option to show available updates in a separate window, that is easier to scroll.
At the beginning of the script you can set whether you want extra window or drop-down list as previously, or both.
When testing with other terminals there was an issue because different terminals interpret arguments differenty, and the update-command wouldn't run in alls terminals. To fix this the script generates an custom script in /tmp and the chosen terminal executes this script. This ensures compatibility with all terminals.
I also added a section in the beginnning of the script where you can set your preferred shell. I didn't change that the terminal stays open after update, because this way you can study terminal output when updates are finished without the risk of closing terminal by accidentally hitting enter.
I also added an option to show security updates before normal updates.

Link to updated script version.

Edit: I have edited the link once more as the check for running eopkg instances before checking for updates didn't work properly

Edit2: some scammers added a comment to the comment section of my pastebin

It's a phishing scam: Do Not click on the link in that comment.
I have reported that comment to pastebin, but cannot remove it myself.

Sebastian

PaperTiger Everything works perfectly and I have it running as a systemd user script.

How does that work? Does it kind of autostart then? can you share?

PaperTiger

Sebastian What I did was to create a file named solus-updates-indicator.service containing the following:

[Unit]
Description=Solus Updates Indicator
After=graphical-session.target
PartOf=graphical-session.target

[Service]
Type=simple
ExecStart=/usr/bin/python3 /home/**USERNAME**/.solus-updates-indicator.py
Restart=on-failure
RestartSec=5
Environment=DISPLAY=:0
Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%U/bus

[Install]
WantedBy=graphical-session.target

Note that my target file is hidden, hence ".solus-updates-indicator.py". Don't forget to point the file to the actual location of your python script. Having done that, create the user systemd directory if it doesn't exist:
mkdir -p ~/.config/systemd/user/

Now, copy the service file into place:
cp solus-updates-indicator.service ~/.config/systemd/user/

Reload systemd so it sees the new file
systemctl --user daemon-reload

Next, enable it to start automatically at login
systemctl --user enable solus-updates-indicator.service

You can also start it immediately without rebooting
systemctl --user start solus-updates-indicator.service

The following commands may also prove to be useful:

Check status

systemctl --user status solus-updates-indicator.service

View logs

journalctl --user -u solus-updates-indicator.service

Stop service

systemctl --user stop solus-updates-indicator.service

I tested everything this morning with the updated python script and everything worked perfectly with significant updates being done. I'm a happy camper.

AlterNez

Hello!

I know this thread has already been marked as Resolved, but I’ve just stumbled across this script and, as I’d also been thinking about creating an extension along the lines of ‘Solus Updates Indicator’, I couldn’t resist giving it a go.

However, once I had the script in my hands, and with a similar adjustment to the user above (swapping bash for zsh), I get the following error when trying to check for updates:

╰─$ python3 Solus\ Updates-Indicator.py                                                                            
Update check failed: [Errno 2] File or directory does not exist: “pkcon”
Update check failed: [Errno 2] File or directory does not exist: “pkcon”

I know Packagekit is still installed because it’s integrated with Gnome, so I’m quite confused here.

Does anyone have any idea what’s going on?

stocc

AlterNez You need to install the updated version of the script (3 posts above this one). pkcon has been replaced by pkgcli, which the updated version has addressed.

Sebastian

AlterNez Have you tried the latest version of the script as in this link?

AlterNez

Sebastian
Oh, thank you. I didn’t realise there was a more up-to-date version. Everything’s working fine now.

English isn’t my first language, so I wasn’t quite sure whether there was a way to update it directly or not.

Thanks for your help

Axios

This is what makes Solus great!!
When users become involved and at least get it documented in forum for the
advantage of others.
And thank you to those people.
Truck on!

PaperTiger

I've made some changes to the script to suit my own situation and preferences. I'm sharing because I believe others may find it useful. Among the adjustments I made are the following:

Header bar — swapped the plain window title for a Gtk.HeaderBar. This is the proper GTK3 mechanism for placing controls in the title area, and it means the close button also moves up there (standard GNOME convention), so the old bottom "Close" button was removed.
Pill shape — a minimal CssProvider is injected with a single rule: border-radius: 9999px on the .apply-pill class. This rounds the button into a capsule without touching any other styling. The handler disconnects itself immediately (prevents double-clicks mid-install). Once clicked, the button goes insensitive and relabels to "Installing…" While updates are installing, a progress bar is revealed at 0 % and expands to fill the space between the version and repo columns. Then pkexec eopkg up --yes-all is launched in a background thread — pkexec shows a native polkit authentication dialog, no terminal needed. When finished: the status label updates with the outcome, the button becomes "Done" and clicking it closes the window. A background check is also triggered to refresh the tray icon count.
Desktop theme colour — the button gets GTK's built-in suggested-action class, which automatically adopts whatever accent colour the active desktop theme defines (blue on Adwaita, green on Budgie's default, etc.). No hardcoded colours are used, so it will look native on any Solus desktop.
Active/inactive state — btn_apply.set_sensitive(has_updates) handles everything: GTK automatically renders the button greyed-out when insensitive, and fully themed when active.
Changelog tooltips — hovering a package row could show its release notes if eopkg exposes them
Selective updates — checkboxes per row so the user can choose which packages to apply, passing the selection to eopkg install rather than eopkg up
Notification on new updates — using gi.repository.Notify to send a desktop notification when the background check finds something new
Auto-start on login — a small .desktop file dropped into ~/.config/autostart/ so the tray icon appears automatically
Flatpak: flatpak checking and updating

See below for a screenshot:

File can be downloaded from https://pastebin.com/wbDGXT0c

Sebastian

PaperTiger Changelog tooltips — hovering a package row could show its release notes if eopkg exposes them

You can use pkgcli show-update --quiet PACKAGENAME for that.
That's what I have used for the extra window on double click with info about that package's updates.

Sebastian

PaperTiger Just tested your script. Man, that looks nice too. So many cool details. Like

I mean, I don't plan to have that, as I intend to stay eopkg only. And I won't implemet selection of single packages.
Not sure If that makes much sense for the updates.
But I gotta say, it feels well-thought-out and with an eye for details.

Are you vibe-coding like me, or do you actually know python and edit the code yourself?

Sebastian

PaperTiger Additional feedback: just unselected the flatpak and clicked on apply.
What I really like is the pkexec thing with native polkit authentication dialog. Thats pretty cool. Will implement that too.
What I didn't like. The installation process starts in background, and not in terminal. You kind of lose control of what's happening at that point. That's exactly why I don't use discover/GNOME software and need an updates indicator in the first place.
But that's up to you, of course, if that's your preference.

Sebastian

Nice work.

I was also working on my script and will share code soon. Still working on some quirks.
The more features you add, the more issues you get you haven't thought of. Need some more testing.
Will probably post my script in a seperate post when time has come.
I decided deliberately against flatpak integration. I aim to have a pure eopkg system updates indicator.
I worked on the logic to when check for updates itself, will give more detail when I share the code.
I added a install button to the seperate window view. I added function to double click on row in extra window to get details for the update for the package in question.
I created a desktop file. So you can start indicator from startmenu and put in easily in DE's autostart. And so that de extra windows you open identify as updates indicator in dock/GNOME dash.
And most importantly I added a settings dialog and moved settings like update interval, terminal, shell, icons, etc to a proper congig file in ~/.config/solus-updates-indicator so that when I share the code, no one has to actually edit the script itself anymore for settings.

It's getting pretty cool.

Edit:
forgot to mention: I added addtional icons so that indicator icon not only indicates updates/no updates, but also others states of the script like checking for updates in preogress, waiting for eopkg to terminate before checking for updates, waiting for password for eopkg up, installation in progress. Plan to implement check for network connection when checking for updates and add icon for no network connection.

I also plan to grey out menu items that shouldn't be active when updates or checking for updates is in progress.

Will take a look at your others improvements and see if I can adopt some of them.

Edit2:
Well, what the heck, here is what my current code looks like. But as I said. I still need some testing. And gonna implement one or two more things.

Sebastian

Sebastian I worked on the logic to when check for updates itself, will give more detail when I share the code.

My code contains a logic now that it not only checks for updates accordingly to the intervall in the settings. But it also checks every 45 secons while that intervall is running(if no eopkg instance is curently running) if the transaction number in eopkg history has changed:
sebi@solus ~ $ eopkg history -l 1 | grep "#" Vorgang #1201: Depot Update sebi@solus ~ $

If the number has changed, there must have been an eopkg operation been running like install, remove, update, rollback not triggered by the script itself, but by the user in terminal or with gnome software, discover.
In that scenario, the indicator might show a wrong status. I.E it shows updates that already have been installed, or doesn't show updates that are availabe.
So, if the transaction number has changed, the script triggers a check for updates immediately and kind of resets the intervall timer.

I plan to add an additional check. Let's say you have set timer to 60 minutes. The timer is at 15 minutes. You then suspend computer. Next day you get back to computer. Now timer would check in 45 minutes if updates are available, that might be already be available for 12 hours.
That's why I plan to add a check along with the has transactional number changed check: is last check for updates longer ago than the time set in interval. If so, computer must have been in suspend, and you better trigger check for updates now.