When sni-qt is installed:

• passive popups (when hovering over the systray icon) works
• systray icon is invisible but functional

When sni-qt is not installed:

• passive popups (when hovering over the systray icon) broken
• systray icon is visible and functional

As discussed with Patrick the issue is with the new KDE 5 (Plasma) architecture

http://blog.martin-graesslin.com/blog/2014/03/system-tray-in-plasma-next/
https://blog.martin-graesslin.com/blog/2014/06/where-are-my-systray-icons/

Python3 + PyQt5 resolved the issue.
Currently the sdwdate_gui uses python2.7 + PyQt4
We need to port it to PyQt5 which needs python3 as well.

After porting, the new look is like attached

Tooltips

Right Click

Left Click

Looks great!

These screenshots were useful to create a homepage for sdwdate-gui. There is now a homepage for both, sdwdate and sdwdate-gui.

• https://www.whonix.org/wiki/sdwdate
• https://www.whonix.org/wiki/sdwdate-gui

https://github.com/joysn/sdwdate-gui/tree/master/usr/lib/python3.4/dist-packages/sdwdate_gui

Few things

1. I am not sure what changes are needed to make sure that we do

sudo apt-get install python3-pyqt5

which is necessary for this change to work. Let me know if any files needs to be modified for that.

2. The original sdwdate_gui.py was located at

/usr/lib/python2.7/dist-packages/sdwdate_gui/sdwdate_gui.py

I created new directory for python3.4
/usr/lib/python3.4/dist-packages/sdwdate_gui/sdwdate_gui.py

3. In Debian Stretch is works seamlessly, but in Debian Jessie, we see some extra errors [but does not change any functionalities]

libGL error: pci id for fd 10: 80ee:beef, driver (null)
libGL error: core dri or dri2 extension not found
libGL error: failed to load driver: vboxvideo

I googled and find the issue to be VM related but no fix as such apart from start using newer versions.

4. I am not sure how do I display the actual changes since this commit is a "new file". Do you want me to make another commit, which is on top of existing sdwdate_gui.py so that you can "view" the changes? Any other way?

1. These packaging related changes are done in git master. (And can be seen in the git history.)

2. I deleted the python2.7 version to make the diff easier to read and since we no longer need the python2.7 version. Moved from python3.4 files to python3 to fix a lintian warning. I am not too sure about that, perhaps it would have been better to move to python3.5, but it works. On Debian /usr/bin/python3 is a symlink to python3.5.

3. Never mind about jessie. As long as it works on stretch we are well set for the future.

4. It's alright now in git master. By deleting the 2.7 version in a separate branch and then using git diff -C the diff was very easy to review.

I broke https://github.com/Whonix/sdwdate-gui/blob/master/usr/lib/sdwdate-gui/show_message (by changing to python3). Could you please port it to python3 / newer Qt also?

Here it is Patrick.
https://github.com/joysn/sdwdate-gui/commits/master/usr/lib/sdwdate-gui/show_message

Great! Merged. show_message (the popup) now functional again.

I see two issues (might be code wise the same issue).

sdwdate-gui -> right click "exit" ->
Segmentation fault

sdwdate-gui -> right click "restart" -> right click "restart" another time -> right click now ignored

Could you look into it please?

Well this issue is seen only in "Jessie" not in "Stetch". Still I fixed this.

https://github.com/joysn/sdwdate-gui/commits/master/usr/lib/python3/dist-packages/sdwdate_gui/sdwdate_gui.py

This change should fix the first issue of segmentation fault.

Second issue

sdwdate-gui -> right click "restart" -> right click "restart" another time -> right click now ignored

I think this is a timing issue. As soon as you press restart, press once more restart, now right click just takes time - probably a good 30 seconds to appear.

Patrick, can you confirm this behavior with the update code?

sdwdate-gui -> right click "exit" ->
Segmentation fault

This is fixed.

sdwdate-gui -> right click "restart" -> right click "restart" another time -> right click now ignored

In T598#12094, @joysn1980 wrote:

I think this is a timing issue. As soon as you press restart, press once more restart, now right click just takes time - probably a good 30 seconds to appear.

Right. It becomes responsive again after a while. But why does it lock up? That's a new bug, that didn't happen in Whonix 13.

Patrick,

I see the same issue (repeated right click , restart ) is present even in the older version. Can you verify that once?
If so, we can fork "unresponsive right click" issue out of this ticket.

Thanks

Yes it is indeed by design.
Some comments in the code

## When restarted from sdwdate-gui, allow sufficient time between
## status changes. See related comment in sdwdate-gui.

## When the file is quickly rewritten by another operation, reading
## would fail. TOCTOU

