6 ms·

I wish that there would be one unified API for creating desktop programs on Linux. Right now it's somewhat coalesced on GTK/GNOME and Qt/KDE, though there are

I wish that there would be one unified API for creating desktop programs on Linux. Right now it's somewhat coalesced on GTK/GNOME and Qt/KDE, though there are a number of others out there. 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. Why do my text editor and Arduino IDE use different file pickers? It'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's similar to Kate's but slightly different. I'm sure that installing Atom and VS Code would introduce me to two more file pickers. 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't even agree on which order the Open and Cancel buttons should be. 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 still miss this greatly. None of these are insurmountable problems, but it needs someone to make a decision about the one true way to do things.

meditate 8y ago
>someone to make a decision about the one true way to do things. Things don't really work this way in free and open source development. There is no one person to make decisions, consensus is reached when the quality of something raises "above the bar" and actually improves things for all involved parties. If someone wants there to be an über-library that serves everyone's use case then it's up to them to go and do the work to build that. And it has been getting better in this regard. For example KDE and GNOME used to have their own IPC, multimedia & audio mixing backends, but now both have converged on DBus, GStreamer and PulseAudio, in part because these were intentionally built to be flexible low-level solutions. I'm sure there are more examples of this too but those are the first that come to mind.
- Mister_Snuggles 8y ago
  You're absolutely right. I wonder if something like DBus and PulseAudio could happen with my UNC pain point. With the assumption that the goal is for "vi //server/share/file.txt" to work the same as "notepad.exe \\server\share\file.txt" does on Windows, here are my thoughts. First off, notepad.exe doesn't really care about the fact that it's a UNC path. It just opens the file with CreateFile (either CreateFileW or CreateFileA). There would need to be replacements for the libc file functions. These could be a shim in front of libc, or baked right into libc. Note, there's a LOT more needed than "just" new file functions - any functions that do anything with paths need to be looked at. Shells would likely need some changes to work properly, though it's not like the Windows shell can truly do much with UNC paths - copying files to/from works, but you can't cd into them. How does it ask for credentials? If it's via DBus, a desktop environment provide the authentication prompts, but what about a pure-commandline system? Maybe the transport is just SSH and relies on the existing public key authentication? But what if you're just doing a one-off thing and don't want to set that up? Using SSH is probably a decent idea since it's got authentication, security, and a file transfer protocol, already built in. On top of all of this, when you open //server/share/file.txt for writing, what does that actually mean? Is there a file descriptor? How does that work with the kernel? Does libc now manage all file descriptors with only a subset corresponding to kernel file descriptors? Could a pure user-space solution fake this well enough to actually work? Would this need to be a FUSE filesystem along with some daemon to automatically unmount the remote servers when the mount is no longer needed? Would it be something like the automounter, just a lot better? Does a kernel need changes for any of this to work? This is one of those things that touches so many layers and potentially interacts with so many parts of the system, potentially all the way down to the kernel. My guess, and I don't actually think this will happen, is that Apple will do something like this on Mac OS X and have a reasonable mapping to the BSD world underneath, then someone in the Linux community will come along and do something similar in a way that's better suited for Linux. As a parallel, Apple came out with launchd in 2005 to replace init scripts, systemd made an appearance in 2010 - both do very similar jobs, with launchd tailored to the needs of MacOS and systemd tailored to the needs of Linux. Maybe something similar could happen with UNC-like file sharing.
  - 8y ago
smallbigfish 8y ago
"On Windows, you can basically use a UNC path" How about NFS in Linux? It's a lot more transparent than SMB will ever be in Windows. SMB is and will remain a Windows feature.
- Mister_Snuggles 8y ago
  These aren't the same thing. In Windows, you can basically use a UNC path anywhere because CreateFile knows how to deal with it. The point is that you don't need to mount the remote filesystem (the Windows-equivalent being mapping a network drive).
  - ti_ranger 8y ago
    I don't mount remote filesystems, autofs does it for me whenever I browse /net/$hostname
rhinoceraptor 8y ago
To be fair, the Arduino IDE is java swing, so it doesn't look quite right on any platform.
jcelerier 8y ago
arduino IDE is written in java with Swing, it looks weird on every OS
pja 8y ago
I'm sure that installing Atom and VS Code would introduce me to two more file pickers. Having just checked, both Atom & VS Code use the GTK/Gnome file picker. LibreOffice is also using the GTK/Gnome file picker.
bayesian_horse 8y ago
Windows doesn't have that kind of unique standard either. Both KDE and GNOME have user interface guidelines. If Software doesn't follow it, well...
- Mister_Snuggles 8y ago
  In recent years, Windows has become a mess in the UI space. Mac OS X has fared a little better, but it's also becoming a mess. It makes me sad. Years ago programs written for either operating system tended to follow the UI standards pretty well, with the main exception being games. Microsoft started to try new things with Office, so if you wanted to see where the standard was going you just had to look at where Office was.
  - bayesian_horse 8y ago
    I'd say this is a sign of more and more people developing software, and with ever more diverse motives. If your motive is to sell lots of copies to lots of people and make lots of money to it, investing energy into UI refinement makes total sense. If you just have to scratch an itch, maybe it doesn't.
