Linux Problems on the Desktop (2018)
I wish that there would be one unified API for creating desktop programs on Linux.  Right now it&#x27;s somewhat coalesced on GTK&#x2F;GNOME and Qt&#x2F;KDE, though there are a number of others out there.<p>I use Linux in a VM for very hobbyist level embedded development (think Arduino and the like).  Driver problems are non-existent, all of the technical problems are non-issues in this environment.  The problems that I see are all to do with the lack of a common set of services for building a GUI application.<p>Why do my text editor and Arduino IDE use different file pickers?  It&#x27;s because my text editor uses the KDE API, but the Arduino IDE uses something else.  GIMP uses yet a different file picker from the other two.  LibreOffice uses yet another file picker, that&#x27;s similar to Kate&#x27;s but slightly different.  I&#x27;m sure that installing Atom and VS Code would introduce me to two more file pickers.<p>The reason for this is that each of these programs uses a different GUI toolkit and, as a result, has a different concept of what a file picker needs to look like.  Some of them don&#x27;t even agree on which order the Open and Cancel buttons should be.<p>Network transparency is another thing that suffers from this.  On Windows, you can basically use a UNC path (\\server\share\path\to\file.txt) almost anywhere because the entire system from the file picker all the way down to the file APIs knows about UNC paths.  In Linux, KDE apps do this one way, GNOME apps do it a different way, and command line tools need you to somehow mount the target server before you can even think about it.  I last seriously used Windows about 14 years ago and I <i>still</i> miss this greatly.<p>None of these are insurmountable problems, but it needs someone to make a decision about the one true way to do things.