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.
1 Like
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.
1 Like
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.
What’s wrong with the developers? In the local file manager. KIO (Network transparent access to files and data) is responsible for the local file properties window. Am I in a nightmare? File properties are drawn by KIO, not Dolphin. Who thought this was a great idea? Everything that happens to files on my computer should be handled by Dolphin. KIO should be responsible for computers located on the network.
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.
My brain is exploding. Dolphin calls KIO, which displays properties for test.jpg, and the 4-th tab “Details” doesn’t have its own KIO layout like 3 tabs before but is called plugin from Baloo. I just want a proper tooltip. Why is the file manager’s architecture so scattered throughout the system? How match strings code you safe ? not teoretic for real? 2,5?
Maybe I seem rude. Simultaneously asking for help and fixes in the program. And then insulting developers who, in my opinion, write code “somehow incorrectly.” Please forgive me. But understanding the architecture of how it works leaves me deeply depressed.
I understand the purpose of KIO: to allow programs to access files on remote computers via various protocols, as if they were local. (It’s strange why this should be handled by DE, and not by a kernel module running on a filesystem.)
I don’t understand why a file manager that works with local files should access the KIO API. ?
Okay, I understand the purpose of Baloo file indexing and their properties.
I don’t understand why baloo needs to be called to display proprietary files on remote PCs via KIO.?
Who is this desktop environment architecture being created for? For whom? We basically have three types of interfaces for Linux.
type I : console pseudo-graphical interface
type II: Program interfaces written in GTK
type III: Program interfaces written in Qt
No one in their right mind would write a program interface for KDE. Because by writing it in Qt, the program would already look like it was built into the system, thanks to the same theme design for all applications.
No one in their right mind would edit a file on a remote PC, no matter how great KIO’s abstraction layer is. Everyone would want to get a local copy of the file so they could work on it. Even your favorite GitHub pulls files locally, rather than allowing remote collaboration.
And even if someone does need it, a kernel-level KIO implementation will be a cut above. Because there will be no need to understand yet another unnecessary API. im a realy have a big butthurt