Question about KUrl::equals/cmp...

[David Faure]

On Thursday 05 November 2009, Dawit A. wrote:
> The issue with KUrl however remains because the option name is confusing
> to  say the least and that same option produces different results in
> urlcmp.

I agree. And many months later, here's a suggested fix for it:
* a new flag that allows to request that "empty path" and "/" are treated the 
same (I still maintain that it makes sense that they are not, by default, even
path(RemoveTrailingSlash) doesn't turn "/" into "").
* making urlcmp call KUrl::equals instead of having a different implementation
* documentation for CompareWithoutTrailingSlash that explains the no-path case
* unittests for both urlcmp and KUrl::equals, both for "subdir with and 
without slash" and "no path vs just /".

This makes KUrl's behavior more documented and logical, but of course it 
changes behavior for existing code that was using 
urlcmp+CompareWithoutTrailingSlash. In web-browsing cases, AllowEmptyPath 
should be added to get the previous behavior.
Well, let me provide a patch for that, too. I ported khtml's uses of urlcmp to 
KUrl::equals (to avoid re-parsing of existing kurls) and added AllowEmptyPath.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: urlcmp.diff
Type: text/x-patch
Size: 7128 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100430/06732eb8/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: khtml_part.diff
Type: text/x-patch
Size: 1502 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100430/06732eb8/attachment-0001.bin>