On Tue, Jun 09, 2015 at 01:05:23PM +0200, Knurpht - Gertjan Lettink wrote:

hplip-systray doesn't work with plasma5's systemtray. To avoid it from even trying copy the /etc/xdg/autostart/hplip-systray.desktop to ~/.config/autostart, then change the Exec= to "echo something" or whatever.

If I dismiss the error message at startup and then run hp-systray & it behaves as expected. -- ======================== Roger Whittaker roger@disruptive.org.uk ======================== -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2015-06-09 14:39, Freek de Kruijf wrote:

Op dinsdag 9 juni 2015 12:10:57 schreef Roger Whittaker:

...

On Tue, Jun 09, 2015 at 01:05:23PM +0200, Knurpht - Gertjan Lettink wrote:

...

hplip-systray doesn't work with plasma5's systemtray. To avoid it from even trying copy the /etc/xdg/autostart/hplip-systray.desktop to ~/.config/autostart, then change the Exec= to "echo something" or whatever.

If I dismiss the error message at startup and then run

hp-systray &

it behaves as expected.

I also have that behavior, so it works with systemtray of plasma5.

Can I change the Exec in "sleep 10;hp-systray -x"

As Andreas said: a sleep won't fix it. Who says that after 10 seconds, the conditions are right enough for hp-systray to succeed launching? ...also note the difference between "hp-systray" and "hp-systray -x". -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday, June 09, 2015 13:12:24 Patrick Shanahan wrote:

* Brüns, Stefan [06-09-15 12:22]:

...

On Tuesday, June 09, 2015 12:32:31 Freek de Kruijf wrote:

...

After updating hplip and starting a KDE session I get a warning message from hplip that the system tray is not available. After searching for a solution to this problem I found that starting hplip-systray is too early. So a sleep of a few seconds before this application runs will solve the problem.

However I can't find where this program gets started.

Any suggestion?

hplip uses the Qt4 python bindings. Stock QSystemTrayIcon does not support StatusNotifierItem, but this can be changed by installing sni-qt.

hplip-systray polls for the availability of the Tray for 60 seconds and exits afterwards.

Actually, it should just start, QSystemTrayIcon handles the delayed start of the system tray by itself.

I also see this "anomaly" on three of my four local boxes, all with sni-qt installed and like settings. One desktop work and two laps and another dt fail, complaining missing setting-tray.

All systems are Tw.

