You are not listening. This is the experience that many of us have had on the job that conditions a sort of PTSD paranoia about updates. We constantly worry about them in the back of our minds. It is an unneccesary source of stress. You guys are adding to that stress by not being transparent about updates.
Even the phone (to @red11 's point in a post about design) lets you know when there are system updates.
That is why we would think that.
I’ll put something together.
I think what you are proposing is a Gnome extension with an API similar to gnome-notifications but for system-status-indicators rather than notifications.
A maintenance task would report its status to that extension.
The extension would present a “blinking blue U” in the top right when any of its represented tasks were in need of attention.
Yes, that would do it for me.
This is probably obvious but just in case.
Clicking on the “blinking blue U” would show all the maintenance tasks with their status and recommended action. They would not just do their action.
Thanks for the feedback to help me get on the right track.
Yep, you got the idea spot on.
I’ll also attempt to implement a tooltip that summarizes the rpm-ostree status -v output some way.
The action would be to reboot - when convenient. You will have to live with the blinking until you do. I need that so I do not forget about it.
I will play with the blinking rate so as to not be too annoying - but annoying enough to be effective. Perhaps that will need to be a config item.
On the config page I’ll put a “test settings” button or check box so you can immediately see the results of the settings change.
I said this before but I think it got lost.
There are multiple maintenance tasks.
ujust update actually performs several.
I have a few of my own in my personal Justfile
There are others (things like git pull for specific projects).
I believe the automatic update only does the rpm-ostree update.
I would like somewhere that I can quickly see the status of these tasks.
The automatic update via rpm-ostree is great, I just want to elect to be informed (or not).
Generally, I use systemctl --user timers or path to trigger maintence.
I’ll think about how to incorporate those somehow.
Ideally it would be a list of items on the config page that represent rules to apply
A longer term goal - I’ll start with rpm-ostree at first. But will design with that in mind. Thanks.
I’ll create a separate post when I have a github repo setup later today.
Please watch for it. I like your ideas.
Oh and …
That is exactly my point as well. It will alleviate some stress for me with regards to time management. I can stop worrying about carving out time to get to a good stopping point to do a timely reboot.
ngl I feel like the topic of updates notification should be spun into a new topic, both to keep the thread relevant and for easier visibility for other users not on thread (as well as posterity and rediscoverability later on)
Is it possible to create a new thread and move messages there so that everything is seamless?
Edit: Nice. Here is shortcut to original thread for anyone who needs it btw.
Right, new thread. Here is my two cents: I don’t dislike @phreed’s idea, but I dislike messing around with systemd files[1] so I’d say it should be an interactive ujust dialogue[2] that activates prebuilt systemd files.
Later, it could be incorporated to whatever new system is used for user Welcome Tour / Ublue Configs since we seem to be moving beyond yafti. The only issue is just who wants to put in the works to make it in the first place. I don’t, because I derive satisfaction from seeing updates with my own eyes, so I run System Update manually every other days.
[1] both personally, and also for other users because I can guarantee you even if the person is familiar with Linux, the moment I mentioned it as a solution the average Reddit user on r/LinuxOnAlly or something, they are going to get angry and think it’s stupid
[2] which IMO should also be how extra Swap and, hibernate + disable secure-boot, is configured because it’s still a common request (yours truly included).
I agree with running manually. 90% of the time that is what I end up having to do anyway because the auto-download feature hasn’t worked since early this year some time.
If someone is skilled enough to use systemd units to form their own solution awesome. And if they can share that work with the project so it gets included - even better.
My focus is strictly on a GNOME extension to provide indication that I need to take some action - like reboot, or rebuild my container hierarchy.
That is all I am going to be doing. In a general sense it is just a reporting function.
I’ll be back in an hour or so to paste the link to the new post I promised.
@phreed and anyone that might be interested - here is the post:
An extension for Gnome would be good. However, I am using Aurora so I hope that someone with Plasma dev experience could add something similar. Since this is all related to desktop indicator, it seems that a dbus API could be standardized for this on both DEs.
And if you want to be sure all you have to do is:
systemctl list-unit-files --type timer
Then once you have identified the right timer.
systemctl cat rpm-ostreed-automatic.timer
Which clearly states:
[Timer]
OnBootSec=1h
OnUnitInactiveSec=1d
RandomizedDelaySec=10m
OnCalendar=*-*-* 4:00:00
Persistent=true
(To bad it does not have a reference to the documentation or the documentation to the timer.)
So simple! (aren’t I the funny one)
My intention is to rely on a command to monitor (could be anything you want) coupled with another command that mines the output for data to display.
@Mshrm agreed. But I am not familiar with KDE anymore. I used it for awhile when it first came out (late 1990s?) but it just wasn’t for me.
I’m weird. I really dislike the normal desktop metaphor. I used openbox for awhile, but ultimately settled on GNOME. I turn the dock off, desktop icons off - I want all the available screen real estate for my maximized apps. I have poor eyesite. It’s an ergonomics thing.
I am hoping that the commands approach will be portable enough.
The dbus API idea is interesting though.
So if there are updates emit an event on dbus with the information to display in the tooltip.
Hmmmm - I need to think about this some. I wasn’t planning on making any actions available so that would make even the commands more portable. And uni-directional data flow like that should be straightforward enough.
But, can we please take this discussion over to upd-indicator design discussion before we get into trouble again?
What about even simpler… On top left there is already U icon for Universal Blue, what if we just use this for notifying the update is ready.
On left side no system update. On right side system update is ready. You know when square is filled update is ready. Like when moon gets filled we have full moon.
In this case we don’t need any extensions separately build for Gnome vs. KDE vs. something. We just change an icon (fill the square). We also do not need to be intrusive with some green or red icon. Because such icons require additional tweaks for users that “I don’t want this green icon, I want to turn it off.”
Please join the discussion at the link above.
We are not proposing that this new extension be added to bluefin or Aurora.
Thanks.
Android and ChromeOS both have a notification that tells me that an update is available.
These are however necessary since the update will trigger additional changes during the next boot. The notification doubles as a warning that your next boot might take quite a bit of time.
For the most part, updates do not require additional post update script runs. Our previous update took sent a notification that we ended up turning off pretty immediately. Since all it ended doing was giving people a button to reboot now.
Just turn your computer off every once in awhile. It’ll be fine.
There is more then just the OS that we are interested in. That is just 1 minor piece.
Come join the discussion in my repo to understand the whole picture.
For example, I plan to config my own custom rule to monitor if my local clone of cpython:3.15 is behind or not.
We are also discussing design ideas to make this OS and DE agnostic. That is tougher. But there are some basic tools like systemd and D-Bus available to us.
The icon should be a block B or a 
. Universal blue is a generic branding for many images.
The top left icon is part of logo-menu extension so using that would mean mangling with the logo-menu code (Bluefin has a fork that they use)
I have a fork of LogoMenu that I use too. It is a great example extension, by the way. He has a little of everything in that silly little thing. Lots of Gtk and Gio examples, custom schema for gsettings, multiple language support, etc.
In apt-indicator I ended up choosing ‘selection-mode-symbolic’ when all rules are green, and a slowly flashing (with muted color) ‘software-update-available-symbolic’ when something needs attention.
I’ll have prefs items so they can be changed to whatever else can be found in your GNOME theme.
I am making some good progress. Phase 1 is getting close to completion.
Come provide your feedback at upd-indicator discussion.
And see the demo (gif) at upd-indicator.
