setroubleshoot gui consists of 2 parts - sealert browser and seapplet. sealert browser was already migrated to GTK+ 3 and we are slowly working on seapplet rewrite in order to use GTK+ 3, GNotifications and so on.

The intention of setroubleshoot is to keep number of technical details low. There are analysis available under Setroubleshoot button which provides information like this:

If you want to allow httpd to read home directories.
Then you must tell SELinux about this by enabling the 'httpd_enable_homedirs' boolean.
You can read 'httpd_selinux' man page for more details.
setsebool -P httpd_enable_homedirs 1

which seems to be simple enough. There are even analysis which has a fix button like "Restore Context" which can fix the problem for you.

Unfortunately, we don't have a GUI expert onboard right now so the progress is slow. We would appreciate any help in this area via github.com/fedora-selinux/setroubleshoot or pagure.io/setroubleshoot

This is not about 'fixing up the ui' of sealert. It is about designing the problem reporting aspect of the OS from the ground up in a way that makes sense. See https://wiki.gnome.org/Design/OS/ProblemReporting for some background

There's no amount of work a "GUI expert" could do to make those error messages understandable by someone who didn't know SELinux. To quote one of GNOME's translators on IRC:

what is httpd? do I want it to read my home directory? is my home directory the same as where I put my files? what is SELinux? I've heard of 'linux' before. what's a boolean? what is a man page? is it like a help for men? this is scaring me

I've provided technical support about SELinux to companies, and I don't feel comfortable about using this tool, and even less having it used by non-technical users.

The intention of setroubleshoot is to keep number of technical details low. There are analysis available under Setroubleshoot button which provides information like this:
If you want to allow httpd to read home directories.
Then you must tell SELinux about this by enabling the 'httpd_enable_homedirs' boolean.
You can read 'httpd_selinux' man page for more details.
setsebool -P httpd_enable_homedirs 1

which seems to be simple enough. There are even analysis which has a fix button like "Restore Context" which can fix the problem for you.

I'll just copy/paste this comment that somebody left in IRC today:

"""what is httpd? do I want it to read my home directory? is my home directory the same as where I put my files? what is SELinux? I've heard of 'linux' before. what's a boolean? what is a man page? is it like a help for men? this is scaring me"""

I'll add to that: what's a context?

Um sorry Bastien, I see we have just said the same thing. :)

It was a random example from my system related to httpd domain - apache or nginx webservers.

If "what is a man page" is valid question then setroubleshoot sealert is probably not the right tool for this use case. There's still DBUS API https://github.com/fedora-selinux/setroubleshoot/wiki/DBUS provided by setroubleshoot which could be used in other GUI tool to provide a better experience for beginners.

If an app violates SELinux policy, one or the other is broken. An automatic bug report would be good, or a notification to the user, but there's no reason to keep a complicated graphical application installed.

There are cases when a file has a wrong SELinux label or when a problem can be set by an SELinux boolean. They can be simply fixed by a setroubleshoot when a user wants to.

Automatic bug reporting wouldn't work due to possible big amount of false positives.

I don't see any cases where the end-user should be presented with anything related to SELinux. The only reason this exists is to warn of problems that shouldn't exist in the first place, either bugs in the policy, or the lack of automated tooling to do the right thing when deploying applications.

If a developer, or system integrator wants to see all those messages, I'm happy to let them install sealert to have those popup graphically, but this has no place in the default installation, whether or not it uses a modern graphical toolkit.

Discussed at today's WG meeting. We agreed to remove it from the default Workstation install, without replacement. The change will be implemented in a way so as to ensure Server is not impacted, since Cockpit has its own frontend for setroubleshootd messages.

Implemented in https://pagure.io/fedora-comps/pull-request/195

This has been implemented. The remaining task is to boot a live image and verify that it's really gone.