I tried editing the source code. Oh my god. The developers just took all the file metadata and stuffed it into the tooltip/hower. And they did the same with the preview panel. I had two heart attacks when I saw that.
I believe that requesting the removal of information that isn’t useful to you disregards the priorities of other users. For example, I do need to be able to see the creation, editing, and access dates, as well as be able to sort by file extension. Sorting by the “type” of multimedia files that I just converted to another format is useless to me. However, it is useful to be able to sort by file extension and perform the necessary operation on a specific extension of file, not a “type”.
Wow, it would probably be cool if we could customize display settings for each file type, including their order. Something could replace the “cramming all file metadata” approach. Something that would show a widget specific to that file type, depending on the file type. So that these “widgets” could be edited by the user from the file properties graphical interface. I wonder if anyone has ever thought of this before, or maybe even implemented it in any projects.
.jpeg have 7 properties. .dng- have 18 - you dont need see all 18 properties, all time. Do we have a memory limit? I’m saying that this file manager element needs attention. It needs a major overhaul. The preview panel also needs a major overhaul. How many years ago did people ask for the ability to preview text files? 13 years ago? Oh, my God.
I do not use Dolphin to manage my several image formats. For that, I use Digikam. As for audio files, I use Puddletag. But when I only need basic info (filename, extension, size, creation data) … I use Dolphin.
That’s exactly what I’m talking about. A tooltip should be small and neat, and show the bare minimum of information necessary (if you can customize exactly what it is, that’s fantastic). It shouldn’t display all the file’s properties.
Oh, this is simply unbelievable, I found a third use of the same method. (Baloo::FileMetaDataWidget) Only now in the “file properties” window - the menu where you can view/change permissions and checksums. It strongly seems that whoever did this was in a hurry. Or they were just too lazy to do it properly.
Since you have already shown up in the topic, and so as not to create a new one:
How about, on the “Properties” tab in the “File Properties” dialog handled by KIO, presenting the file properties as a table, and also having a checkbox/radio button “Click to edit the tooltip”? This button would display the same list of file attributes, but with the ability to enable/disable these attributes and change their order for display in the tooltip.
These data would be saved in KConfig for each individual MIME type, which would store which fields to display for this MIME. When the tooltip is shown, a constructor would be called that reads from KConfig the properties to display for this MIME. If there is no user‑saved configuration, then it would show the “common” configuration for the whole MIME category.
This approach would reduce the space the tooltip occupies and make it informative and genuinely useful.
Perhaps overpaid and underworked as usual…
Please be careful, though this may be a blunder I’m sure that it will be looked at… perhaps some discussion is already underway to decide how to respond to this.
I fully agree that a more concise tooltip is more appropriate - possibly a setting to toggle popping up a tooltip vs popping up a larger configurable info popup.
Ooh, yes, configuration would also be wonderful.
Been running into this frustration for a while, so decided to look into it and found this post. More information is at https://bugs.kde.org/show_bug.cgi?id=455645 and it looks like this has, surprisingly, been an annoyance for almost 4 years now.
All software is.
What makes you think nobody is bothered by it? I see people categorising new KDE bugs and commenting on them often, doing lots of unrewarding work. Just this week I got an email saying there was a merge request for a Dolphin bug I was following.
You’re not going to convince people to look at your tooltip issue by criticising them for not caring.
they were just too lazy to do it properly.
Disrespecting the volunteer contributors is not allowed per KDE’s Code of Conduct. Please edit your message so it is more respectful and constructive.
You can also help by reading through our instructions on how to help some of the problems you are pointing out.