Expose Group information for files and folders so that it can be shown in Dolphin's Information panel, tooltips, etc.
FEATURE: 308002
FIXED-IN: 18.08.0
michaelh |
Baloo |
Expose Group information for files and folders so that it can be shown in Dolphin's Information panel, tooltips, etc.
FEATURE: 308002
FIXED-IN: 18.08.0
Deploy change, create new user, open Dolphin, open Information Panel
Deploy change, use existing user account, open Dolphin, open Information Panel
No Linters Available |
No Unit Test Coverage |
+1 Let's wait a little for more opinions.
src/metadatafilter.cpp | ||
---|---|---|
115 | Because of default == true, Group shows up for "old users" as kfileitem#group is not defined for them. |
Yes, this is optional-and-off-by-default for new user accounts and for existing users who have not customized the Information Panel before.
Michael brings up a good point though: this will cause existing users who have customized what's displayed in the information panel to get the new entry automatically. But maybe we can live with that and such users are sufficiently technically adept that they'll either like it or be able to easily turn it off?
We might also want to come up with a generic solution for that issue, or else we'll hit it over and over again whenever we add a new piece of data that the Information Panel can display.
In that case I would go for an generally opt-in solution with a few options checked by default. Just enough to convey whats possible. To be specific:
Showing up for any file:
Additionally:
With this users will experience that info changes with the file type and hopefully get curious to discover more.
In fact, this is exactly what we currently have by default in 18.04! :-)
What I'm saying for this is that we need a generic method to add additional data that can be displayed using the Information Panel without making those data displayed by default for users who have previously customized what's displayed in their Information Panels.
That's already available for those who want it. Right-click in the Information Panel, choose Configure... and add whatever you want.
In fact, this is exactly what we currently have by default in 18.04! :-)
Let's go for a drink then.
What I'm saying for this is that we need a generic method to add additional data that can be displayed using the Information Panel without making those data displayed by default for users who have previously customized what's displayed in their Information Panels.
I understood. What I meant by opt-in was settings.readEntry(uriString, false) which would show nothing except when explicitely set to true and true by default would be the above mentioned list.
Ah, I understand now. Yes, opt-in rather than opt-out makes sense to me. I'll experiment with that later.
Thanks! I didn't know that I can configure the Information panel. :D
@ngraham Mr. usability, your comment...?
Hah, I was in fact already having those thoughts...
It would probably make sense to move these settings into the Configure window, where all the other Dolphin settings live. It's always been a bit odd that the only place to configure the Information Panel was hidden away in a context menu.
It would probably make sense to move these settings into the Configure window, where all the other Dolphin settings live. It's always been a bit odd that the only place to configure the Information Panel was hidden away in a context menu.
Which reminds me of my last comment in D11245
Could you please enable file permissions by default? File permissions are way useful than Tags or Rating, which are already enabled by default.
The people for whom file permission information is useful (technically oriented sysadmin/IT/programmer types who administer or work in a multi-user environment) should be able to find out for themselves how to enable this--or will once we make it more obvious! :-) I'm not sure that file permission information is relevant for most of Dolphin's target users, especially considering that the output right now is not human-readable (e.g. "rw-r--r--").
Yep, my guess is most users rule their system anyway. For me they provide no useful info as I never navigate into say /sys/bus/clockevents/ with dolpin. There's a konsole for those things.
Well, I often wonder whether a given file is an executable or writable..
now is not human-readable (e.g. "rw-r--r--").
Are there alternatives to traditional Unix permissions?
Personally, I think it's okay to show traditional Unix file permissions because Linux is a Unix-like operating system* but I'm a "developer" so maybe my opinion shouldn't count.
* Yes, yes, I know... Linux is a kernel.
To me, this suggests that we might want to badge the icon itself or something, because this is generally useful information, and also has security implications (you don't want executable programs masquerading unseen as regular files).
Heh, it's not that your opinion doesn't count, but rather that we trust skilled people with specialized needs to optimize their own workspaces as needed. We optimize general-purpose tools for the common case, not the specialized case.
"Simple by default... yadda yadda yadda". In this case, it seems that the "powerful when needed" part of customizing the Information Panel's display was too well hidden, and we can and should improve that (in another patch, obviously).
src/metadatafilter.cpp | ||
---|---|---|
115 |
Nonsense! |
src/metadatafilter.cpp | ||
---|---|---|
115 | Sounds good! Would you like to submit a patch for this? |
$ kde/applications/baloo-widgets (string-list-widget)>git branch --list | wc -l 28
Do I have to?
Hah, of course not! I was just thinking that it might be a trivial 5-minute patch. If not, I can take a look myself when I find the time.
Ok, ok,..
- Tags
- Comment
- Rating
- Type or Date
- Size
Additionally:- Title (covers all media: audio, video, ebooks)
- Width & Height (covers all images and video)
In fact, this is exactly what we currently have by default in 18.04! :-)
Type or Date?
I was just being conservative; we can land in 18.04 if you'd prefer, assuming it's accepted in time.
I18N_NOOP2_NOSTRIP("@label", "Group") is a new string.
The real question is, why Baloo Widgets is not part of Frameworks :P
Ah right, so it is. And yeah, it is weird that this project isn't on the Frameworks release schedule.
Forgot that there actually already is a method to ensure that existing users don't get the change: increase the version number of the file. Now the upgrade case works just fine. This is ready for review.
I think it's quite worthwhile to use a whitelist instead of a blacklist. But that's now a general enhancement and not related to this patch. I'll review it.
At least for "writable", there is already the lock icon badge.
Heh, it's not that your opinion doesn't count, but rather that we trust skilled people with specialized needs to optimize their own workspaces as needed. We optimize general-purpose tools for the common case, not the specialized case.
"Simple by default... yadda yadda yadda". In this case, it seems that the "powerful when needed" part of customizing the Information Panel's display was too well hidden, and we can and should improve that (in another patch, obviously).
Show an additional "screw driver" icon after "Unlock panel" in the context menu has been selected?
Add a "Sidebar" category in the dolphin configuration, or add it as a new tag under "General"? (My preference: new Category).
Any chance this change broke the unit test filemetadataitemcounttest, due to new items?
See https://build.kde.org/view/Applications/job/Applications%20baloo-widgets%20kf5-qt5%20SUSEQt5.9/34/
Please have a look if you can make CI happy again :)
Oooh darn, for some reason I've missed these test failures in baloo-widgets, sorry! Will fix.
After investigating, it looks like this failure may be an installation issue on the build machine. The test is failing there because the new group property is inappropriately visible, but the approved change expressly covered this case by adding it to the baloofileinformationrc blacklist and bumping the version, which should have had the effect of not making the property visible. I suspect baloofileinformationrc did not get updated on the build machine the way it did on my local machine, where the test passes.
@bcooksley, any chance you can take a look at this?
@ngraham, @bcooksley : de-warning, my bad. The test I linked to by some magic had started to no longer fail in https://build.kde.org/view/Applications/job/Applications%20baloo-widgets%20kf5-qt5%20SUSEQt5.9/38/ (scripty surely did not fix it, or? :) there might be something dirty still, but we have to wait for it to return if there is), but was replaced by another test failing. I just looked at the graph and assumed it was the same test failing, given the constant number 1.
That test FileMetadataItemCountTest does not fail for me locally as well with latest master of KF & Qt 5.11.1.
(And the new test failing, extractortest, should hopefully be fixed soon as well, as sideeffect of the regression fix patch D13885)
In regards to CI nodes, for Linux virtually nothing is retained between builds, with the only writeable path that is kept being the directory where the archive cache is kept (and that is at a path unique to the CI system which nobody else should be touching)