KDE on Linux used to have something similar in the late 90s - it allowed you to open a website URL as a directory listing, so you could browse the site's asset directories and open image files, etc. Think like a client-side generated version of Apache's index pages, but using your local file manager. It was a plugin to the VFS framework (KIO) the desktop and all the apps use, so it would also work e.g. in Open File dialogs from anywhere within the toolset.
I remember using this regularly to mass-download the images embedded into a page - open the page this way by replacing http:// with a pseudo-protocol, copy all, paste, done.
KDE always came with a lot of VFS trickery like that. Ripping a music CD into MP3s was similar - you'd open the volume in the file manager and see your tracks along with a virtual folder full of MP3 files. The rip and encoding would happen on the fly, and you could do this e.g. straight from the file attach feature in an instant messenger.
Desktop Linux was a lot less friendly to get working smoothly back then compared to now, and feature discovery was by word of mouth more than anything, but it sure felt like living in the future early.
Reading your comment, it also came to my mind this inter-process communication from KDE called DCOP, which allowed you to call methods from KDE applications supporting DCOP from the command line or shell scripts. For example, the Konqueror web browser exposed functions to open tabs, navigate to URLs... instant messaging applications allowed you to query your contacts' online status, send a message, the music player would let you control the playlist, etc.
It then (IIRC 15 years ago) became deprecated in favor of DBUS, but I remember it was not as straightforward and simple to use as DCOP was, and also the applications, at least by the time, weren't supporting lots of useful operations with DBUS.
> Ripping a music CD into MP3s was similar - you'd open the volume in the file manager and see your tracks along with a virtual folder full of MP3 files.
AudioCD KIO is still working the same way. I'm ripping an old audio CD of mine to FLAC as I write this comment.
KDE's one of the oldest and best maintained feature is KIO backend. It's still alive and kicking as hard as in 3.5.x days.
Yeah, KIO is an awesome piece of software. Yesterday, a fuse interface was released[1] so that non-KDE software in Plasma also get most of the benefits of KIO.
And speaking of browser tabs, Plasma Browser integration allows to switch to an open tabs from Krunner directly and it works with Firefox, Chrome and Microsoft Edge.
I had no idea kio-fuse was being worked on. This is awesome! gvfs (and its FUSE implementation) was my favorite feature of GNOME and was the reason I primarily used Nautilus on KDE on my work VM.
Yes, finally in 2020 Dolphin can open a file from an SMB shared folder without making a local copy, which basically made KDE unusable in any environment that involved editing files on a Windows share.
Took a while but it does work, bar a few minor issues. I have problems with certain applications not understanding Dolphin has already authenticated to a share. For example VLC will only open a file if the URI to the share contains the user name required to authenticate (smb://user@fileserver/Video).
I think the first OS with this functionality to be IRIX 6.3 in early 1996. It integrated Netscape Navigator to the 4DWM file manager, and allowed you to browse both HTTP and FTP, and also audio CDs and even audio DATs if you had a DDS drive!
The problem is that too many dump GNOME and KDE for their twm flavour window manager and then it is no wonder that these ideas get lost among GNU/Linux users.
Perhaps GNU/Linux should decide what it wants to be, besides yet another UNIX kernel clone.
That is how Android and ChromeOS happen, or FOSS developers end up buying a BSD based proprietary desktop OS, or even Windows based systems, to develop software for GNU/Linux based cloud environments.
Which supports your feeling that the current (dominant) systems are dumbed-down. I don’t want to think about the security implications of the carious implementations on this long holiday weekend... but if we needed to spend less energy on security we could have nicer toys.
They aren't dumbed-down, the features are there, used on macOS, Windows, to certain extent by iOS and Android IPC, GNOME and KDE apps, they just aren't used by those that think using twm clones and the CLI are the epitome of UNIX desktop experience.
I suspect it would be harder to pull off these days without launching chrome headless for example. Opening the page itself wouldn't include images/resources loaded over JS. It would also not work great with image atlases.
So one thing really cool about KIO is that any KDE application can understand KIO URIs.
You can paste any KIO URI into any application's file open dialog box and it'll retrieve it. So for example, you could open any KDE media player, paste in an audiocd:// URI, and it'll play the specified track from your CD.
And it also meant that any application could open remote files without having to manually download them first. Like, if I wanted to open some random file off the web in a text editor, I can just go into Kate, hit Ctrl-O, and paste its URL into the dialog box, and it'll fetch it into a temp folder and open it without me having to first download it manually. This was especially useful for PDFs, because Okular is generally way better than any browser's PDF reader (and I was doing this before most browsers came with PDF readers).
How does it work internally for non-KDE apps? GNOME's equivalent, GVFS, uses real FUSE paths at /run/user/1000/gvfs. Does KIO do the same thing, or copy them to a temporary directory before sending the path to the application?
I think KDE still supports Konqueror, which implements things like this. It used to be KDE's file manager and web browser all in one app. I always found this to be quite logical. The underlying abstraction is called KIO. Unfortunately I have no KDE installation at hand, so I can't tell if dowloading all images of a webpage still works as easily. The Audio CD ripping feature should work without problems, though.
Btw Konqueror also used/uses the KHTML rendering engine, which was the foundation for WebKit.
I think that was one of the casualties of the painful transition from KDE 3 to KDE 4. I really loved KDE before but KDE 4 was completely unusable for a year and many UX concepts were thrown aboard or have just not been ported, really sad actually. KDE 3 was paradise for power users. I wonder what KDE is like nowadays though
I don't think it was KDE 3 -> 4 transition that killed khtml.
I was only around in the last year or two but KHTML [0] was mostly developed by a single volunteer on his spare time (Hi SadEagle in case you're reading this). There were occasional commits by other people but the majority of KHTML's development was done by him.
You see, Konqueror as a web browser didn't even have a single full time developer. That was the beginning of browser wars when Apple and Google were both funding Safari and Chrome with millions of dollars.
It was not really feasible for KHTML to compete with so many new specs being introduced to the web.
It's still fascinating what they achieved though. At the time KHTML was the first to pass ACID2 test and beat competition performance-wise in many aspects.
This is all what I can recall so don't consider it 100% accurate but I'm pretty much sure about the main point, which is that it simply was not viable to develop khtml from a practical standpoint.
[0] Quick note that Konqueror itself was created and maintained by David Faure, who maintained KDELibs (Before it became KDE Frameworks). David was a sponsored full time developer but he wasn't doing a lot of work on KHTML and KJS (The browser aspects of Konqueror)
That's fascinating, also that it was written by a single person. I remember how surprised I was when I discovered that Konqueror was at that point in time on par or better in terms of rendering quality compared to Mozilla and others. Also browser speed, memory usage etc. was just flawless. But yeah, IMHO one person projects are doomed to be abandoned unless the person is really dedicated to that project. (glibc maintainer Ulrich Drepper is probably a well-known counter-example)
> It used to be KDE's file manager and web browser all in one app.
It goes further than that. It's pretty much everything in one app. KIOs accesses stuff and KParts shows it. Since many applications expose their functionality using those, it can show whatever content they support and browse it as a filesystem when it's possible.
Web browsing is just KIO doing http and a KPart showing the page. File management is just the file (or smb or sftp or whatever) KIO and the Dolphin KPart. The Kate KPart is used in both cases to either view local text files or web pages source.
But there are others and you can do any combination, including some cool ones.
You can go to man:// or info:// to view man/info pages.
The Akonadi KIO from the PIM suite can be used to browse remote mail or calendar accounts and extract data.
It even used to be possible to use magnet links in HTML (like in <video src="magnet:...">) with kio-magnet or to browse mysql databases and use applications to edit content in cells with libferris, although I don't think those are currently maintained.
Han, I completely forgot I used to do that. Indeed, that type of feature felt incredibly powerful back then. And Browser tabs were new anyway. ( Limited to Opera only IIRC )
I remember using this regularly to mass-download the images embedded into a page - open the page this way by replacing http:// with a pseudo-protocol, copy all, paste, done.
KDE always came with a lot of VFS trickery like that. Ripping a music CD into MP3s was similar - you'd open the volume in the file manager and see your tracks along with a virtual folder full of MP3 files. The rip and encoding would happen on the fly, and you could do this e.g. straight from the file attach feature in an instant messenger.
Desktop Linux was a lot less friendly to get working smoothly back then compared to now, and feature discovery was by word of mouth more than anything, but it sure felt like living in the future early.