## QFileSystemWatcher may emit the fileChanged signal twice
## or three times, randomly. Filter to allow enough time
## between kill and restart popup in show_message(), and
## prevent os.kill to raise an error and leave a gui open.

So, I think if this needs a fix, this probably needs a re-design. A new ticket is desirable for that.

In T598#12098, @joysn1980 wrote:

I see the same issue (repeated right click , restart ) is present even in the older version. Can you verify that once?

Works for me in Whonix 13. Right click does not lock up.

Yes it is indeed by design.
Some comments in the code

## When the file is quickly rewritten by another operation, reading
## would fail. TOCTOU
try:
    with open(self.status_path, 'rb') as f:
        status = pickle.load(f)
except:
    return

I do not think this is related. Also possibly nothing can be done about it. It's about showing status messages. When one status is written and then sdwdate quickly progressing in the next moment and another status written. In these situation the one status that did not finish writing to disk is discarded and that later status that was written gets used.

1. When restarted from sdwdate-gui, allow sufficient time between
2. status changes. See related comment in sdwdate-gui.

Same as below.

## QFileSystemWatcher may emit the fileChanged signal twice
## or three times, randomly.

QFileSystemWatcher does not seem random. That would be a python bug. This was a previous issue which I might have quite some time ago here:
https://github.com/Whonix/sdwdate-gui/commit/0046d2170000449c666fe5f80ec9440505867922

During that time ./usr/share/sdwdate-gui/unit-test/fuzzer was created. It creates tons of messages in a very short time to check if sdwdate-gui has an issue with that. sdwdate-gui then supported super fast file changes and never messed up.

## QFileSystemWatcher may emit the fileChanged signal twice
## or three times, randomly. Filter to allow enough time
## between kill and restart popup in show_message(), and
## prevent os.kill to raise an error and leave a gui open.
if self.message != self.previous_message:
    self.setToolTip('%s\n%s' %(self.title, self.stripped_message))
    self.update.update_tip.emit()
self.previous_message = self.message

That comment may be outdated, but that code may be good to keep. If sdwdate gets or some other case it could indeed happen that it issues the same message twice. Protecting from duplicate passive popups seems useful.

So, I think if this needs a fix, this probably needs a re-design. A new ticket is desirable for that.

Created T626 for that.

I do not see the issue in my case. I have latest sni-qt installed and the sdwdate icon is also visible.

Can you check if you see them inside status and notification?

I'll check in the next developers-only build.

Just an update.

By default each system tray icon has "visibility" value "Auto". Meaning, we have to press "Up Arrow Key" in the system tray icon to see the icon.

In case, we always want the sdwdate to be always shown then we need to modify
/home/user/.config/plasma-org.kde.plasma.desktop-appletsrc
file to add the below line at the end

shownItems=\\0

It should be in the General Containments. The updated section will look like below

[Containments][7][General]
extraItems=org.kde.plasma.notifications,org.kde.plasma.battery,org.kde.plasma.volume,org.kde.plasma.mediacontroller,org.kde.plasma.devicenotifier,org.kde.plasma.clipboard
knownItems=org.kde.plasma.notifications,org.kde.plasma.battery,org.kde.plasma.volume,org.kde.plasma.mediacontroller,org.kde.plasma.devicenotifier,org.kde.plasma.clipboard
shownItems=\\0

Through UI it is easy, but the above can be updated using script. I am not sure what changes are to be done for this, so thought of posting this here.

Thanks for reporting!

Making edits in user's /home kde dirs directly isn't a clean solution. Easily breaks or breaks unrelated things or interferes with user settings.

The clean solution is dropping a kde configuration snippet. Here is an example, package https://github.com/Whonix/kde-dolphin-menubar-enable... Essentially two files:

• config file: https://github.com/Whonix/kde-dolphin-menubar-enable/blob/master/usr/share/kde-dolphin-menubar-enable/share/config/dolphinrc
• environment variable: https://github.com/Whonix/kde-dolphin-menubar-enable/blob/master/etc/X11/Xsession.d/50kde-dolphin-menubar-enable
• The other files are just for packaging purposes.

That worked in Debian jessie based Whonix. Currently broken in Debian stretch based Whonix. Apparently the KDEDIRS variable was abolished and hopefully replaced by something else. Still TODO to figure that out and fix.

A similar solution for "always show all tray icons" or "always show sdwate-gui" might have to be added.

In T598#12298, @Patrick wrote:

That worked in Debian jessie based Whonix. Currently broken in Debian stretch based Whonix. Apparently the KDEDIRS variable was abolished and hopefully replaced by something else. Still TODO to figure that out and fix.

Might have found a fix for that. More here: T633#12299