I actually quite like this - there’s no need for certain features when their absence makes managing the directories easier. However, solely those features deliberately removed should be removed.
from what i gather, i think the file picker is up to the developer, so if you take a 100 different developers and ask them to give you a file picker… you will get a 100 different variations (some of which will be GTK based).
dolphin obviously uses the Qt based file picker, but they build upon it, which most developers probably feel is unnecessary for their needs.
but i’m not a developer, so i could be totally wrong.
@skyfishgoo, the main dolphin application definitely doesn’t use the Qt file picker as its base. I expect that KDE’s file picker implementation doesn’t too, because I’d be seriously surprised if as much functionality as depicted could be added to it, nor that that would be desirable.
They shouldn’t differ unless they’re custom, because although the application developer controls which they want to invoke, they usually (rationally) choose the toolkit-provided file picker. Qt and GTK both provide a basic file picker.
However, KDE specifically differs in that all of their applications utilize a non-toolkit but not application-specific file picker. It is the KDE file picker aforedepicted.
Because solely KDE (rather than merely Qt) applications utilize this FP, I fail to understand why its codebase would be separate from dolphin’s. This is especially strange when considering that dependencies like the konsole KPart draws konsole as a dependency, so precedence exists for this.
Why does the file picker appear to be a reimplementation of most of dolphin’s functionality?
Because no-one has done that. Same reason as ever.
You are skipping over the progress that has been made to make the KDE file-picker more dolphin-like and vice versa over-time. For instance the places panel code is now shared between the two, so is the url navigator/breadcrumb.
Some people even call it the “dolphin file-picker”.
Must the code bases really be separate?
The file picker will never be exactly as Dolphin, it has other constraints and fill a different use-case.
That being said, we (as in KIO/dolphin devs) agree that we can make them more similar. Grouping is very unlikely (for implementation reason), moving panels maybe, but file metadata unlikely (this needs baloo framework).
For those interested in technical details, those are in different code bases, the KDE file-picker is implemented in the KIO framework (KFileWidget), and dolphin is an KDE Gears application.
The interesting thing is, you have this question because the KDE file picker is too powerful compared to file pickers in other platforms.
No one asks why file pickers in GNOME or Windows are so inferior to Nautilus or Explorer, because they don’t look remotely close to the latter. The KDE one went halfway from simple dialogs to a complete file manager, and it seems a somewhat awkward place to be.
@jinliu, I asked this question to Microsoft 5 years ago, for exactly the same reasons I asked here. I don’t believe that I ever received a response, however, and because the two codebases differ significantly, I doubt that their implementations are similar in anything except concept.
Additionally, I’ve had many a person refer to the File Picker windows as “file manager” when discussing how to open certain types of files.
Or maybe KFileWidget could just launch Dolphin (in a special “File Picker” mode) when it’s present. So KFileWidget itself only serves as a fallback (when Dolphin is missing), and can be made much simpler than it currently is.
But some apps add custom UI compoments beside KFileWidget, and that can’t be done in Dolphin.
This “file picker” mode is common in CLI file managers (e.g. ranger). But in GUI file managers, the only one I’ve seen is the Android system file manager.
You and I must “talk computers” with similarly-minded folks - even the concept of a “file picker” is tricky for some, I’ve found, as with a lot of effort they get used to what a click, double-click, right-click, drag-and-drop all mean in the context of a desktop or folder icon, and they eventually start to “get” the grammar of handling files through their icons…
Then they get to a file picker popup at some point - perhaps an “Upload document” button on a website - and enough of those mouse motions and menu selections are different, or mean different things, and the tools in the picker window are different enough that it forces them to develop a “file picker” grammar. (This has mostly been on Windows, FWIW)
It’s certainly not insurmountable for those folks, and not remotely a red-alert-urgent kind of thing, but I imagine that even for advanced users, having to stop and think which “mindset” you need to be in can create some friction.
Is there some fundamental reason for this? I’ve always been surprised that it was easier to improve the file picker implementation rather than build out the ability to extend Dolphin as a file picker.
Indeed, AOSP’s com.android.documentsui is an unusual example of an entire file manager being created from a basic file picker, rather than the other way around.
@johnandmegh, we do indeed! You’ve articulated what I wanted to much better than I was able to. Both my grandmother, sister and mother act exactly as you describe.
Actually, @meven, those sections which you reference, which rather obviously appear to reutilize/share code (most significantly, the Places panel) are why I asked. Specifically, because so much is not unnecessarily reimplemented, I am more surprised that they need to be separate.
Surely adding the few modifications necessary to make Dolphin a usable file picker would be a more trivial task than building out the same functionality as is in Dolphin into the file picker?
I’m not an expert on this, just some speculations:
Firstly, KFileWidget is not a dialog, but a Widget. Some apps create their own dialogs, with a KFileWidget inside. This seems to be the popular way in KDE when apps want a custom file dialog. All these custom dialog code need rewrite, because IIUC you can’t embed Dolphin in a dialog, at least not in Wayland.
And more apps just use the standard QFileDialog (which IIUC opens a standard dialog with a KFileWidget inside). But unlike Android Intentions or shell “$(ranger)”, in which the calling app is suspended until the dialog closes. QFileDialog allows the app to interact with it (QFileDialog Class | Qt Widgets 6.6.3). Dolphin can’t (and probably shouldn’t) do this.
But in reality, most apps just wait for QFileDialog to finish. These can be changed to launch Dolphin instead. However, that would make file dialogs inconsistent across KDE apps, where most are Dolphin, but some (cases above) are still KFileWidget.
The history here is that Dolphin and the file picker used to share a lot of code, but long ago, Dolphin went off and wrote its own rendering engine and places panel code and so on, for various reasons that probably made sense at the time.
However this caused a long-term maintenance burden. For this reason the Places panel code has since been re-unified. However the view engines still differ.
Re-unifying code is always ten times more difficult than forking it or diverging in the first place, which is why this kind of internal fork is such a bad idea IMO. Much better to use common components and improve them where they fall short, rather than going off and doing your own personal custom thing.
An issue we had only until recently also, was that KIO/Plasma (the framework the DE) couldn’t be made depending on Dolphin (an app).
The proposal to make nautilus implement org.freedesktop.impl.portal.FileChooser effectively having a looser/dynamic dependency circumventing the issue.
Such a solution could be imagined for dolphin too. But we have limited dev bandwidth as always and I have plenty of more important things to take care of.
