A very important question about the ideology of developing a Desktop Environment

Brainstorm
, ,
1

I’ve been using Linux as my primary system for both work and home for some time now, without dual booting. As a result, I chose KDE Plasma as my desktop environment, and I remain committed to that decision.

Over the past year with Plasma 6, I’ve gathered several questions and suggestions for the KDE developers. I’d greatly appreciate any insights or responses to help me better understand the development process.

Could you share what principles guide KDE developers in decision-making, ideology, and development priorities? I notice some community requests seem overlooked—how does the team balance user feedback with their vision for what’s best overall?

I’m curious why Dolphin still lacks built-in previews for text files, PDFs, and similar formats. Also, regarding KIO dependencies: could KIO serve as an optional module for Dolphin rather than being core? Direct file access for a file manager seems intuitive, while KIO feels more suited for network protocols like file://. I’d love to hear the rationale behind this architecture.

It would be helpful to understand the benefits of using KIO for local file access in Dolphin. This design choice intrigues me, and I’d appreciate learning more about its advantages.

In the system tray, I see the “Status and Notifications” label each time I expand it. After a year, is there a way to customize or hide this for users familiar with the interface?

Regarding system tray icon labels: tooltips already provide app names on hover. For experienced users who recognize icons (like Telegram or qBittorrent), could labels be optional to keep the tray cleaner?

I’ve noticed that disabling tray icons (widgets) also disables related system functions. Is this by design for resource management? A setting to decouple these would be appreciated for more flexibility.

Settings for system, plasmoids, and KDE apps feel spread across multiple locations. Grouping them centrally—such as app-specific sections in “System Settings” under an “Applications” menu—might improve discoverability. Context menus work well, but a unified view could help.

Plasma seems designed to welcome newcomers while offering power for advanced users. How does the team ensure experienced users feel empowered rather than limited by defaults?

2 Likes
2

Each person will have different motivation to contribute, different idea or vision what they want to work on.

For things that have multiple contributors there is often a form of road map or “todo” list to align the individual efforts.

Some thumbnailers might not be installed by default, e.g. I manually installed the LibreOffice thumbnailers.

Some formats might not have thumbnailers yet if nobody had time yet to work on them.

Given that they are separate programs and also shared with other desktops they are actually a great option for getting into FOSS development.

It allows the program to use the same code paths for working with local files, remote files and even virtual files.

It also decouples the UI from the actual file access, preventing it from being blocked during long running operations.

It enables the user to do start multiple operations, e.g. copying two sets of directories in parallel.

Supports closing of the main UI while keeping the process running until completion.

Since KIO is shared between applications it allows each application team to focus on their app’s primary functionality and cooperate on the shared one.

Which gives users more choice in which application they use for a certain task without losing access to the common functionality. E.g. using a different file manager without losing the capability to access files via SSH.

8 Likes
3

I agree with heavy and specific files, like 3D models and the like. They should be provided by programs that handle these files. BUT for common files like text (not office documents), but regular txt files. How many years will it take for a preview to appear?

Which gives users more choice in which application they use for a certain task without losing access to the common functionality. E.g. using a different file manager without losing the capability to access files via SSH.

That’s great and all well and good. But why should this be implemented at the Desktop Environment level? Why not at the kernel model level? Based on this, programs written in GTK won’t use these features that are exclusive to KDE. Therefore, they won’t be in demand, and therefore won’t be used. Therefore, you wasted your time developing this abstraction.

KIO is needed to work with remote PC protocols like smb:// shftp:// webdav:// and others. Good, great. Why do you need KIO to work with local files? Why is working with local files dependent on the KIO API? For a demonstration? Not all users need remote access to files. But everyone needs access to local files.

5

A the time when this was developed there wasn’t anything like FUSE nor were there any asynchronous APIs for file access.

Sometimes it is faster to develop something “in house” then to work on a lower level.
Also has the advantage of working on other kernels, e.g. BSD or Solaris.

They could, the applications communicate with the KIO processes via known protocol.

However, they will most likely already be using GIO. which is similar on some aspects and different in others.

It is quite possible that someone could put in the extra effort to make them converge and establish this as a infrastructure.

After all this is how D-Bus came along.

It is quite widely used and has been for decades.

And kio-file allows the application to use the same code paths when dealing with local files.

An application doesn’t “need” do use it for local files but it can.
As outlined in my previous comment there are numerous advantages to be gained.

Besides KIO there are many different APIs for file accesss, e.g. QFile, C++ filesystem, POSIX read/write, etc.

Developers will usually use the API the best match for the features they need.

I am pretty sure they can do that with Dolphin and many other KDE applications.

6

Yes, but why doesn’t the implementation look like this? Direct access to local files. For remote ones, a KIO representation. Even if I know for sure that I don’t need to use remote PCs, I still have to implement the KIO dependency. This whole race to “not use the same code in two places” is absurd. To change permissions on a local file or calculate MD5 hash sums, I need to access an interface designed for remote PCs. This isn’t normal. Let’s say I wanted to contribute to the community and add a function to Dolphin. I had to conduct a thorough investigation of the spaghetti code to discover that the “details” tab isn’t called from the file manager or KIO, but is generated on the fly by the Balloo widget. This tab doesn’t even have a layout like the MD5 hash or user permissions.

7

What would the Dolphin developers gain from having two different code paths?

