KDE’s URIs
October 13, 2006
Significant for KDE’s IO-handling is its use of proprietary URI schemes. As recently mentioned on the kde-usability list, there’s for example the home:/ scheme that when entered into Konqueror displays the content of the /home folder, more or less.
If “proprietary URI schemes” sounds all evil and wrong, it does so because it is. Registered schemes have an agreed meaning in a wide community. Proprietary URI schemes is like any other kind of interoperability breaking — like when Microsoft decides to add its own modifications and extensions to Javascript and CSS. Any piece of software understands file:///home while its only KDE applications using KIO that capiche home:/. That’s the best case scenario. Perhaps someone decides to behave and standardize a scheme by name home:/, which happens to have different semantics to KDE’s.
This is not a theoretical problem, see report #126847 for an example of where these homemade schemes cause trouble.
While I think I am correct in my bashing so far, one surely can add nuance to it. Many would probably say that KDE’s proprietary schemes is a necessary evil for making the usability of URIs reasonable. For example, they would claim that man:/cmake is better than tag:kde.org,2006:man:cmake(a use of the tag scheme to produce an interoperable URI).
I think arguing about URIs’ usability is in the wrong ball court, because URIs have bad usability no matter what. As soon URIs are advertised in commerials on TV, it’s never http://www.tv2.dk, they elegantly let it read tv2 dk.
KDE’s widespread belief in URIs perhaps stems from that developers fail to abstract from themselves and see it from the user’s perspective. That one can enter “gg: wikipedia” in Konqueror to automatically google for the term “wikipedia” is touted like the invention next to sliced bread. But how should users — except for the geeks — know how to use gg:, let alone know it exists?
The same could be seen in discussion on the kde-usability list: some didn’t know the home:/ scheme exists, which to me is fully understandable. I don’t see how users should be able to learn the pesky syntax details of using home:/, let alone a reason why.
Therefore, I don’t believe the right way to solve URIs’ poor usability is to use proprietary schemes. For example, googling quickly should be done with one of the well known approaches browsers take, and navigating man pages should not be enabled by having memorized the man:/ scheme, anyone should be enabled to it via a friendly interface.
Dropping down to the command line for interfacing the user is about a two-decades step backwards in usability.
PS. If you don’t want to use a proprietary URI scheme for your app, check out the KDE URI Guidelines.
October 13, 2006 at 1:34 pm
Wikipedia says this about the term “proprietary”:
“Proprietary indicates that a party, or proprietor, exercises private ownership, control or use over an item of property, usually to the exclusion of other parties.”
I don’t think that KDE is claiming ownership and/or preventing anyone from using things like “home:/”. Just because others do not use that system, does not mean that it’s “proprietary”. There’s nothing stopping GNOME (For example) using similar scheme, but for one reason or the other, they choose not to. And their decision to not use such a scheme is not due to KDE-folks telling them that “this scheme is our proprietary technology, so you can’t use it”.
Suppose that no-one except Linus Torvalds used Linux. Would that mean that Linux is “proprietary”, even if it were licensed under the GPL and all? No it would not. Just because something is not used by others does not automatically mean that it’s “proprietary”.
October 13, 2006 at 1:45 pm
Actually I DO think that gg:, wp: etc. and the possibility to configure your own search filters (I configured dict: for dict.leo.org search) is one of the best inventions since sliced bread. Well, not literally, ok, but it’s one thing I really, really LOVE in KDE. And thus, there doesn’t need to be only one way of doing things, I mean, you can still use the google search field to search on google and all the other search machines (switching between them is done in just two clicks). I do agree that home:/ is rather useless, and that man:/ may not be the only way to access man pages, but I would never remove the man:/ slot (nor the devices:/ one) as they make experienced users’ life much, much easier.
October 13, 2006 at 1:51 pm
Usability and interoperability are all good and nice. But please keep in mind that these proprietary uris are indeed the MAJOR advantage of konqueror above firefox. In konqueror i can search any of a dozen search engines by simply using the appropriate uri without ever touching the mouse. In firefox i have to deal with a slow and clunky search bar. While i agree that there should be a clunky search bar for the casual user, i see no reason for removing a VERY efficient tool.
October 13, 2006 at 2:24 pm
Don’t take this comment as stop-energy, but if you remove the custom URI from Konqueror, you remove stuff like easy SSH and device access, and you basically downgrade Konqueror to being a “simple” web browser, losing all competitive advantages against Firefox and friends. You could as well replace it with Firefox…
I am seriously worried by all this usability talk around KDE recently. This time would be best spent in creating an easy plugin system for Konqueror that doesn’t require C++ skills, because that’s the main disadvantage for Konqueror against competitors. A default python API for konqueror would kickstart a revolution.
But hey, that’s hard, so let’s bitch a bit about “usability” instead
October 13, 2006 at 2:37 pm
Usability is very important, but only when it is well understood usability. The Gnome approach of thinking every user is brain-dead makes me miss MS Windows (let alone KDE! ) every time I’m force to use a GTK desktop.
So yes, things should be easily accessible and make sense to casual and non experienced users, but hopefully KDE devs will have the good judgment to not screw the expert user in the process, as Gnomies have done.
October 13, 2006 at 2:53 pm
IIRC, URIs reserve schemes start with “x-” for private use. So, I’m pretty sure that using “x-man:cmake” would be acceptable to almost everyone.
If KDE want to submit a proposal to the relevant standards body (IETF?) to get “man” an officially recognised URI, then if it gets accepted I’m pretty sure that you’d *still* be able to use “x-man” for backward-compatibility for as long as you thought people still had URIs that matched it.
Although they’d probably prefer something like “help” as the schema name, and KDE would have to use something like “help:man/1/cmake” for man pages, “help:info/make” for GNU info pages, etc… But again, using “x-man” as a shortcut would anger no-one.
Using well-defined namespaces for extensions (such as CSS attributes starting with “-”, again built into the standard, and used at least by mozilla for their extensions) such that everyone *knows* which features are extensions and may go away/break/be replaced by something that does *mostly* the same thing in the future, is a good way to try out and test the effectiveness and implementation problems for features to be proposed in version n+1 of any standard.
October 13, 2006 at 3:35 pm
You are confusing the two types of usability. Useabiloity for expert, with useability for novices. Gnome famiously focuses on the latter at the expense of the former.
An expert is someone who has time to learn some complex task, because in the end that effort will save time. A novice by contrast does not have time to learn the tricks.
If you only search the web once a month, you can type google.com. If you search the web hourly it is worth your time to become an expert in KDEs searching, remembering gg:. As such we should leave our propritory URIs in place, but make sure they are documented in palces where only experts will look.
Everyone is a novice in some areas, and an expert in others. Tasks you do all the time are canidates for a sequence that can only be learned by training – if that sequence is the fastest way to do things.
Example: The phone company has (or had – I presume they still have this system) a system for information operators that is complex and fairly hard to learn. However it was carefully designed to make well trained operators faster. Compared to typeing names on a normal keyboard they save several keystrokes. As I recall they save 5 seconds per call – users will not notice, but the operators are able to process a few more calls per shift, and this saves them many operators and this big money. However it costs them several days additional training before a new operator can be useful.
I agree that the propritory URI scheme is a problem. However I disagree strongly with the useability for novices at the expense of useability for experts. Today you can safely assume that everyone has previous computer experience. The exceptions are mostly people who live in places without reliable electric service, or ‘luddites’ who will never touch a computer anyway.
October 13, 2006 at 3:40 pm
http://www.kdedevelopers.org/node/2231 might warrant another look?
October 13, 2006 at 5:15 pm
@Nik:
> In firefox i have to deal with a slow
> and clunky search bar.
Nope, you can just right-click on the search field in a webpage and choose “Add a keyword for this search…”. You get a very similar shortcut function like in Konqueror then.
October 13, 2006 at 5:25 pm
Well it started out promising, but you completely miss the point near the end of the post. Custom URI’s are not all evil, in fact most of them are amazingly useful, one of KDE’s core features I’d say. It’s just when you start inventing uri’s for places on the regular filesystem is when you start getting in trouble. man: is great, cause how do I access man pages otherwise without dropping to a command line? fish: is great, because it lets me access remote documents. media:\ is fucking horrible, because this stuff is basically local storage, but half the apps think it’s a remote file and refuse to open it. It makes a hell of a lot more sense to mount the media device at a regular path in the filesystem.
Try plugging in your camera. For me, kde opens a window with a URL like media:\Canon A540. If I double click a video, kaffeine opens and then complains it can’t open remote files. Now there’s some terrible usability. Remote files? On a locally plugged in camera? That makes no sense to anyone not familiar with what these URI’s are usually used for.
The new kubuntu finally gets rid of this misfeature. Now if I plug in my usb stick, it gets opened at /media/usbstick. Fantastic, all the apps work, no stupid urls. and anyway, since when is media:/Camera better than /media/Camera?
home:/ is similarly useless. Basically any URI that is just a location on the filesystem should be scrapped.
October 13, 2006 at 5:32 pm
Didn’t know home:// existed but to put it as politely as I can that is just bizarre.
Why not use ~/ the traditional abbrevation for the $HOME directory?
As for the use of the word “proprietary” in the sense of specific to KDE, it is not incorrect but it just isn’t the more commonly used meaning and may cause confusion so it might have better been avoided.
It should be mentioned that Firefox keywords allow you setup quick search link much like custom search URIs in Konqueror and this feature has existed since the days of Mozilla before Firefox even existed.
http://www.mozilla.org/docs/end-user/keywords.html
So to be clear the real advantage in Konqueror is not so much that this is possible but that it is already setup by default and you dont need to waste time configuring it if you move to a different machine. There is a lot to be said for having good defaults. (Actually it seems in firefox there are at least keywords searches setup by default for google, dict, and wp (wikipedia).)
> The Gnome approach of thinking every user is brain-dead
*cough* harsh. Gnome developer really don’t think “every user is braindead” but they are trying to make things very very easy and keep life pleasant for adminstrators by having very few ways users can shoot themselves in the foot. Granted there are obvious downsides to this approach but Gnome and KDE aren’t going for the same people so these are the differences we should be able to agree to disagree on. Besides there are plenty of very intelligent people who are busy doing other things like brain sugery
who dont necessarily have the time to learn how to get more out of their computers, intelligence isn’t the issue.
> Today you can safely assume that everyone has previous computer experience.
It is not so much experience as the fact that some beginners unfortunately stay permanent beginners. They use computers so infrequently they end up having to relearn things from scratch pretty much every time. At Akademy there were discussions about who the target users for KDE are and the honest answer was that KDE really isn’t aiming at that kind of absolute beginner anyway so there is no need to spend excessive time worrying about them just yet.
October 13, 2006 at 6:28 pm
Similar to above. See this bug:
http://bugs.gentoo.org/show_bug.cgi?id=150306
An example of KDE’s custom URI’s breaking interoperability (in this case, media:/ and system:/ breaking openoffice 2 trying to open documents). If there are errors in support for openoffice, this will drive away many potential users.
October 13, 2006 at 8:09 pm
I also think both Konqueror shortcuts like gg: and special IOslaves like man: should be kept. Using a standard URI instead of a custom IOslave makes sense where such a standard URI exists (e.g. home:, media: and probably webdav(s): too), but where there is none, the custom URI should definitely be kept! As for shortcuts which redirect to an actual URI, I don’t understand how they can hinder usability because people who don’t know them never see them. For those who do, they’re very useful! (I never use the search bar in Konqueror, I always use the gg: type shortcuts. In fact, reading this article reminded me of how useless the search bar is and got me to remove it from my Konqueror configuration.
) What about turning the redundant IOslaves like media: and home: into shortcuts too, i.e. having Konqueror replace them with the real URL automatically (as it does with gg: etc.)? That way they don’t get in the way (apps like OO.o should never see them), but can still be used.
October 13, 2006 at 10:11 pm
I couldn’t care less if something doesn’t work in a non-KDE app. I also couldn’t care less if something doesn’t work in Kubuntu (which, by the way, works on my Gentoo box just fine).
The URIs is one of the best things to ever happen to KDE. Remove them or even force use to have to append them with x- and you risk losing one of the best features of KDE. I don’t care if the average user never knows about it or uses it. It’s a killer feature for advanced users and removing it will just be one step on a series of many towards dumbing down KDE as bad as Gnome has been.
October 13, 2006 at 11:07 pm
How about kde:/man/ , kde:/media/ , etc? Okay, it looks kind of ugly but does keep everything in a single namespace.
October 14, 2006 at 12:32 am
there are a few issues tangled up into one big discussion here…
1) usability: yes, these URI’s don’t tend to get in the way of users. if they don’t know they exist, the don’t stumble upon them. however, the entire point of many of these URI’s is to allow applications to programatically access data in an abstract fashion. the remote places link in konq’s default about page is a nice example of this. whenever anyone starts talking about the usability of URIs for users i can’t help but think “but URIs aren’t for users. they are for the technically adept and applications.”
and that tag: soup style is just horrible =/ the people dealing with web and uri issues constantly lose track of the idea that they are designing for others who don’t obsess over these things, creating overly complex and often incomplete solutions. (personally i really dislike css for precisely these reasons, to deviate from the topic slightly
2) namespace issues. i have yet to see a real collision of namespaces, but if we wanted to protect against that it’s not difficult.
3) real problems. the only real world problem i’ve seen is that “virtual” url’s that don’t map directly to data cause problems. apps need to be patched to support these oddball uri’s. i do wonder if, instead of throwing the baby out with the bathwater, it would be possible to make the kio uri handling a bit more useful for application developers so the difference between webdav:// and http:// isn’t a problem. we have methods to convert paths using virtual protocols to real paths, which is a start. making it transparent to the developer would be very, very nice.
June 21, 2007 at 1:33 pm
So good enough for hot anime girl pics him to myself spiritually for.
June 30, 2007 at 2:46 am
There and replace big round butts the intense frustration? Was that the other hand slid under her wet.
November 5, 2007 at 9:23 am
femme plus sexy net Stepping to avoid anything at the encasing latex. Blindfold from herthighs.
November 28, 2007 at 10:28 am
celebrity nude oops
December 13, 2007 at 6:05 pm
Oh as young loli he falling in the foursome project is a trio.