On Thursday 18 August 2011, Thiago Macieira wrote:
> On Thursday, 18 de August de 2011 18:59:09 Giuseppe D'Angelo wrote:
> > But, how should
> >
> > QUrl url("c:/tmp/foo #123.wav");
> >
> > be parsed then?
>
> If the constructor parses as URL only, then it's a URL with scheme "c",
> path "/tmp/foo " and fragment "123.wav".
That's what I would prefer. For a simple reason: I've used URLs to point to
internal resources in past projects and sometimes those end up having odd
schemes, like "c:/" or "q:/".
> If the constructor parses as URL-or-path, then on Windows it's definitely
> the file path.
>
> The question would be what to do on other systems if we parse as
> url-or-path.
What if I want to store a Windows path on a Linux machine, because I'm
writing a portable remote control software. If QUrl behaves differently on
different platforms, this means _more_ work instead of less.
Also, how should this be parsed: QUrl("/some/path")? or
QUrl("relative/path")?
On Linux the first would indicate a path or a URL for the current host, the
second could be a relative path or a relative URL. On Windows the first
could be a path on the current drive or a URL, the second could be a
relative path or URL.
I don't believe QUrl should do some fancy path-detection magic in its
constructor - this would lead to unexpected and inconsistent results. If you
insist on using a URL for storing paths it is not asked too much to properly
convert it with QUrl::fromLocalPath().
Konrad
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
