Bug 23795 - HPLIP "no system tray detected" error with Gnome 3.30.0
Summary: HPLIP "no system tray detected" error with Gnome 3.30.0
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: High normal
Target Milestone: ---
Assignee: GNOME maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
: 24302 25062 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-11-01 07:32 CET by Sébastien Morin
Modified: 2019-07-06 17:56 CEST (History)
9 users (show)

See Also:
Source RPM: hplip-3.18.9-1.mga7
CVE:
Status comment:


Attachments

Description Sébastien Morin 2018-11-01 07:32:59 CET
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.
Comment 1 Marja Van Waes 2018-11-01 07:53:14 CET
(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) => marja11
Assignee: bugsquad => gnome

Comment 2 Lewis Smith 2018-12-07 20:37:05 CET
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.
Comment 3 Frank Griffin 2018-12-07 21:35:54 CET
Reincarnation of https://bugs.mageia.org/show_bug.cgi?id=16946 ?

CC: (none) => ftg

Comment 4 Lewis Smith 2018-12-09 11:49:37 CET
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 => High
CC: (none) => lewyssmith

Comment 5 Martin Whitaker 2018-12-10 00:13:22 CET
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

Comment 6 Lewis Smith 2018-12-10 21:35:47 CET
(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).
Comment 7 Martin Whitaker 2019-02-02 16:24:42 CET
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.
Comment 8 James Kerr 2019-02-02 22:16:21 CET
*** Bug 24302 has been marked as a duplicate of this bug. ***

CC: (none) => brtians1

Comment 9 Thierry Vignaud 2019-02-03 13:46:34 CET
(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

Comment 10 Martin Whitaker 2019-02-03 14:41:58 CET
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?
Comment 11 Thierry Vignaud 2019-02-03 19:59:19 CET
Recommends will have an effect on upgrade.
But if done on CLI with --no-recommends (or "no-recommends" in /etc/urpmi/urpmi.cfg)
Comment 12 Martin Whitaker 2019-02-03 21:43:23 CET
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.
Comment 13 Thierry Vignaud 2019-02-04 16:56:32 CET
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
Comment 14 Martin Whitaker 2019-02-04 19:53:10 CET
(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.
Comment 15 Martin Whitaker 2019-02-04 20:20:42 CET
BTW, that would also be needed to have the extension enabled by default in clean installs.
Comment 16 Olav Vitters 2019-02-04 22:03:53 CET
(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

Comment 17 Martin Whitaker 2019-02-04 22:15:04 CET
(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.
Comment 18 Olav Vitters 2019-02-05 19:24:44 CET
(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.
Comment 19 Martin Whitaker 2019-02-06 00:12:30 CET
(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.
Comment 20 Lewis Smith 2019-02-06 10:29:13 CET
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?
Comment 21 Sébastien Morin 2019-02-06 15:25:18 CET
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?
Comment 22 Martin Whitaker 2019-02-06 20:20:06 CET
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.
Comment 23 Lewis Smith 2019-02-07 21:22:29 CET
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.
Comment 24 Martin Whitaker 2019-02-08 01:10:07 CET
gnome-tweaks wasn't included on the CI ISO, but I have made sure it will be on the next ISO build.
Comment 25 Sébastien Morin 2019-02-08 07:32:50 CET
(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.
Comment 26 Lewis Smith 2019-02-08 14:01:50 CET
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...
Comment 27 Dave Hodgins 2019-02-14 20:09:34 CET
I agree it should be set up to operate that way, in any Mageia gnome install.

Status?

CC: (none) => davidwhodgins

Comment 28 Martin Whitaker 2019-02-16 14:49:24 CET
(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.
Comment 29 Brian Rockwell 2019-02-16 22:20:54 CET
Just did - no issues.  This has been fixed from my perspective.

thank you
Comment 30 Lewis Smith 2019-02-17 09:09:35 CET
(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...
Comment 31 Dave Hodgins 2019-02-17 17:20:52 CET
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) => FIXED
Status: NEW => RESOLVED

Comment 32 Lewis Smith 2019-07-06 17:56:12 CEST
*** Bug 25062 has been marked as a duplicate of this bug. ***

CC: (none) => mageia


Note You need to log in before you can comment on or make changes to this bug.