Qt 4.8 QUrl.toLocalFile behavior change, impacts to KUrl (and friends)

[Sebastian Trüg]

On 10/27/2011 11:35 PM, Thiago Macieira wrote:
> On Thursday, 27 de October de 2011 23:17:49 Milian Wolff wrote:
>> On Thursday 27 October 2011 21:11:11 Thiago Macieira wrote:
>>> On Thursday, 27 de October de 2011 13:32:51 Rex Dieter wrote:
>>>> See also,
>>>> http://bugs.kde.org/285028
>>>> ( and https://bugreports.qt.nokia.com/browse/QTBUG-22382 )
>>>>
>>>> In Qt 4.8, QUrl.toLocalFile now seems, by design, to return NULL for
>>>> urls
>>>> lacking any scheme.  Discovered this the hard way figuring out why all
>>>> my
>>>> audio knotifications were quiet.  Since audio event sources are simple
>>>> filenames, e.g. KDE-K3B-Finish-Success.ogg, and
>>>> QString soundFile = soundFileURL.toLocalFile();
>>>> no longer works.
>>>>
>>>> Any suggestions or advice on how best to deal with this?
>>>
>>> As we discussed on IRC, any string source must be properly labelled
>>> whether
>>> they are a URL or they are a local file. They cannot be both.
>>
>> is there at least a qWarning emitted in such a case, so we can find these
>> problems with QT_FATAL_WARNINGS=1 ?
> 
> No, but there's something better:
> 
> #define QURL_NO_CAST_FROM_QSTRING
> 
> Your code will not compile when you're auto-casting. You'll need to select 
> what to do:
> 
> 	QUrl::fromEncoded() - if it's a URL, with the "file" scheme
> 	QUrl::fromLocalFile() - if it's a file name
> 
> This option remains in Qt 5, but there there's going to be a new method to 
> convert from QString to QUrl without passing through QByteArray.
> 
> This is extremely important to get right because a filename and a URL are NOT 
> the same. Certain characters in the string are interpreted differently 
> depending on what the string is: %, # and ? in particular.
> 
> So, to be honest, the bug *already* *existed* in your code if you're finding 
> these problems now. I just made it blatantly clear, and it's been there for a 
> year for people to see.
> 
> I'm also calling right now KUrl's fromPathOrUrl a fatally flawed design.

Be that as it may but the fact remains that KDE potentially does not
work with Qt 4.8. Is that really a risk worth taking? I am all for fixed
semantics in the methods but this seems like a problematic case.

Cheers
Sebastian