Thiago Macieira schrieb:
> On Tuesday 11 March 2008 10:52:14 David Faure wrote:
>   
>> On Saturday 08 March 2008, Thiago Macieira wrote:
>>     
>>> David Faure wrote:
>>>       
>>>>>  No. The next best option is still patching Qt, even if TT doesn't
>>>>> give a damn about the patch. That's their problem, not ours, and
>>>>> there's no point in complicating our lives by adding a duplicate
>>>>> function in kdelibs. Qt-copy/patches is not only for patches TT like,
>>>>> it's also for patches they don't like. Why do you think Qt3-based
>>>>> qt-copy patches has so many so old patches?
>>>>>           
>>>> API additions are a big no-no though.
>>>>         
>>> We're talking about making an already-existing static function a lot
>>> faster. I think it qualifies.
>>>       
>> Ralf said
>> "The patch is appended. It adds
>> static bool QFileInfo::isAbsolute(const QString &path);
>> static bool QFileInfo::isRelative(const QString &path);
>> [...]"
>>
>> That's new API, which can't go into qt-copy only if TT doesn't want it,
>> otherwise KDE will never compile with official versions of Qt, that's what
>> I meant. But apparently you guys at TT are okay with this patch so this
>> isn't a problem, I was only replying to "qt-copy/patches is also for
>> patches TT doesn't like": not if they add API.
>>     
>
> That's because Ralf designed the patch like that. He didn't have to add new 
> API.
>   
The QFileInfo methods are for convencience and because the previous 
QDir::isRelativePath() uses QFileInfo too. Only the 
QFSFileEngine::isRelativePath() and QFSFileEngine::isAbsolutePath()  are 
really required. 

If necessary I can update the patch.
> Anyways, I'm in the middle of testing the patch. Unfortunately, the QDir unit 
> tests we have did not work on my machine, so I needed to fix them in order to 
> get a baseline for comparison.
>
>   
is it located in the public qt sources ?

Ralf