Hm, there may be a race condition in the bus startup, tray startup and hp- systray startup. Does it also happen if you invoke hp-systray after the desktop has started? You can trace the hp-systray startup by copying the attached hplip- systray.desktop to your ~/.config/autostart/ directory. It will dump the relevant dbus messages to /tmp/dbus_sni_$pid.out Kill the dbus-monitor process after your session has started: killall dbus-monitor The added tracing may change the timing, thus the trace might be useless. I have attached a trace of the hplip-systray startup. You can see the folllowing: The unique name :1.2707 gets a new owner as result of a "Hello" method call (NameOwnerChanged, [:1.2707, "", :1.2707] The requester is informed of its aquired name (Hello -> ":1.2707") :1.2707 adds a match for the StatusNotifierHostRegistered signal :1.2707 asks the bus for the StatusNotifierWatcher owner :1.2707 asks org.kde.StatusNotifierItem to Register a new StatusNotifierItem Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424

* Patrick Shanahan [06-09-15 17:21]:

* Brüns, Stefan [06-09-15 15:42]:

...

On Tuesday, June 09, 2015 13:12:24 Patrick Shanahan wrote:

...

* Brüns, Stefan [06-09-15 12:22]:

...

On Tuesday, June 09, 2015 12:32:31 Freek de Kruijf wrote:

...

After updating hplip and starting a KDE session I get a warning message from hplip that the system tray is not available. After searching for a solution to this problem I found that starting hplip-systray is too early. So a sleep of a few seconds before this application runs will solve the problem.

However I can't find where this program gets started.

Any suggestion?

hplip uses the Qt4 python bindings. Stock QSystemTrayIcon does not support StatusNotifierItem, but this can be changed by installing sni-qt.

hplip-systray polls for the availability of the Tray for 60 seconds and exits afterwards.

Actually, it should just start, QSystemTrayIcon handles the delayed start of the system tray by itself.

I also see this "anomaly" on three of my four local boxes, all with sni-qt installed and like settings. One desktop work and two laps and another dt fail, complaining missing setting-tray.

All systems are Tw.

Hm, there may be a race condition in the bus startup, tray startup and hp- systray startup.

Does it also happen if you invoke hp-systray after the desktop has started?

No, there appear to be at least two pids of hp-systray -x after the failure to find the system tray. I kill those processes but it is not required and issue "hp-systray -x" and have normal and expected function.

...

You can trace the hp-systray startup by copying the attached hplip- systray.desktop to your ~/.config/autostart/ directory. It will dump the relevant dbus messages to /tmp/dbus_sni_$pid.out

Kill the dbus-monitor process after your session has started: killall dbus-monitor

The added tracing may change the timing, thus the trace might be useless.

I have attached a trace of the hplip-systray startup. You can see the folllowing:

The unique name :1.2707 gets a new owner as result of a "Hello" method call (NameOwnerChanged, [:1.2707, "", :1.2707] The requester is informed of its aquired name (Hello -> ":1.2707")

:1.2707 adds a match for the StatusNotifierHostRegistered signal :1.2707 asks the bus for the StatusNotifierWatcher owner :1.2707 asks org.kde.StatusNotifierItem to Register a new StatusNotifierItem

I will do this on one of the lap tops and post a link.

trace is at: http://wahoo.no-ip.org/~pat/dbus_sni_16030.txt -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Op woensdag 10 juni 2015 10:58:34 schreef Johannes Meixner:

Hello,

On Jun 9 16:22 Brüns, Stefan wrote:

...

On Tuesday, June 09, 2015 12:32:31 Freek de Kruijf wrote:

...

After updating hplip and starting a KDE session I get a warning message from hplip that the system tray is not available. After searching for a solution to this problem I found that starting hplip-systray is too early. So a sleep of a few seconds before this application runs will solve the problem.

However I can't find where this program gets started.

Any suggestion?

hplip uses the Qt4 python bindings. Stock QSystemTrayIcon does not support StatusNotifierItem, but this can be changed by installing sni-qt.

hplip-systray polls for the availability of the Tray for 60 seconds and exits afterwards.

Actually, it should just start, QSystemTrayIcon handles the delayed start of the system tray by itself.

In general I have zero knowledge about desktop-related stuff (I do not use a desktop) so that there is basically nothing what I could do here.

As far as I understand it had worked in the past with older KDE but now it does no longer work with newer KDE.

Accordingly I assume it is a generic issue in HPLIP with newer KDE but not an openSUSE specific issue.

If I am right, the proper way to get it really solved is to report it directly to the HPLIP upstream authors via http://hplipopensource.com/hplip-web/support.html

This way the issue could be solved in HPLIP for all desktops for all Linux distributions instead of openSUSE specific hacks.

Or is the only issue that for current openSUSE:Factory the hplip binary RPM should require sni-qt and then all would again "just work"?

In this case I would appreciate an OBS submitrequest with an appropriate conditional RPM requirement for sni-qt for the hplip binary RPM (sni-qt is neither available for openSUSE:13.1 nor SLE12 nor SLE11 but HPLIP is built in the OBS Printing project for all of them).

Kind Regards Johannes Meixner

Agreed, it's up to HP to fix this. In the meantime, this works on my laptop as a workaround: - Copy the hplip-systray.desktop from /etc/xdg/autostart to ~/.config/autostart, then edit it to make it like this: cat ~/.config/autostart/hplip-systray.desktop [Desktop Entry] Categories=Application;Utility; Comment[nl_NL]=HP System Tray Service Comment=HP System Tray Service Exec=sleep 20;hp-systray -x & GenericName[nl_NL]=Printer Status Applet GenericName=Printer Status Applet Icon=/usr/share/hplip/data/images/128x128/hp_logo.png MimeType= Name[nl_NL]=HP System Tray Service Name=HP System Tray Service Path= StartupNotify=false Terminal=false TerminalOptions= Type=Application Version=0.6 X-DBUS-ServiceName= X-DBUS-StartupType= X-KDE-StartupNotify=false X-KDE-SubstituteUID=false X-KDE-Username= X-SuSE-translate=true -- Gertjan Lettink, a.k.a. Knurpht Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org