Regression: systray needs compatibility adjustments to work with plasma5

Bug #1350038 reported by Harald Sitter on 2014-07-29
This bug affects 15 people
Affects Status Importance Assigned to Milestone

Bug Description

plasma5 does no longer support the ancient xembed systray but instead requires a status-notifier-item. to transparently allow for qt4 applications using qsystemtray to continue working in plasma5 a compatibility patch + runtime binary is recommended by the plasma developers.

currently hp-systray is not compatbile with this and requires a patch that allows for receiving qsignals while waiting for a systray to become available

Harald Sitter (apachelogger) wrote :
Dennis Schridde (devurandom) wrote :

According to question #258609 "the problem is solved in a newer version of HPLIP" (which one?). The "fix" appears to be to use the sni-qt plugin, which provides a compatibility translator between QSystemTray (XEmbed - old way) and StatusNotifierItems (SNI - Unity/Plasma5). Can you confirm that? Are your patches still needed?

Dennis Schridde (devurandom) wrote :

I confirm that the SNI Qt plugin does its job, and that HPLIP appears to be fixed with regards to the autostart issue mentioned in

summary: - systray needs compatibility adjustments to work with plasma5
+ Regression: systray needs compatibility adjustments to work with plasma5
Sergio Callegari (callegar) wrote :

@Dennis. No. This is not the case. I have just upgraded a machine to vivid, I have the latest KDE 5 from the kde backports ppa, I have sni-qt installed and hplip does not start properly. This is a big regression with respect to utopic. I believe that there can be conditions where the bug is not experienced because as said elsewhere "On startup, it can happen that KSNI module & tray are not yet initialized, so hplip "missdetects" the tray." But in many situations the bug is experienced. This is the reason for the process-events-for-systray.patch.

Infact, the one line patch by Harald fixes the issue.

To the hplip package maintainers. Please, *apply the patch and make a SRU as soon as possible*. It is more than 2 months that kubuntu vivid is out with a problem and a nasty error message and with a 1 line patch fixing the issue has been floating around for ages (from much before vivid was released). We can believe that the patch is well enough tested by now. It is just a matter of applying it. I understand that this is by a large deal the smallest among the tons of issues that kubuntu vivid forces the user through and that ubuntu proper does not suffer from the issue in first place, still there should be no harm in fixing it.

Sergio Callegari (callegar) wrote :

Latest version of hplip (3.15.2-0ubuntu4.2) in Vivid Updates still has the issue.

What can I say: thanks for making a new release ignoring bug reports for which a patch was available and well tested.

Sergio Callegari (callegar) wrote :

This bug has been open for more than 1 year, with a patch available to fix the issue from the first day.

The patch does not seem to have side effects.

The patch probably fixes the issue in the wrong place (in hplip, rather than in KDE where a race evidently exists, given that all the other desktops can use hplip just fine). Hence, resistance in applying the patch is understandable.

However, if there is no intention of applying the patch because of the above understandable rationale, please someone mark the bug as "Won't fix".

Sergio Callegari (callegar) wrote :

Bug affects Wily too. I think that it will affect Xenial too. Please prove me wrong.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.