You are viewing the original copy of this page

You are viewing your personal edited copy of this page

The Problem with the Linux Desktop

Registering a system wide hotkey

Monitoring the contents of the clipboard

Creating a layered window

Performing transparent window mouse hit testing

Creating a system tray icon

Detecting application shutdown due to use a log off request

A layered window on the Linux desktop, but what about transparent hit testing for the mouse?

Reply from Teresa

Not invented here syndrome. Preferring to implement things "my right way" rather than someone else's way that works.

Preferring to innovate rather than maintain, "Oh XXX has issues. Let's not fix it but start again".

A love of complexity. SystemD rather than sysV is the classic example: to save 7 seconds at my boot time (yes, I checked it) required hundreds of thousands of lines of SystemD code, and many hours of learning on my part. Currently I have massive problems caused between the various ways processes communicate with each other, often unnecessarily.

My reply to Teresa

As a long time desktop application developer, and an experienced Linux user and programmer, I am always frustrated when it comes to writing desktop applications on Linux. I commonly run into situations with Linux desktop environments, be it with Gtk functions, or with X11 functions, where I not only have no easy way do something, but also no easy way to find out how to do something. On the other hand, with Windows I have access to a single help file with a nice searchable index of all the functions I might need.Here is a small list of some of my recent frustrations when writing Linux desktop applications:Using my Windows help file I can find an easy way to do these things [1] Some of you may scoff at these Windows functions and the term easy, but they do in fact work, are searchable through Duck Duck Go, and they do what I expect them to do.But on Linux, I keep running into problems. Tray icons in work in some environments and not others, or worse yet stop working after an upgrade. This happens occasionally when a distro maker will decide to change things up by inventing their own way of doing something. The result is my applications break.Other times it seems as if the documentation for Linux functions are poor or do not exist at all. I've tried to find ways to create system wide hotkeys, and performing transparent hit testing with little success. Solutions are typically inelegant and prone to side effects or other problems. Often I've had difficulty searching for a way to do something. For example, I spent too much time trying to figure out how to monitor clipboard changes as I wrote my Linux clipboard history utility.The point is, figuring out how to accomplish a task in your the Linux desktop application can often turn into a tiring quest to find something that works only for some users.But what's the solution? Sometimes I need to use Gtk, other times X11, and sometimes DBUS to solve a problem. Does Linux need a unified MSDN type documentation portal to encompass more than a single toolkit? I don't think that would work as it seems as if every Linux toolkit provider acts as if they live on their own island. If Wayland becomes more popular, does that mean my color picking program or screenshot program or global hotkey code will just stop working when users move to Wayland? If I write a tray icon class to work with libappindicator1, does it stop working on systems that default to libappindicator3?I don't know, but I do know that I don't want to spend my time trying to learn what broke what. So I ask you, what's the solution for someone that wants to program for the Linux desktop?The Linux Kernel is a model of how to develop an OS. Change the kernel in a way that breaks something, even something done stupidly in user space, and Linus (Torvalds) will scream. But outside of the kernel space, open source developers suffer from these problems:I started in Linux 15 years ago. The desktops were a joy. They were stable, simple, and sufficient. Now they have become unstable, complex, and overkill. Unfortunately, last week as I began converting everything to Windows 10. I found exactly the same problems with Visual Studio. Lazarus still my mainstay thank goodness.Teresa, thank you for your considered opinion.I agree with most of what you said, but with regards to the option of moving back to Windows, for me that is a non starter. I don't use Linux rather than Window because of some technical benefit. The primary reason I use Linux because I don't want to worry around my privacy being compromised, either from malware or viruses which is a big problem on Windows, or from software vendors themselves be it Windows telemetry or other spying features which are being commonly bundled today with 1st, 2nd, and 3rd party software on Windows. These problems are pretty much non existent on Linux.I also value the efficiency of Linux. I have all processing speed and file system the room I need on a 2008 Core2Duo, 4GB of RAM, and a 60GB SSD laptop running Linux, even with the newest distros. On the latest version of Windows 10, not so much. Just getting Windows installed is about 30GB. And yes, this is a big deal for me because I always have 10 or more of these laptops on hand and use them to teach my students basic computers usage, online safety, and computer programming. Even if I wasn't using these machine for teaching, they still make for great everyday computers when running Linux. Again, when using them with the most recent version of Windows, not so much.My complaints, as you expanded upon, center mostly around the fractured nature of the Linux desktop ecosystem. Even popular distros such as Ubuntu break things from release to release. Whereas Windows seems to always try to protect backward compatibility of software, at least since they made the move to a true 32 bit OS. Of course with Windows OS upgrades some hardware is no longer supported (I still can't use the Canon photo capture system on other than XP), but most of the time everything works.Thanks again for your considerate thoughts.