4.0 Wishlist: KURL -> KDE::Net::URI + KDE::Net::URL
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.
Have the small things left to fix/add been done too?
- 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.
Posted in the wrong thread ;(
Also, what's the difference between KURL adn the current way?
KURL is the current way, KDE::Net::URL is the new/replacement class...
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...............
Namespaces / documentation
>> 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.
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.
Change for changes sake?
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.
Please remember you can also
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)
Re: Please remember you can also
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.
There are 3 reasons for splitting kdelibs classes, and especially kdecore, into namespaces:
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.
A few other points: