KDE Developers Are Currently Seeing 150~200 Bug Reports Per Day

[sophisticles]

This alone proves you are a complete troll (a proper comparison would have been Dolphin ~= Explorer). Cannot be otherwise. Because otherwise would be too sad a reality for everyone to bear.

https://malwaretips.com/blogs/explorer-exe-what-it-is-should-i-remove-it/

Explorer.exe, also known as Windows Explorer or File Explorer, is a process that manages the graphical user interface of the Windows operating system. It is responsible for displaying the desktop, taskbar, and file management functions such as browsing files and folders. When you open a folder or navigate through your computer’s file system, explorer.exe is the process that handles these actions.

Functions of explorer.exe

Explorer.exe performs several important functions that are essential for the smooth operation of the Windows operating system. Some of its key functions include:

• Displaying the desktop: Explorer.exe is responsible for rendering the desktop background, icons, and taskbar. It provides a visual representation of your computer’s desktop environment.
• Managing file and folder operations: When you open File Explorer or browse through folders, explorer.exe handles these operations. It allows you to view, copy, move, rename, and delete files and folders.
• Launching applications: Explorer.exe enables you to launch applications and programs by double-clicking on their icons or shortcuts. It initiates the execution of the selected application.
• Providing context menus: When you right-click on a file, folder, or desktop, explorer.exe generates context menus that offer various options such as opening, deleting, or renaming the selected item.
• Handling system notifications: Explorer.exe displays system notifications, such as new email alerts, battery status, and network connectivity, through the taskbar and notification area.

Explorer.exe is the Windows GUI, it is analogous to the Plasma shell + Dolphin.

[sophisticles]

Please report the issue to KDE and inform sopissedtickles that number of bugs is now 24001.

Very clever.

How long did it take for you to think of that one?

[sophisticles]

The only thing I think that would drastic effect of improvement quality of KDE software without requiring ridiculous resources is using more typesafe languages like Rust, its not going to make the unknowns safer but it will make the knowns much safer which makes it easier to identify where underlying issues are. This is going to be a hard sell however given that KDE is literally tied to the Qt framework which is written in C++ and actually has a custom compiler with moc (although someone could translate this to Rust).

Modern C++ is definitely safer than old school C++ so that can help, but it still doesn't come close to Rust

So basically you want to rewrite KDE in Rust but I'm the insane one for what I propose?

Have to love the open source Kool Aid.

[mrg666]

Very clever.

How long did it take for you to think of that one?

Took just a bit more than this

https://www.youtube.com/watch?v=etBoJJ0GZI8

[sophisticles]

So by your logic, you stand outside an ant hill with a hammer, smashing the ants as they leave. Since the queen is pumping out new ants every day, that therefore means none have actually died. Am I getting that right?

You do know that I have a degree in Biology, right?

Depending on the species of ant, a queen can lay hundreds to thousands of eggs per day:

https://fireant.tamu.edu/learn/biology/

So yes, unless you kill the queen, you have accomplished nothing.

It isn't immune but it is inherently less vulnerable than Windows. I've witnessed malware on a Linux server before; I know it's legit. If you're really that appalled by the security vulnerability of a first release of a major DE update, then don't use it. That's like buying a Smart Car and complaining about the potential of losing your legs if you get into a head-on collision at highway speeds.

I actually practice what I preach, I have stopped using it and I am back to Mate.

I am hoping that COSMIC prove to be better but I have my doubts.

[Nth_man]

> Most of the bug reports actually not about KDE issues at all: graphics driver issues
> graphics driver issues

its 2024 - GPU in linux barellly working.
[...]
AMD and intel are just unusable in reality, idk what is it.

Mmm... it's working for me, and for other people, for example with the Steam Deck :

"Okay, how many Linux users are there on Steam?

For an estimation of the total number of Linux users on Steam, Valve reported they had 132 million "monthly active users" in March 2022 (source).

Using the latest months recorded share (Feb-2024 - 1.76%): 2,323,200 estimated "monthly active users" for Linux+Steam.