Const-me 8y ago
> I'm sure that installing Atom and VS Code would introduce me to two more file pickers. I’m sure they will both use the same one. I don’t like Electron because slow and consumes too much RAM, but I have to admit they do have that unified API. It’s quite high-level, and relatively stable because there’s only a single implementation.
ti_ranger 8y ago
> 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 still miss this greatly. I just use NFS and autofs. Sure, it's a few seconds more effort to set it up, but it's a once-off cost.

meditate 8y ago

>someone to make a decision about the one true way to do things. Things don't really work this way in free and open source development. There is no one person to make decisions, consensus is reached when the quality of something raises "above the bar" and actually improves things for all involved parties. If someone wants there to be an über-library that serves everyone's use case then it's up to them to go and do the work to build that. And it has been getting better in this regard. For example KDE and GNOME used to have their own IPC, multimedia & audio mixing backends, but now both have converged on DBus, GStreamer and PulseAudio, in part because these were intentionally built to be flexible low-level solutions. I'm sure there are more examples of this too but those are the first that come to mind.

Mister_Snuggles 8y ago
You're absolutely right. I wonder if something like DBus and PulseAudio could happen with my UNC pain point. With the assumption that the goal is for "vi //server/share/file.txt" to work the same as "notepad.exe \\server\share\file.txt" does on Windows, here are my thoughts. First off, notepad.exe doesn't really care about the fact that it's a UNC path. It just opens the file with CreateFile (either CreateFileW or CreateFileA). There would need to be replacements for the libc file functions. These could be a shim in front of libc, or baked right into libc. Note, there's a LOT more needed than "just" new file functions - any functions that do anything with paths need to be looked at. Shells would likely need some changes to work properly, though it's not like the Windows shell can truly do much with UNC paths - copying files to/from works, but you can't cd into them. How does it ask for credentials? If it's via DBus, a desktop environment provide the authentication prompts, but what about a pure-commandline system? Maybe the transport is just SSH and relies on the existing public key authentication? But what if you're just doing a one-off thing and don't want to set that up? Using SSH is probably a decent idea since it's got authentication, security, and a file transfer protocol, already built in. On top of all of this, when you open //server/share/file.txt for writing, what does that actually mean? Is there a file descriptor? How does that work with the kernel? Does libc now manage all file descriptors with only a subset corresponding to kernel file descriptors? Could a pure user-space solution fake this well enough to actually work? Would this need to be a FUSE filesystem along with some daemon to automatically unmount the remote servers when the mount is no longer needed? Would it be something like the automounter, just a lot better? Does a kernel need changes for any of this to work? This is one of those things that touches so many layers and potentially interacts with so many parts of the system, potentially all the way down to the kernel. My guess, and I don't actually think this will happen, is that Apple will do something like this on Mac OS X and have a reasonable mapping to the BSD world underneath, then someone in the Linux community will come along and do something similar in a way that's better suited for Linux. As a parallel, Apple came out with launchd in 2005 to replace init scripts, systemd made an appearance in 2010 - both do very similar jobs, with launchd tailored to the needs of MacOS and systemd tailored to the needs of Linux. Maybe something similar could happen with UNC-like file sharing.
- 8y ago

smallbigfish 8y ago

"On Windows, you can basically use a UNC path" How about NFS in Linux? It's a lot more transparent than SMB will ever be in Windows. SMB is and will remain a Windows feature.

Mister_Snuggles 8y ago
These aren't the same thing. In Windows, you can basically use a UNC path anywhere because CreateFile knows how to deal with it. The point is that you don't need to mount the remote filesystem (the Windows-equivalent being mapping a network drive).
- ti_ranger 8y ago
  I don't mount remote filesystems, autofs does it for me whenever I browse /net/$hostname

rhinoceraptor 8y ago

To be fair, the Arduino IDE is java swing, so it doesn't look quite right on any platform.

jcelerier 8y ago

arduino IDE is written in java with Swing, it looks weird on every OS

pja 8y ago

I'm sure that installing Atom and VS Code would introduce me to two more file pickers. Having just checked, both Atom & VS Code use the GTK/Gnome file picker. LibreOffice is also using the GTK/Gnome file picker.

bayesian_horse 8y ago

Windows doesn't have that kind of unique standard either. Both KDE and GNOME have user interface guidelines. If Software doesn't follow it, well...

Mister_Snuggles 8y ago
In recent years, Windows has become a mess in the UI space. Mac OS X has fared a little better, but it's also becoming a mess. It makes me sad. Years ago programs written for either operating system tended to follow the UI standards pretty well, with the main exception being games. Microsoft started to try new things with Office, so if you wanted to see where the standard was going you just had to look at where Office was.
- bayesian_horse 8y ago
  I'd say this is a sign of more and more people developing software, and with ever more diverse motives. If your motive is to sell lots of copies to lots of people and make lots of money to it, investing energy into UI refinement makes total sense. If you just have to scratch an itch, maybe it doesn't.

Const-me 8y ago

> I'm sure that installing Atom and VS Code would introduce me to two more file pickers. I’m sure they will both use the same one. I don’t like Electron because slow and consumes too much RAM, but I have to admit they do have that unified API. It’s quite high-level, and relatively stable because there’s only a single implementation.

ti_ranger 8y ago

> 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 still miss this greatly. I just use NFS and autofs. Sure, it's a few seconds more effort to set it up, but it's a once-off cost.