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.