To be clear, that is not the total, that is monthly active".

There is more information on https://www.gamingonlinux.com/steam-tracker/

[anda_skoa]

Nice but I am more talking about the core Qt framework being in C++, although this is definitely helpful for end user applications

The context of how you mention it was KDE software. Which could be written in Rust regardless of whether it uses Qt.

I am sure you are also aware that the output of Rust can be easily linked into a C/C++ library so even parts of Qt could be written in Rust.

Well the difference between a code generator and a compiler can be a bit bening (i.e. is typescript a compiler or code generator even though its target is javascript?)

As I said the misunderstanding around moc is common and leads to wrong assumption on how it works and what it does.

I've come across people who think it somehow transforms the sources and is therefore a needed step before the C++ compiler does its thing.
But it is not. Good example for this is, as you said, the typescript compiler, but I am also fine with it being called a code generator.

You called it a "custom compiler" but it doesn't even parse a custom language. It reads C++ headers files.

I don't think that protobuf/grpc are the best example because this is talking about message serialization which is a lot more clear cut

I don't think the domain really matters. Lexer and parser generators don't do serialization either but are still generating code.
Main difference to moc is that it does not generated headers, only sources.

Qt also has code generators that are more like protoc, e.g. qdbusxml2cpp (generating code from D-Bus XML interface files) or qscxmlc (generating code from XML state machine charts).
Almost every framework that deals with a compiled language and has a module for either of these has such a tool.

But very few people would write "and actually has a custom compiler" as you have done.

Oh yes, but iirc (this was over 10 years ago) moc did a lot more than just trivial boilerplate, it did actually have some logic in there hence the bluriness between compiler/code generator.

All code generators that either have command line options or read input files need to have logic to deal with those.

But in any case the distinction is largely irrelevant here

Well, it should be but you suggested that Rust would be a hard sell to KDE developers because one of their libraries uses a code generator.

Why not go for the opposite and assume that their understanding of the value of code generation would make them appreciate the power of Rust macros?

[anda_skoa]

Have you never read anything i have posted?

Yes, even the posts that were so disconnected from reality that they could have come out of ChatGPT.

I don't working for free, if you want me to fix something you have to pay me a fair market wage.

Wasn't that of the plan that you somehow discovered to be unactionable when being challenged to do it?

If KDE or Gnome had a central person with a Master Degree in Computer Science that earned 1.7 million a year and was responsible for maintaining the code base, then they would be fantastic desktop environments.

Both KDE and Gnome are multi-product software producers, many of the product maintainers have university degrees, sometimes even PhDs.
Even the Linux kernel has several sub projects with their individual maintainers because it is too large for a single person to handle.

Being open source is not what makes the Linux kernel what it is

Oh yes, it does. More importantly being Free Software makes the Linux kernel what it is.
Being open source made it possible to adapt it to almost any conceivable device, being Free Software made it possible for each new adaptor to build on the work of all the others.

Lastly, there is zero benefit for me to fork the project because all the fixes to the GPL software also have to be GPL, I wouldn't own a thing.

So it is not your project management skills or the engineering skills of your developers that would be the different, but you owing "a thing"?

If they re-license it under an MIT license, I'll fork it and show them how it's done, of course the source will be closed and the DE will be a commercial only product.

Then go and pick any MIT licensed project on github and report back when you have successfully removed all bugs from your fork.
Should also be much easier and quicker than doing the same for a product portfolio of hundreds of applications which would be the case of your original suggestion with KDE

[anda_skoa]

Thanks, even though my tiny little brain understood the distinction

I am glad to hear.

Some people do not and think that the quoted 24 000 bugs was for the KDE Desktop Environment when it was across the whole KDE product portfolio.
Some of those people even publish their ignorance by writing things like

the entire KDE DE has 24,000 open bug reports

[anda_skoa]

Way to cherry pick quotes.

It is a bit inconvenient when people actually understand how software development and distribution works, isn't it?

You could have thought about that before posting in a forum that actual software engineers read and comment on