Some people prefer vintage! 😜

That said, since it's that old, should we consider taking a ground-up approach? I'm currently on my work machine (macOS) but I know what pain-points you're referring in the experience of the application that'd help with aligning with Breeze (or even Kirigami standards.

In T8377#135794, @ngraham wrote:

This isn't really something that we can feasibly fix in Kubuntu. I would say, "please report upstream," but KDE folks are well aware of the issue already. What's needed is not more bug reports, but rather someone to actually put in the time to improve it. Would you like to have a go at it?

https://community.kde.org/Get_Involved/development

That sounds good with me. It definitely sounds a bit bigger than a junior task but I'm up for it. Do you know of any Bugzilla tickets for this? I can also search in a few.

Bugzilla tickets aren't necessary to commence work, in fact! The real issue is that KSysLog currently has to run as root: apps run as root don't inherit user themes. The correct solution is to make it not need to run as root, and then make it request elevated privileges using PolicyKit only when necessary. You might talk to @stikonas, who recently did this work for KDE Partition Manager.

The funny thing is: when I tested Artful, it looked the same as in the upcoming Bionic, but I saw a picture illustrating a breezified KSysLog in Help.

apps run as root don't inherit user themes :)

https://youtu.be/IjOZwAIKKhg
https://youtu.be/ytybmQrLTzI

In T8377#135797, @ngraham wrote:

Bugzilla tickets aren't necessary to commence work, in fact! The real issue is that KSysLog currently has to run as root: apps run as root don't inherit user themes. The correct solution is to make it not need to run as root, and then make it request elevated privileges using PolicyKit only when necessary. You might talk to @stikonas, who recently did this work for KDE Partition Manager.

I'm a bit confused here. Are we talking about KSystemLog? Because on my machine it starts as non root user and I can see Breeze theme.

That video confirms what he mentioned - but it does provide a notion for a potential fix.

It seems like XDG_CURRENT_ENVIRONMENT is _not_ being set by or being used by kdesu and the launched application.

In T8377#135810, @jackyalcine wrote:

That video confirms what he mentioned - but it does provide a notion for a potential fix.

It seems like XDG_CURRENT_ENVIRONMENT is _not_ being set by or being used by kdesu and the launched application.

This can be workaround from the app itself. Current master branch of partition manager (which is not yet using Polkit) restarts itself with some environmental variables that are passed through.

Ugly but it served KDE Partition Manager for a while:
https://cgit.kde.org/partitionmanager.git/tree/src/util/guihelpers.cpp?id=079e423abd89780d73acf851d1bf4a8db3994dba#n55

Whether kdesu keeps environmental variables actually depends on whether it calls su or sudo (kdesu can do both).

@ngraham It's important for root apps to be visually consistent with the rest of the desktop but a different color scheme is advisable. Re-open at will.

In T8377#135841, @ngraham wrote:

In T8377#135812, @ragreen wrote:

@ngraham It's important for root apps to be visually consistent with the rest of the desktop but a different color scheme is advisable. Re-open at will.

Agreed. The question is... should we fix this in Kubuntu by setting XDG_CURRENT_DESKTOP="KDE", or upstream in KSystemLog itself?

But that would break theming in other desktops.

It must be fixed upstream, either by adopting PolKit (preferable) or by adding a hack like KDE Partition Manager does (less preferable).

Whatever it takes. The issue should be addressed. @rikmills What do you think?