For example when copying files the only need to call KIO::copy(), regardless of whether the source or destination is local or remote.

They also get a convenient API to monitor and control the operation.

They get an operation that is run concurrently and will not block them.

If they would be using, e.g. QFile::copy() then they would get no monitoring and the operation would block until completed.

You are free to use whatever API fits your use case.

For example you could use QCryptographicHash::addData()with a QFile object as its argument. However, if you application is a GUI process, you will want to do that in a separate thread.

1 Like
8

What does the user get? Dolphin calls the KIO network stack, which in turn calls the Baloo local file indexer. Don’t you see the inconsistency in calling the local file indexer from KIO, which is responsible for remote computers? Baloo doesn’t index files on remote computers. Why is it called from KIO?

9

So, imagine you need to call an ambulance to your home. You get through, and the operator asks, “Have there been any crimes in your building?” Then they tell you to hold on hold. The ambulance operator calls the police and finds out. Then they come back and ask, “Have there been any fires in your building?” They ask you to stay on the line, call the fire department, and confirm.And only then does he return to you on the line and ask what kind of help you need? Working with local files through KIO is the same.

1 Like
10

In the case of Dolphin a very capable application.

Dolphin uses the KIO API, whether that involves a network operation handler depends on the uses URIs.

For local files it will spawn an operations handler that works with local file APIs.

Not sure which operation that would be but if that operation can by assisted by Baloo then it makes sense to use it.

Do you have a reference to that operation?

I would assume that it only involves Baloo for local files, not remote ones.

We can probably check the code. Which operation are we talking about?

1 Like
11

not true. The purpose of DE is to improve the user’s quality of life. What the user gets: No preview for simple and common files. The same baloo widget is used in three places. In the tooltip when hovering over a file. The same baloo widget in the F11 preview window. And the same baloo widget in the “ditails” folder in the file properties. The lack of drag’n’drop functionality in the system tray widget (instead, we have a big, ugly menu with drop-down lists) used to hide icons. Settings responsible for system behavior are hidden in the plasmoid settings, which only work and are called if the widget is displayed.

12

yes we can,

image
image1002×717 80.8 KB

see tab “Сведенья” - “ditails” Why is the layout in KIO responsible for rendering this window, which is related to a local file?

13

No, that’s not true. The first three tabs have layouts that are contained in KIO. But the fourth, “Details,” doesn’t have a layout—it’s just a ballo::widget.

14

The purpose of a DE is to facilitate the user experience. For some reason, KDE is focusing on things that need to be addressed at the kernel level, like creating APIs. It’s not enough that there are two sets of libraries, GTK and Qt, when choosing to write a GUI program, according to the KDE team’s vision, you also need to consider which DE the Qt/KDE program is written for. What if Xcfe also makes its own implementation? XIO to write programs for Qt/xcfe. In the open source world, duplicate forks that do the same thing aren’t enough for us.They created the KIO API to make things easier for developers. Great job! DE has had 12 years of feature requests from users. Was text file preview requested back in KDE 4?

15

hit me if I’m wrong

17

I’m not sure what the purpose of this thread is. Just to complain that things haven’t been done the way you wanted them to be done, based on your personal understanding of the technical implementations?

What’s your desired end goal here? Emotional validation? Technical changes?

Neither seem likely with the attitude you’re bringing here. I’d recommend toning it down and engaging in good faith with people. @krake has already heroically replied to your leading questions; if you want further answers, you’re probably going to need to adopt a more constructive attitude.

Thanks.

20 Likes
18

I don’t need social approval, emotional response, or support from the RGB+ community. I need a desktop environment that works. One that performs a single, well-defined function — being a desktop environment, not trying to solve problems beyond its scope, whether it’s “how to provide access to remote PCs’ files as if they were local” or “how to make KDE convenient for developers who write software for KDE.”
Let me remind you: KDE Plasma is a desktop environment, not a platform for software development. It is NOT yet another abstraction layer over hardware.

Thanks, and have a nice day.

19

The scope between a DE and a ‘platform’ is inherently blurry isn’t it?

Features like integrated network file services solve real problems for a large proportion of the user base…

As for the RGB+ community - I’m quite confident they’ll continue glowing fabulously without your approval, but dismissing an entire group of people doesn’t reflect well on your character… sadly veering into offensive ignorance.

6 Likes
20

I am afraid it is unclear which point you are trying to make.
Is the details widget a KIO widget or is it a Baloo widget.

And why would either be an issue? Regardless of which library it comes from it allows Dolphin to display details of a file.

Development on different layers of the stack can require different skills.
A developer might feel confident with C++ and usage of libraries like Qt but feel less confident about using C and contributing to Kernel code.

It can also be advantageous to implement things at a higher level, e.g. as a process instead of a kernel module, or as a library instead of a system call.

It can also be very helpful to try things one way, to discover which aspects worked well and which didn’t, and then incorporate that knowledge into a new iteration.

Trying to create the perfect solution up front can easily lead to not having any solution at all.

Not really.

Most KDE applications have no dependency on KDE’s Plasma deskop.
Many of them even work on very different platforms like Windows.

Exactly!
Giving application developers advanced tools, e.g. libraries or services, allows them to concentrate on their application’s code.

Sometimes these things are specifically created for this, sometimes appear as one application’s feature and are later extracted into a widely used component.

In either case it is something any new application can just use, the proverbial standing on giants’ shoulders.

4 Likes