Description of problem: When Gnome desktop environment is started, a pop-up error message says: "HPLIP Status Service: No system tray detected on this system. Unable to start, exiting". This is what I can find in journaltcl: nov. 01 10:14:23 bifrost hplip-systray.desktop[8479]: error: No system tray detected on this system. Unable to start, exiting. nov. 01 10:14:23 bifrost /hp-systray[8479]: hp-systray(qt5)[8479]: error: No system tray detected on this system. Unable to start, exiting. nov. 01 10:14:23 bifrost org.gnome.Shell.desktop[6444]: Window manager warning: Invalid WM_TRANSIENT_FOR window 0x1a00008 specified for 0x1a00006 (HPLIP Stat). Version-Release number of selected component (if applicable): $ rpm -qa | grep hplip hplip-hpijs-ppds-3.18.9-1.mga7 hplip-3.18.9-1.mga7 hplip-hpijs-3.18.9-1.mga7 hplip-gui-3.18.9-1.mga7 hplip-model-data-3.18.9-1.mga7 and gnome-3.30.0-2.mga7 How reproducible: Always. Just open a session in Gnome desktop with your up-to-date Cauldron. Please note: this message doesn't show up when opening a session in KDE Plasma.
(In reply to Sébastien Morin from comment #0) > > How reproducible: > Always. Just open a session in Gnome desktop with your up-to-date Cauldron. > > Please note: this message doesn't show up when opening a session in KDE > Plasma. Assigning to the Gnome maintainers, then.
CC: (none) => marja11Assignee: bugsquad => gnome
Not sure whether this is the right place to complain, but testing M7beta1 Classic ISO Gnome desktop from GDM, there is no sign of Systray. Yet programs which leave launchers in it, work. Just that you cannot see them. Gnome Systray used to be hidden in the bottom LH margin, popping out when hovered there. This does not happen now - unless it is hidden elsewhere, which I have not been able to find.
Reincarnation of https://bugs.mageia.org/show_bug.cgi?id=16946 ?
CC: (none) => ftg
Same problem testing M7beta1 Live Gnome installation. This must be fixed, because you think applications have not started when in reality they have - but remain inaccessible. Because the consequence is not trivial, I have raised the bug priority.
Priority: Normal => HighCC: (none) => lewyssmith
The legacy tray has gone for good: https://bugzilla.gnome.org/show_bug.cgi?id=785956 but there's a GNOME extension that may help: https://extensions.gnome.org/extension/1031/topicons/
CC: (none) => mageia
(In reply to Martin Whitaker from comment #5) > The legacy tray has gone for good: > https://bugzilla.gnome.org/show_bug.cgi?id=785956 This is hopeless. Many applications (especially KDE, also Mageia network thingies) do not pop a window, but put themselves in Systray for activation on-demand. Not having it, one is not only unaware that they are running, but you have no access to them! Unless I have missed something... > but there's a GNOME extension that may help: > https://extensions.gnome.org/extension/1031/topicons/ "This extension moves legacy tray icons (bottom left of Gnome Shell) to the top panel." This looks ideal, since it makes the Systray like for the other desktops. Can we not install it as standard? So many questions (which could become bugs) are caused by this loss of Gnome Systray. Something for the Gnome maintainer(s).
An enhanced version of that extension is already packaged as gnome-shell-extension-topicons. I've added it to rpmsrate so that it will be selected by a default install. I think the user will still have to turn it on manually, but I'll try to make that automatic on the Live ISO.
*** Bug 24302 has been marked as a duplicate of this bug. ***
CC: (none) => brtians1
(In reply to Martin Whitaker from comment #7) > An enhanced version of that extension is already packaged as > gnome-shell-extension-topicons. I've added it to rpmsrate so that it will be > selected by a default install. I think the user will still have to turn it > on manually, but I'll try to make that automatic on the Live ISO. Nice But that solve the issue only for the users who fresh mga7 install. That doesn't solve the issue for the users who do upgrades from previous mga installations. Adding a requires or a recommends somewhere (task-gnome-minimal) would be better.
CC: (none) => thierry.vignaud
I didn't want to make it a requires, as some users might not want it. And would a recommends have any effect on upgrade?
Recommends will have an effect on upgrade. But if done on CLI with --no-recommends (or "no-recommends" in /etc/urpmi/urpmi.cfg)
OK, I've added it as a recommends for task-gnome-minimal. It's still needed in rpmsrate to get it included on the CI ISO.
There'll still be one issue for upgrade users: the extension will be disabled by default but I'm not sure what we can for that
(In reply to Thierry Vignaud from comment #13) > There'll still be one issue for upgrade users: the extension will be > disabled by default but I'm not sure what we can for that We could create a mageia-gnome-config package that enabled it by default. It just needs to add two files: /etc/dconf/db/local.d/00-extensions: [org/gnome/shell] enabled-extensions=['TopIcons@phocean.net'] etc/dconf/profile/user: user-db:user system-db:local and run 'dconf update' post-install.
BTW, that would also be needed to have the extension enabled by default in clean installs.
(In reply to Martin Whitaker from comment #14) > We could create a mageia-gnome-config package that enabled it by default. It > just needs to add two files: Changing dconf is not the correct way to do it. Dconf is an implementation detail, what you're after is gschema. See mageia-theme and the gschema override. Anyway, the solution of this bug is fairly strange. Instead of ensuring that topicons is installed for the packages which need it every GNOME installation will now have a TopIcons extension.
CC: (none) => olav
(In reply to Olav Vitters from comment #16) > Changing dconf is not the correct way to do it. I followed the advice here: https://help.gnome.org/admin/system-admin-guide/stable/extensions-enable.html.en > Anyway, the solution of this bug is fairly strange. Instead of ensuring that > topicons is installed for the packages which need it every GNOME > installation will now have a TopIcons extension. The packages that need it are not GNOME specific, so I don't know how to achieve that. If you have a better solution, go ahead and implement it.
(In reply to Martin Whitaker from comment #17) > (In reply to Olav Vitters from comment #16) > > Changing dconf is not the correct way to do it. > > I followed the advice here: > > https://help.gnome.org/admin/system-admin-guide/stable/extensions-enable. > html.en That's a sysadmin guide, not a packagers one. > > Anyway, the solution of this bug is fairly strange. Instead of ensuring that > > topicons is installed for the packages which need it every GNOME > > installation will now have a TopIcons extension. > > The packages that need it are not GNOME specific, so I don't know how to > achieve that. > > If you have a better solution, go ahead and implement it. You're now changing the behaviour of GNOME for everyone for one specific problem. A proper solution is indeed not easy, however just doing something is also a bit problematic.
(In reply to Olav Vitters from comment #18) > That's a sysadmin guide, not a packagers one. As already said, if you know a better solution, go for it. > You're now changing the behaviour of GNOME for everyone for one specific > problem. All I've done is ensure the extension is installed by default (and the user can override that). How does that change the behaviour of GNOME, if the user doesn't enable it? And if we do automatically enable it, how does that change the behaviour if there are no applications that use the legacy systray? And this "one specific problem" includes the Mageia tools (mgaapplet, net_applet) we install by default. > A proper solution is indeed not easy, however just doing something > is also a bit problematic. IMO, doing nothing, and providing users with broken tools, is worse.
I am pleased about the progress of this Gnome add-on. As an occasional Gnome *user*, I see nothing but benefit to: - Installing this pseudo-Systray add-on as standard (done). - Turning it *on* by default (to do). Here is why. The M6 Gnome hidden Systray was criticised because it *was* hidden: - you had to know it was there, - how to unearth it (simple though it was). All other desktops have a Systray of some sort. My understanding of this new one is that it will integrate in the top taskbar, so not demand significant extra space. Why should anyone complain about that? Especially as it seems that it can be *disabled* by Gnome purists who do not want it. Providing it disabled is no help to people who might like it but simply do not know it is potentially there, nor how to expose it. In this case, opt-out is better than opt-in. BTW Can one currently install it on M7 to test? And how to show it if it is not by default operational?
I'm not a GNOME user, but I have installed it on a laptop running Cauldron, so I would be glad to help testing it. What should I install exactly?
To test, install the gnome-shell-extension-topicons package. Then, from the Applications menu, run the "Tweaks" application, select "Extensions" in the sidebar, and enable the "Topicons plus" extension. Whilst there, you can also click on the cogwheel icon to change some settings, e.g. the position of the system tray on the top panel.
M7beta2.2 x64 Classic install updated, Gnome (Wayland) desktop from LightDM. Thank you Martin for all your work on this. Re your previous comment: 1. To my surprise, I already had gnome-shell-extension-topicons-22-1.mga7 without asking for it: gnome-shell-extension-topicons-22-1.mga7 Where did it come from? 2. To my disappointment, I did *not* have gnome-tweaks, so had to install that manually: gnome-tweaks-3.30.2-3.mga7 3. Then followed your instructions (but who could guess?) and deliberately ignored the cogwheel options to see what would happen. 4. Logged out/in for precaution. Lo! A systray - in the middle of the top taskbar. Showed immediately the working network icon. *No* HPLIP complaint => bug resolved fixed. Well done. 5. Since we are used to it on the right, I re-did the instructions to move the placement to the right - which happened immediately. And soon, a Mageia update icon appeared. I did them, it changed appropriately (but then disappeared). This is a superb resolution: familiar & unobtrusive. Only real Gnome purists could object; why would anyone complain? The instructions become: - Make sure you have, or install: -- gnome-tweaks -- gnome-shell-extension-topicons (which need to depend on the tweaks) - Then as per comment 22. I did not test the necessity of logout/in. which is all a bit heavy & obscure, and how do you tell people? Better would be, when installing Gnome, automatically add the two packages (dependencies); the extensions are often recommended anyway. And if possible, pre-configure the Systray to be on the right. Trying $ ls -alR | grep gnome I could not see a likely config file candidate. I refrain from closing this in the hope that the package tweaks I note might happen. It certainly fixes the problem as-is if you follow the tortuous path; better that all that comes out-of-the-box.
gnome-tweaks wasn't included on the CI ISO, but I have made sure it will be on the next ISO build.
(In reply to Martin Whitaker from comment #22) > To test, install the gnome-shell-extension-topicons package. Then, from the > Applications menu, run the "Tweaks" application, select "Extensions" in the > sidebar, and enable the "Topicons plus" extension. Whilst there, you can > also click on the cogwheel icon to change some settings, e.g. the position > of the system tray on the top panel. I am confirming that this bug is fixed. Just like Lewis did, I installed gnome-shell-extension-topicons and gnome-tweaks. Then I followed Martin's directions and as I activated the "Topicons plus" extension, the wifi icon appeared in the top bar. I clicked on the cogwheel to move it to the right endside, then rebooted the system. Logged in into Gnome (Wayland) again and saw the "HP" icon in the top bar. No wifi icon though, which is a little surprising, but I will investigate to find out what happened here :) No more HPLIP error message. Thank you so much! You may close this as fixed.
I remain convinced that to be useful (beyond stopping the HPLIP error), this thing *should* come out-of-the-box with Gnome. I have discovered that Gnome Live does have the two necessary packages, so you can invoke the Systray on demand. Trying to find what file gets changed when invoking it - something must be -, immediately afterwards (it appeared at once, with the Mageia Update icon; no need to logout/in) I did: $ find . -amin -3 [deleted flagrantly irrelevant lines] ./.local/share/recently-used.xbel ./.config/dconf/user xbel is XML of most recently accessed data files; no mention of this thing. user is binary... Searching it with xxd did not help. Trying the same thing in /etc threw up nothing. We may be forced to mention it in Release Notes if it cannot be automated. It matters for Mageia Updates at least. The README warns that it is not maintained...
I agree it should be set up to operate that way, in any Mageia gnome install. Status?
CC: (none) => davidwhodgins
(In reply to Dave Hodgins from comment #27) > Status? If you install from the latest beta2 CI ISOs, the TopIconsPlus extension and the tweak tool will be installed by default, but the extension will not be enabled. If you use the latest beta2 GNOME Live ISO, the extension is enabled by default. I haven't tested an upgrade.
Just did - no issues. This has been fixed from my perspective. thank you
(In reply to Martin Whitaker from comment #28) > If you use the latest beta2 GNOME Live ISO, the extension is enabled by > default. This is really good, Martin. Once again, thank you for doing all this. > If you install from the latest beta2 CI ISOs, the TopIconsPlus extension and > the tweak tool will be installed by default, but the extension will not be > enabled. Live in hope for the next round...
Thanks. If it doesn't work on upgrade due to changes needed in config files in the users home directory, that's something for the errata as the installers are not allowed to alter the home directory files. Closing this bug as fixed. It can be reopened if problems are found later.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
*** Bug 25062 has been marked as a duplicate of this bug. ***