(German version: https://wordsmith.social/felixernst/dolphin-treffen-bei-barcelona)
Among my contributions towards KDE I am probably best known for becoming a dolphin maintainer recently. “Maintainers” are the people most responsible for something, and I share this responsibility with Méven Car these days.
The plan was to have a dolphin meeting at Barcelona, so I set off.
I think the most important topic for a self-organising and -acting international group like us, that swims in all seven seas, is that we meet from time to time at a coast to talk about common goals. Otherwise, everyone surfs and browses wherever the streams pulls them. Everyone has an idea about what is currently the most important thing to get to and then simply swims there as directly as they can. However sometimes it makes sense to discuss what really is the most important area to focus on. And that is exactly the topic I have chosen for our dolphin meeting.
It was new to me to act in a leading organisational role within KDE. Not only concerning Dolphin but also more generally within the ecosystem of penguin fans.
Okay, I think I have to drop the Doublespeak here because technical terms become necessary. To avoid any further confusion, I'll clarify now: Dolphin is an application. To be more precise: It is the default file manager of KDE. Méven Car and I share the responsibility of maintaining it. The text above wasn't really about animals at all!
We did meet in Barcelona and tried to figure out where the biggest areas of improvement for Dolphin might be.
Time Travel for Files and Folders?
Neal Grompa, who brings KDE's software to Fedora and other distributions, had the idea that Dolphin should have a feature that allows users to restore older states of files and folders. The practical application of this would for example be that a user — after ruining a report or article — could simply bring back an older version of that file. Or that someone — after accidentally deleting a file — could restore an older version of the folder containing that file and therefore restore the file itself.
Does that sound like magic to you? Is it even possible? Wouldn't it be necessary to have some sort of backup for this to work?
The answer to all these questions is “Yes”. You might not yet be aware that some modern file systems, which you might already be using while you are reading this, are already keeping old data around. They do this so that you can bring your computer back into a working condition if your system ever becomes dysfunctional. Popular file systems which have this as an integrated feature are BTRFS and ZFS.
While exploring the sights of Barcelona with Luca Weiss and Arjen Hiemstra, we discussed how such a time travel feature could be implemented in Dolphin, and I also researched the topic a bit on my own later: The problem I am currently seeing is that it is difficult to pinpoint where in the file system the older versions of files and folders are located. It turns out that at least for BTRFS there is no mandatory folder structure. While it is normally reasonably easy for users to find the old versions (e.g. in openSuse in “/.snapshot/SNAPSHOTNUMBER/snapshot”) the names could be anything, the age of the backup is not necessarily stored in an easily accessible manner either, and figuring out which files belong together isn't trivial either. What do we do if the file that should be restored has been moved to a different folder in the meantime?
Maybe I am missing something, but I am having difficulty inventing a reliable approach even if I ignore all the technical details for the moment. That doesn't mean that the project is impossible to implement. Not at all! Worst case one could simply search the full disk. However, I have to admit that this is too big of a project to programme on the side. If you are interested or capable to implement this nicely you would be the hero of some users who would otherwise not know how to recover the data. I am certain of that.
One would probably implement it as a KAbstractFileItemActionPlugin which opens a window in which the user could choose the version of the file or folder they want to restore.
Dolphin could be better at dealing with slow storage
In a way the most important thing for a file manager is that it quickly displays the data on storage media. We don't want the name Dolphin to only be for show: A dolphin is fast (fastest mammal in water at 64 km/h). Nothing blocks it in the oceans.
Disks, on the other hand, can be blocking which can be a problem for the other Dolphin. It might take a while for them to retrieve data especially when they are accessed over the internet or another “slow” network. But the access being slow isn't really a good excuse for Dolphin to stutter as well. Loading of data can obviously take some time but Dolphin should stay responsive and quick regardless of that.
More details on this topic can be found in our meeting notes: https://invent.kde.org/system/dolphin/-/issues/35#note_535555
Copying files and folders is wrongfully reported as completed
With some regularity users complain about data loss because they removed a storage device after the data transfer has been reported as completed.
In KDE we report a file transfer as complete when the Linux-kernel reports to us that the transfer is complete. Unfortunately, that isn't the full truth because the Linux kernel is a bit hasty in that regard. It considers a transfer as complete as soon as the data is “accessible from the new location.” However, that is a while before the data has actually been physically transferred.
I see three solutions to this: 1. Linux gains a new option so the reported transfer progress is based on physical data transfer progress. 2. We make sure ourselves that the transfer is complete before we report that it is. 3. (In the words of Kai Uwe Broulik:) “We show a very very angry message to the user when they unplug a device that is still mounted, so they will learn not to do that!”
Dolphin should allow users to manage root-owned files and folders
As you might know, the Linux security model can deal with multiple user accounts that act on the same data. Depending on the specific file or folder, different users can have different permissions when it comes to accessing, changing or executing the data.
The account that has full access to all data on the computer is typically called “root”. It is the administrator account on pretty much every computer.
If a user tries to run Dolphin with all the permissions of an administrator by using the programme “sudo”, which would allow them to edit any data on the file system, Dolphin denies this. The reason for this is that this action could potentially allow a hacker to seize full control over the computer. This blockade was put in place before I was part of KDE but users are still annoyed by it because it makes certain tasks more difficult for them. How can we improve this situation without introducing new security hazards for companies and users alike?
Harald Sitter created an alternative, more secure method (https://apachelog.wordpress.com/2022/08/04/kio-admin/) which allows users to manipulate all data. We might integrate it better into Dolphin eventually.
I also recently discussed a different more immediate solution with Nate Graham: We know that in the past years various methods have emerged to bypass the blockade. These methods, that reduce security, are quite popular. The blockade in Dolphin doesn't really stop users who want to do an insecure thing. So instead of trying to hinder users more effectively, we should take the chance and inform them about the dangers of what they are trying to do. If they still want to continue after that, we can't and shouldn't stop them. It could be a good idea to transform the block into more of a lock with an easy way to open it legitimately.
So much for what was discussed at the Dolphin Meeting. The rest of this article is about other topics that are relevant to me.
Dolphin for Phones?
In Barcelona I talked a lot with the young developers who strive to make an adapted version of KDE Plasma a success on mobile phones. I hope this software will soon become a viable alternative to Google's Android for the average user. There is some interest to have the file manager that people know and love from their computer also available on their phone.
They didn't know — and neither do you probably — that Dolphin is already so flexible and touch-friendly that not too much work should be necessary to bring Dolphin in a state that is nice to use on phones:
We would probably need a separate configuration for phones, so users can easily install Dolphin in such a fitted state. Are you interested in making Dolphin shine in the mobile space? Contributions are always welcome!
Dolphin and the “Blue Angel”
I talked with Joseph P. De Veaugh-Geiss, who supports the eco-friendly “Blauer Engel For FOSS” project, about the possibility of also certifying Dolphin with the “Blauer Engel”. Question is: What are the direct benefits we expect from such a move? Eventually, it could push governmental institutions towards using Dolphin but Joseph explained that they probably wouldn't switch to Linux for this alone. To his surprise — and maybe yours too — Dolphin already works on Microsoft Windows and to my knowledge even on macOS. It has some rough edges on Windows and nobody really takes care of those at the moment. Would that be worthwhile? If we were to popularise the Windows version, would that lead to a lot more free and eco-friendly computing? I am not sure if we shouldn't rather use our limited resources on other things.
You might notice by now that there is way more meaningful work to do in Dolphin alone than we can realistically undertake with our small group of volunteer developers. It would be great if even more friendly contributors would join the project all of a sudden. :)
Documentation in the Application
Another topic that is dear to my heart is that our software should also be usable by computer-illiterate users. We accomplish this with guides and help texts among other things. Some of my efforts to have more help available were successful. One example are the little help buttons which have made their way to various parts of KDE by now after I introduced them on the “Fonts” settings page only two years ago (https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/51). In a similar vein I added a feature to many applications that allows users to invoke exhaustive help directly from an application's user interface. You might have noticed the little “Press Shift for more.”-notes which for example show up when you hover your mouse cursor over a button in Dolphin. In my opinion every KDE application should provide more help this way.
I was in the meeting about writing guides and documentation for the web page https://userbase.kde.org/Welcome_to_KDE_UserBase and tried to promote the idea there that it might make more sense in many cases to have help available directly where it is needed: in the application. Unfortunately, I didn't get the impression that I was able to convince the attendees of that. So instead, I'll repeat here that every step we put between the user and the available help leads to less users actually using that help. When a user wants to know what a button does, the help should be available right there either next to the button or invokable directly from the button.
On a positive note I noticed that some KDE contributors have already figured out the benefits of this feature. Kai is a fan for example. I hope it is only a matter of time until this new way of providing help is used as naturally as the two-year-old little help buttons are by now in system settings.
So much about my endeavours. If you read with interest until now, you might also be interested in my videos about KDE development: https://tube.tchncs.de/c/felix_ernst/videos
Thanks to KDE e.V. and Its Donors
Meeting the unique group that traveled to Akademy 2022 in Barcelona this year held many benefits for our future collaborations and therefore ultimately for our software. The text above is already way too long even though I nearly exclusively talked about Dolphin. So many other topics would be worth mentioning. Above all else how great it was for me to meet all these friendly KDE contributors in person for the first time.
I would like to thank KDE e.V. and the many donors to that organisation for paying the majority of my travel expenses. After personally meeting the people who manage the donation money, I can say with full confidence that donation to the KDE e.V. are in good hands and spent with diligence and strategy to ensure the long-term existence and growth of the wider KDE community. If you would like to donate to this non-profit entity, visit https://kde.org/community/donations/.