A few months ago, looking for a replacement for Windows (which always finds new ways to get on my nerves), I spent a couple of weeks playing with Linux Mint with MATE desktop. During this test drive, one of the annoyances I came across was the inability to drag a URL from Chromium’s address bar to create a link on the desktop. I literally ended up asking for help, and still didn’t figure it out.
In Windows, this is something I’ve been doing for many, many years. It’s not rocket science. You drag the padlock icon next to the address bar onto your desktop and a shortcut is created, pointing to that URL.
Ubuntu 19.10
Since Ubuntu 19.10 was released a week and a half ago, I thought I’d try it out. The first thing I figured I’d make sure was that I could drag and drop links to the desktop. Ubuntu is one of the most popular and mature operating systems around. Surely they’d support such a basic usability feature, right?
Well, it turns out that dragging links from default browser Firefox to the desktop has no effect whatsoever. Odd, isn’t it? Let’s try dragging that link to some other folder instead.
That’s annoying. I mean, drag and drop is a really basic feature that has been around forever. Let’s try dragging a file from one folder to another… obviously that’s going to work, no?
As you drag the file, a little plus icon appears beneath the hand as if to tell you that something’s going to happen. Alas, however, this also has no effect.
And of course, dragging the file to the desktop similarly does not work:
So we can’t drag links from Firefox, and we can’t drag and drop files. Maybe we’ll have better luck with Chromium?
So it seems, like someone hinted in that original question about drag and drop in Linux Mint, that this has nothing to do with the browser and is something related to the desktop environment.
Once again, I had to swallow that feeling of incompetence and ask for help with this. Aside from the usual Stack Overflow treatment of getting my question closed as a duplicate, one of the comments led to other Q&As that uncovered a bitter truth: that drag and drop support was intentionally removed. Why would anyone in their right state of mind do that?
Kubuntu 19.10
Incredulous, I decided to try the KDE flavour of Ubuntu — Kubuntu. Drag and drop a link from browser to desktop? No problem:
Was that really so hard? I get it, there were reasons why GNOME decided to do away with desktop icons and the like. But surely there are better ways to solve the problem than to do away with a basic and essential usability feature.
A desktop environment without basic drag and drop support in… almost 2020… is just garbage.
Totally agree- this is one of my bugbears of Linux.
Been using Mint for years and generally love it… but drag/drop and copy / paste of files is always a will it won’t it work – rather than Windows where it pretty much always works and has done since the Romans were in power….
Totally agree also! It is now mid 2022 Ubuntu v20 and STILL no drag-n-drop!
“bitter truth: that drag and drop support was intentionally removed. Why would anyone in their right state of mind do that?”
I can really not come up with one reason why one would remove such a basic and essential function!
I will assume that they simply could not make it work under all conditions.
Just like MS eliminated ShellBags when going to Windows 10.
They simply could not make it work under all conditions.
They wanted to eliminate all of the service calls due to running out of ShellBags at 5K or 10K or 20K ShellBags.
Appearantly MS just could not make it dynamic.
The default was 5K ShellBags and it cannot be increased beyond 20K ShellBags.
When you run out of ShellBags, Windows 7 starts to work just like Windows 10 that abandoned use of ShellBags, All new windows open on top of old windows and previous window positions are forgotten.
OpenShell on Windows 10 will use the ShellBags which are still in the registry.
Set the ShellBags to 20K ShellBags and OpenShell will make Windows 10 work just like Windows 7 until you run out of shell bags.
Then since MS saw fit to create a limited number of ShellBags, one must erase all 20K ShellBags and start over positioning your windows in their desired positions, just like used to happen in Windows 7 that caused all the service calls to MS.
This is why what a kernel is supposed to do is provide a unified API layer for basic functions like drag-n-drop rather than letting the GUI implement it in its entirety. No, the kernel doesn’t need to fully implement those functions, but the unifying layer should be there with all the basic hooks already in place. Then, userland programs which call for drag-n-drop can tell the GUI, which tells the kernel, which then propagates that call back to the GUI with all the necessary system information now attached.
Why not let the GUI fully roll their own? Because drag-n-drop implements core system and human interfacing actions that are only directly available to the kernel. As GNOME so bluntly shows, that ends up making GUI-only implementations inconsistent. Oh, and by the way, drag-n-drop IS inconsistent in KDE, though thankfully they didn’t strip it out.
Again, I’m not saying to take what is clearly a GUI-only feature and implement all the GUI stuff in a kernel! That would be madness. I’m saying to provide the basic filesystem/memory/hardware framework for a GUI to call within the kernel so that every GUI can have the basic fundamentals ready to use when they implement this feature. Though these features would only ever be used by a GUI, it’s not actually a GUI feature; it’s a kernel module intended to provide a bridge for GUI functionality.
Clearly, Microsoft once understood why this was necessary; just look at the COM Subsystem and WinRT. But modern Microsoft and also Linux devs do not.
However, despite my mention of WinRT, it’s severely hampered by .NET, which is ironic because it’s supposed to be platform-agnostic.
First, its .NET implementation requires many classes to be sealed. Why Microsoft did this sealing nonsense with so many base .NET APIs and then required it for non-base APIs is beyond my comprehension. You can literally copy/paste the code of these sealed classes, since they are not scrambled, so all sealing does is decrease ease of use and increase code duplication.
On the other hand, WinRT’s C++ implementation still suffers from the issues introduced by the dumb design decisions of .NET. I’ll say it again: you’re not supposed to design a platform-agnostic unifying API with the limitations of a non-unified programming language. Anyone who’s ever coded in .NET knows what I mean; it’s an amazing tool but the runtimes are version-specific like Python. Unlike Python, there is no pyenv.
COM does not have these problems because it’s implemented via C/C++. The devs back then didn’t have .NET so they couldn’t force .NET limitations onto everything. I get that the WinRT devs wanted interoperability with .NET, but when they ran into clear design conflicts, you’d assume they’d realize there were problems inherent to .NET…
Instead, they added .NET generics to C++. Does anyone see a problem with this? Like the fact that C++ doesn’t have a concept of generics?
That’s not because they implemented some great feature by adding generics, it’s because generics are f____ing useless in C++. Why would I store my data in a strictly-typed generic when I could do the same with normal C++ code that doesn’t have all of MS’s silly limitations?
The unsafe code/generics paradigm in .NET is plain idiotic. It’s a massive weeping bandage for poorly thought out strict typing. Here, want me to fix it? Get rid of dynamic typing. Instead, allow implicit casting between any type via user-defined implementation. In fact, allow implicit casting on a per-class basis. If I want to define double=int only within my “convclass()” then why not let me? The fact it’s user-defined means any coder can read these rules at the top of convclass() before they edit anything. Yes, this means more boilerplate, but it gets rid of that nasty dynamic type. Moreover, this per-class typedef is already half-done in C# with things like serialization and using statements, so this is not a big ask. F# doesn’t fully implement dynamic because of course it doesn’t, dynamic is awful.
What MS did instead was make a million different implementations of so-called ‘generic’ code structures and add upteen restrictions to make them work as intended. Yet, they kept ‘dynamic,’ the one data structure which violates their entire typing paradigm. They did this because all of those restrictions can cause the code to become unwieldy and confusing. Sometimes far slower, too, as my practice with unsafe code shows. WHY keep the friggin’ band aid when it’s clearly covering a much bigger problem?! You wouldn’t NEED unsafe code 99% of the time if you could implicitly cast between types without dynamic! Sheesh.
Now, as for Shellbags, I’ll bet the reason for the 20k limit is because they’re stored in the registry. Yes, the registry can handle a LOT more than 20,000 entries, but what devs don’t tell you is that traversal of a registry key containing a lot of sub-entries can get very slow. There’s no way that I’m aware of to read registry data into memory sequentially and then scan through it with a faster algorithm. You’re stuck with the crap Microsoft implemented 30 years ago. I think, the limitations of the registry and its central role in Windows development has become a huge sandbag on further development. Which is probably why Microsoft is slowly moving away from being an OS developer and is instead pivoting into business services and Azure.
Anyone with a brain can see NT is suffering from code rot! It’s got the same plethora of issues 9x once had, before Microsoft killed that kernel. Just look at the half-baked Windows UI they’ve been struggling to unify ever since WinRT… Oh right, WinRT, seems that came up again, huh?
Now you see why I ranted about WinRT. Like I said, modern devs don’t seem to understand the need for non-restrictive API unification layers. Let me repeat that: non-restrictive. Provide function calls – don’t tell devs what they can and can’t do with those function calls! If security is a problem, use code signing! These solutions have been around for decades, but nobody is f____ing using them properly.
Then again, I’m some guy who’s never coded for a kernel; who am I to judge, right? Smh.
Still the same issue on most Linux desktop. I have tested this with Chromium and Firefox on Debian KDE/Gnome, Elementary, Ubuntu, Fedora, MX Linux (KDE), Linux Mint, Deepin. The only one working out of the box is MX Linux with XFCE desktop environment. This basic things are what make difficult the user migration from MACOS and Windows to Linux desktop, i hope Linux developers fixes this soon.
Just do the same in Ubuntu, drag it to the desktop, not sure why it doesn’t work to a folder but it does to the desktop.