[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Qt 4.8 QUrl.toLocalFile behavior change,
From:       Kevin Kofler <kevin.kofler () chello ! at>
Date:       2011-10-28 15:40:39
Message-ID: j8eido$oj4$1 () dough ! gmane ! org
[Download RAW message or body]

Thiago Macieira wrote:
> I'm also calling right now KUrl's fromPathOrUrl a fatally flawed design.

It is what real-world users need in a network-transparent application!

They will want to enter a file name in most cases, but if they need to open 
or save a file from/to the network, they have to enter a URL instead. If we 
don't have a fromPathOrUrl API, we have to do what it does again and again 
in every application to support what our users actually NEED. Users most 
definitely DO NOT WANT to have to write file: in front of every file name 
(the common case) (nor to have to encode all special characters in it), nor 
is it acceptable to just forego network transparency.

This basic principle is also why there is no KFileRequester, only a 
KUrlRequester (which supports a LocalOnly flag for when you really cannot 
support KIO network transparency for some reason).

It is trivial to decide whether something is a file name or a URL: if 
there's a scheme, it's a URL, otherwise, in this context, it's a file name. 
Of course, a relative path COULD refer to a remote location in other 
contexts, e.g. in links in web pages, where the context is the directory 
containing the web page. But in the contexts we are discussing here, the 
reference context is the local current directory, so relative paths are 
relative to that and thus always local.

Now we can argue that applications should in fact be using fromPathToUrl on 
those relative paths, then the new toLocalFile should also work for them. 
But the problem is, they currently don't, and your incompatible change 
breaks them.

        Kevin Kofler

[prev in list] [next in list] [prev in thread] [next in thread]