Description of problem:

seapplet now fails to provide any visible indication when a SELinux error 
occurs, and the user is logged in to GNOME.

The problem must be that seapplet is an XDG "system tray" icon.  GNOME has now removed support for system tray icons.  So when a SELinux error occurs, a seapplet process appears in `ps` ... however that process does not manage to actually do anything.

So seapplet needs to be re-evaluated to decide what we want to happen here.  I didn't find any such discussion.

This was a deliberate feature of seapplet: to notify the user that SELinux is the cause of whatever failure has happened.  Which could otherwise have been very mysterious and frustrating.

For comparison, I _think_ ABRT is working correctly and showing notifications.  And I think selinux denials should be treated in the same way as ABRT: show a pop-up notification.   Ideally the seapplet process would also detect that it's systray icon is not visible, so it should be able to exit straight away.

That said, there are also messages visible in the main system log.  I don't know whether these would have been available pre-systemd... or if they would have been visible in the first system log file checked; the split of the log into multiple files was sometimes a cause of confusion.


Version-Release number of selected component (if applicable):
setroubleshoot-3.3.14-1.fc27.x86_64

How reproducible: always

Steps to Reproduce:
1. log in to GNOME
2. provoke a SELinux error (e.g. https://superuser.com/questions/908373/a-way-to-trigger-an-selinux-policy-violation)

Actual results:

no visible notification

Expected results:

Something changes onscreen to notify the user, like it used to.

Additional info: