SEP
14
2003

4.0 Wishlist: KURL -> KDE::Net::URI + KDE::Net::URL

Submitted by tjansen

I hope this becomes a loose series of various things that I would like to change for KDE 4.0. The code may appear in kdenonbeta/kdeutil where I keep utility classes for the KDE namespace.

Here is number one: KURL. KURL basically describes HTTP URLs which happen to be also usable for all other URIs that use the Common Internet Syntax from RFC 1738 Section 3.1. But KURL is not suitable for a growing number of URIs (read this if you do not know the difference between URLs and URIs) that use different syntaxes, like URNs, data: URIs and service: URIs. So I'd like to move some code into a super class called KDE::Net::URI that implements the scheme part that all URIs have in common, and then rename KURL to KDE::Net::URL, following the Namespace convention described in a previous post. This would make it possible to create classes for other schemes. Network-transparent code like KIO should use the KDE::Net::URI class, to allow the use of protocols that do not follow the Common Internet syntax.

Comments

Have the small things left to fix/add been done too?

examples:

- the menubar would be even more real if you’d only draw the lower part of it (and not left, right + top)

that toolbar separators are missing, there are a few other small theme fixes that could be made and it’s perfect.

By KDE User at Sun, 09/14/2003 - 17:18

Posted in the wrong thread ;(

Also, what's the difference between KURL adn the current way?

By KDE User at Sun, 09/14/2003 - 17:19

KURL is the current way, KDE::Net::URL is the new/replacement class...

By KDE User at Sun, 09/14/2003 - 17:28

i really hope we don't radically namespace everything possible in KDE4. why? because this will only make migrating code bases to KDE4 a giant headache. in the case of something like KURL we don't gain anything of consequence in renaming it to KDE::Net::URL while making developers make huge numbers of substitutions... yes, it's "nicer" and it can even be argued that it's "more correct", but the pragmatic reality is that the costs in code porting will be high. and no, perl scripts aren't magical: they lower the pain bar, but don't remove it. for code bases that are not regularly maintained (think 3rd party programs), this is even more poignant.

if we were finding that KDE class names were coliding on even a semi-regular basis with classes from other common libraries, i'd see this very differently.

personally, i'm all for making life as easy for 3rd party devels as possible while still improving KDE... so unless someone can provide an argument for why namespaces are such an important thing...............

By Aaron J. Seigo at Mon, 09/15/2003 - 06:59

>> so unless someone can provide an argument for why namespaces are such an important thing……………

One word: documentation.

Currently it just takes too much time to look up something in the KDE docs, all that because of this silly K in front of the class names.

So fixing it up to make use of namespaces _would_ make things easier for us 3rd party developers.

To me, looking up some method for KDE::Net::URL sounds much easier then looking up this KURL between all of those other Klasses because with the former you can obviously just browse to the KDE::Net section of the docs first, having less classes to choose from, making it faster to look up something, and in the end making KDE application development going faster since less time is spent on browsing the docs.

By KDE User at Mon, 09/15/2003 - 07:35

i really hope we don't radically namespace everything possible in KDE4. why? because this will only make migrating code bases to KDE4 a giant headache.

There is an easy solution for that problem: typedefs. If some compatibility-define is set all new class names should be typedef'd to their old names.
Beside that: if KDE4 is not the right time to clean up the class hierarchies, when is the right point? It will become more painful with every each major release.

By tjansen at Mon, 09/15/2003 - 08:20

I can agree with introducing a new base class to support URIs and URLs nicely, but I don't see what the point of replacing KURL with KDE::Net::URL. I think for such a commonly used a class a simple name like KURL is a better idea.

Rich.

By Richard Moore at Mon, 09/15/2003 - 12:09

Please remember you can also use namespaces without using the KDE or KDE::Net prefix each time..

KDE::Net::URL is insane, indeed.
URL, or Net::URL isn't.

- Rich (another one)

By KDE User at Mon, 09/15/2003 - 12:25

Sure but I'm often working with things like JS bindings so I'm likely to end up with a bunch of URL classes in different namespaces. This means I often need to list them explicitly. Even without this issue, I think KURL is hell of lot clearer than URL or Net::URL.

Rich.

By Richard Moore at Mon, 09/15/2003 - 13:17

There are 3 reasons for splitting kdelibs classes, and especially kdecore, into namespaces:

  1. Ease of use. There are currently >120 classes in kdecore which makes it difficult for developers to find functionality that they dont know. If you want, for example, a KDE function for starting applications you need to look at all 120 class names to find out whether there is a class that may help you. It happens quite frequently that people don't use kdelibs functionality
    because they don't find it, or ask on the mailing list for trivial features that are contained in kdecore. If you categorize the classes you make things easier, as you need to search only through 1-2 namespaces to find a class (maybe a KDE::Sys or KDE::Util namespace, but certainly not the KDE::Net namespace or most others). If kdecore grows it would get even worse.
  2. Modularization. In order to use kdecore classes in non-GUI applications like servers or for other non-desktop code they need to be split up. kdecore contains GUI-related classes like KIcon and KKeyNative that will not work with Qt4's core library and have some dependencies that you probably don't want on servers and embedded devices.
  3. Name conflicts. Without clear namespacing there will be all kinds of namespace conflicts as KDE libraries grow. Words like Service are overloaded, there is Service the .desktop file, Service as in WSDL, Service as in SLP, Service as in Apple's Zeroconf... a consistent naming with the K convention is not possible, unless you want to encode the category into the class name, and this would result in even longer class names. There are also potential naming problems when combing two libraries in a single application, e.g. when you want to use the KDE GStreamer bindings but for some reason also need to import the native API or their C++ bindings

A few other points:

  • as mentioned before, source-compatibility could be kept using typedefs
  • IMHO a change like this should be done ASAP to give the libraries a structure that can be kept for a long period, rather than postpone the change to make the KDE 4.0 transition easier and risk a even more painful transition later (there are other opinions though)
By tjansen at Mon, 09/15/2003 - 16:59

Pages