-
-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
QDirStat tries to use a non-existing file manager #192
Comments
Yes, most likely. You are right: That could be done a bit better. It could check first if the filemanager that has been guessed is available; and then do some fallback cascade if it's not. For the time being, please either replace Or you could set the |
Digging a bit deeper into this, I found out that the problem is really the error reporting. You should really see this: But those two particular default cleanup actions have their output window policy set to "ShowNever".
And the second one even has a comment explaining why: "Make KDE konsole shut up". And that made me remember that it was those KDE programs (and only them!) that kept misbehaving in every possible way, and that was one of them. So proper error reporting (policy "report if error") would always open the output window with the error message: (depending on your desktop and Qt / KDE settings) Because some genius decided that any message that Qt itself reported would be worthwhile to be dumped on stderr, even if it's just diagnostic output like here; and some other genius at TrollTech decided that it's of earth-shattering importance to always tell the user those two messages, even if it should really be only with something like This is why those two cleanup actions are set to this policy "never show". And this is why you never see that error in the output window, just in the log. |
So: Sorry, but I am fed up with pampering broken KDE applications. It's for them that I had to change that proper error reporting policy to something that sometimes (in pathological scenarios) hides an error in the log rather than explicitly showing the user. I am not going to pollute my code even more with more insane workarounds that only those broken KDE applications need. |
While this STDERR pollution is certainly unfortunate, it seems unrelated to the issue I posted initially. It is sad that QDirStat can't easily display errors from Qt apps, but it does not seem to me that it prevents performing a |
Hi, would it be possible to reopen this issue, as it is not about whether QDirStat is capable of logging an error properly or not, but about it using a file manager that does not exist on the system? Would it be possible to use the approach you mentioned?
One could also use D-Bus' https://www.freedesktop.org/wiki/Specifications/file-manager-interface/ As for dealing with showing only proper errors, why not handle it as the app is telling you - an error that you should show? |
Any user who has enough know-how to do something about this should also know to check the log. That's what it's there for. Also, since the standard cleanup actions can be configured in the GUI, it's very easy to replace that |
While yes, user can override the default value, I do not believe the default value should pick an essentially random file manager and hope it is there, instead of querying the system for it. |
It's not random. It's the usable KDE file manager, unlike Dolphin that is dumbed down to the point of being pretty much useless. |
I cannot right click and "Open folder" in QDirStat.
My main file explorer is Dolphin yet QDirStat tries to launch non-existing konqueror, I assume due to the fact it detects my DE as Plasma.
The text was updated successfully, but these errors were encountered: