| Summary: | Partition Manager Doesn't Look Like Screenshots (Uses old gui) | ||
|---|---|---|---|
| Product: | [Applications] partitionmanager | Reporter: | Pranav Sharma <pranav.sharma.ama> |
| Component: | general | Assignee: | Andrius Štikonas <andrius> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | jr, neon-bugs-null, sitter |
| Priority: | NOR | ||
| Version First Reported In: | 3.0 | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/partitionmanager/71481dd60660a654f87233e82087120aca2e52ab | Version Fixed/Implemented In: | |
| Sentry Crash Report: | |||
| Attachments: |
Screenshot of old gui
This is the desktop file settings that fixes the issue |
||
It doesnt follow the breeze style. Created attachment 103055 [details]
This is the desktop file settings that fixes the issue
So the run as other user box is checked by default, which leads to the gross theme.
Yes, it needs to run as root, otherwise it won't have the required permissions to write to the disk devices. You need to configure your theme settings for the 'root' user to match those of the regular user. I think the default setting is to run it as root, but if you run it as the user kde su is activated. Ah yes, I actually discussed this on IRC a couple of weeks ago. The flag [1] indeed is causing the problem. Specifically, partitionmanager has code [2] that would automatically restart itself as root supposedly preserving the environment of the user so that Qt can load the correct theme plugin. This code however only runs when not already root. So the flag in the desktop file effectively renders the auto-root feature moot as it never gets used when the application started via the desktop file (which would be the default way). Ultimately this results in no theme plugin getting loaded as partitionmanager is running with super minimal environment variables set making Qt blissfully unaware of what theme to load. [1] https://cgit.kde.org/partitionmanager.git/tree/src/org.kde.PartitionManager.desktop?h=v3.0.0 https://cgit.kde.org/partitionmanager.git/tree/src/util/guihelpers.cpp?h=v3.0.0#n52 I'll try to release partitionmanager release that fixes this. As Harald said, we discussed it on IRC. It's just that I was busy dealing with a more serious kpmcore bug. (In reply to Andrius Štikonas from comment #6) > I'll try to release partitionmanager release that fixes this. As Harald > said, we discussed it on IRC. It's just that I was busy dealing with a more > serious kpmcore bug. Please note that the "proper" fix to the issue here is to remove the X-KDE-Substitute entry from the desktop file (thus making checkPermissions do the environment magic), not the stuff we discussed on IRC :) Git commit 71481dd60660a654f87233e82087120aca2e52ab by Andrius Štikonas. Committed on 02/01/2017 at 11:37. Pushed by stikonas into branch 'master'. Fix desktop file. KDE Partition Manager restarts itself with correct environmental variables. M +1 -1 src/main.cpp M +0 -1 src/org.kde.PartitionManager.desktop https://commits.kde.org/partitionmanager/71481dd60660a654f87233e82087120aca2e52ab For version 3.1 I think I'll also pass $HOME environmental variable to keep user home dir and theming. (In reply to Andrius Štikonas from comment #9) > For version 3.1 I think I'll also pass $HOME environmental variable to keep > user home dir and theming. You really must not. If you set $HOME you will have configuration files in the user's home owned by root, re-owned to root, have incorrect (rooty) paths written to, and similar nonesense happening. This is also one of the reasons why sudo, for example, takes great care to mangle the environment such that the "default" variables are pointing to root rather than the sudoing user. Setting HOME to the user's home while elevating to root is a big no-no. For theming purposes what you could try to do is make plasmaintegration (the themeplugin) read from SUDO_USER's home and in your helper export SUDO_USER. This needs checking back with the plasma developers, but generally speaking if you go through SUDO_USER and make double sure that the themeplugin is only able to read but not write configs this ultimately should give better themeing. NB: this still would not be perfect as the elevated application still wouldn't be able to load additional themes or plugins or icons from user specified XDG_* environment paths (also, doing so would, in fact. be an enormous security hazard). (In reply to Harald Sitter from comment #10) > (In reply to Andrius Štikonas from comment #9) > > For version 3.1 I think I'll also pass $HOME environmental variable to keep > > user home dir and theming. > > You really must not. If you set $HOME you will have configuration files in > the user's home owned by root, re-owned to root, have incorrect (rooty) > paths written to, and similar nonesense happening. This is also one of the > reasons why sudo, for example, takes great care to mangle the environment > such that the "default" variables are pointing to root rather than the > sudoing user. > > Setting HOME to the user's home while elevating to root is a big no-no. > > For theming purposes what you could try to do is make plasmaintegration (the > themeplugin) read from SUDO_USER's home and in your helper export SUDO_USER. > This needs checking back with the plasma developers, but generally speaking > if you go through SUDO_USER and make double sure that the themeplugin is > only able to read but not write configs this ultimately should give better > themeing. > > NB: this still would not be perfect as the elevated application still > wouldn't be able to load additional themes or plugins or icons from user > specified XDG_* environment paths (also, doing so would, in fact. be an > enormous security hazard). Thanks, I'll try to implement these suggestions when I have time... |
Created attachment 103054 [details] Screenshot of old gui partition manager is using the old gui even though it was updated to version 3.0