| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 3 | |
Hi, can some one help with that question? I have two Qfile objects file1 and file2. Now I want to get a QString that contains the relative path from file1 to file2. Thx Eckhard -- [ signature omitted ]
Its not part of qt... But its pretty simple (google it if you need two) Essentially, convert both to absolute paths Split the paths by directory separator Remove common paths starting with the drive or root separator Replace uncommon with ".." Scott > -----Original Message----- > From: Eckhard Jokisch [mailto:e.jokisch@xxxxxxxxx] > Sent: Friday, January 18, 2008 11:12 AM > To: qt-interest@xxxxxxxxxxxxx > Subject: Tqo files how to get the relative path > > Hi, > can some one help with that question? > I have two Qfile objects file1 and file2. > Now I want to get a QString that contains the relative path from file1 to > file2. > > Thx > Eckhard > > -- > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with > "unsubscribe" in the subject or the body. > List archive and information: http://lists.trolltech.com/qt-interest/ -- [ signature omitted ]
Scott Aron Bloom wrote: >Its not part of qt... >But its pretty simple (google it if you need two) > >Essentially, convert both to absolute paths >Split the paths by directory separator >Remove common paths starting with the drive or root separator >Replace uncommon with ".." Actually, it is: http://doc.trolltech.com/4.3/qdir.html#relativeFilePath -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
When was this added? I wrote my function about 3 years ago (qt 3.3 timeframe) and haven't changed it :) But I have searched for it since. Scott > -----Original Message----- > From: Thiago Macieira [mailto:thiago.macieira@xxxxxxxxxxxxx] > Sent: Friday, January 18, 2008 1:32 PM > To: qt-interest@xxxxxxxxxxxxx > Subject: Re: Tqo files how to get the relative path > > Scott Aron Bloom wrote: > >Its not part of qt... > >But its pretty simple (google it if you need two) > > > >Essentially, convert both to absolute paths > >Split the paths by directory separator > >Remove common paths starting with the drive or root separator > >Replace uncommon with ".." > > Actually, it is: > http://doc.trolltech.com/4.3/qdir.html#relativeFilePath > > -- > Thiago José Macieira - thiago.macieira AT trolltech.com > Trolltech ASA - Sandakerveien 116, NO-0402 Oslo, Norway -- [ signature omitted ]
Scott Aron Bloom wrote: >When was this added? I wrote my function about 3 years ago (qt 3.3 > timeframe) and haven't changed it :) Just before 4.0.0 was released. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Learn something new every day... I have noticed a couple of differences between it and my implementation... 1) QTs returns a unix separator on windows... 2) QTs return empty rather then "." when you ask for a file/dir that is relative to itself... While this may or not be problematic, most of the implementations I have seen return a "." 3) QTs does not return a leading "." when the dir is the parent dir But other then those minor things... I'm glad I found this... I can now remove 100 lines of code or so :) Scott > -----Original Message----- > From: Thiago Macieira [mailto:thiago.macieira@xxxxxxxxxxxxx] > Sent: Friday, January 18, 2008 1:48 PM > To: Scott Aron Bloom > Cc: qt-interest@xxxxxxxxxxxxx > Subject: Re: Tqo files how to get the relative path > > Scott Aron Bloom wrote: > >When was this added? I wrote my function about 3 years ago (qt 3.3 > > timeframe) and haven't changed it :) > > Just before 4.0.0 was released. > > -- > Thiago José Macieira - thiago.macieira AT trolltech.com > Trolltech ASA - Sandakerveien 116, NO-0402 Oslo, Norway -- [ signature omitted ]
On 18.01.08 14:24:51, Scott Aron Bloom wrote: > Learn something new every day... I have noticed a couple of differences between it and my implementation... > > 1) QTs returns a unix separator on windows... No it returns a "Qt separator", because it expects that you're going to use that path again with Qt. And Qt translates / in strings to \ internally when it actually goes to the FS. > 2) QTs return empty rather then "." when you ask for a file/dir that is relative to itself... While this may or not be problematic, most of the implementations I have seen return a "." The problematicness of this really depends on your use-case. For example if the relative path is a subdir, i.e. never contains ".." anywhere, its nicer to have only an empty string. For example in KDevelop I have the project name and then the relative path of the item inside the project. "." is just superfluous there if its the project item itself. > 3) QTs does not return a leading "." when the dir is the parent dir You mean for the relative path between /usr/local/lib and /usr/local, Qt returns ".." only while your code returns "./.."? (maybe with trailing slash) That aligns properly with 2), i.e. they omit ".". Andreas -- [ signature omitted ]
> > 1) QTs returns a unix separator on windows... > > No it returns a "Qt separator", because it expects that you're going to > use that path again with Qt. And Qt translates / in strings to \ > internally when it actually goes to the FS. This is inconsistent then... Well of course its as consistent as the rest of QDir/QFile/QFileInfo are :) Some will return the platform specific separator... Others always return the unix... Of course... none always return windows :) My thoughts are... it should always return platform specific... Since the QT classes can use either... its no harm no foul there. However, if your presenting it to a user directly, and you want to make the presentation clean, I shouldn't have to do a replace afterwards... > > 2) QTs return empty rather then "." when you ask for a file/dir that is > relative to itself... While this may or not be problematic, most of the > implementations I have seen return a "." > > The problematicness of this really depends on your use-case. For example > if the relative path is a subdir, i.e. never contains ".." anywhere, its > nicer to have only an empty string. For example in KDevelop I have the > project name and then the relative path of the item inside the project. > "." is just superfluous there if its the project item itself. Absolutely, and in my implementation, I have a Boolean parameter "addLeadingDot" which by default is true, but can be turned off for cleanlyness : > > 3) QTs does not return a leading "." when the dir is the parent dir > > You mean for the relative path between /usr/local/lib and /usr/local, Qt > returns ".." only while your code returns "./.."? (maybe with trailing > slash) That aligns properly with 2), i.e. they omit ".". Actually /usr/local/lib and /usr/local return "lib" vs "./lib" Scott -- [ signature omitted ]
On 18.01.08 15:18:09, Scott Aron Bloom wrote:
> > > 1) QTs returns a unix separator on windows...
> >
> > No it returns a "Qt separator", because it expects that you're going
> to
> > use that path again with Qt. And Qt translates / in strings to \
> > internally when it actually goes to the FS.
>
> This is inconsistent then... Well of course its as consistent as the
> rest of QDir/QFile/QFileInfo are :)
>
> Some will return the platform specific separator... Others always return
> the unix... Of course... none always return windows :)
Huh? I thought all return unix-paths, except the toNativeSeparators?
Which ones do not do that?
> My thoughts are... it should always return platform specific... Since
> the QT classes can use either... its no harm no foul there.
Uhm, no. If you put windows paths into a QFileInfo on unix, that won't
work. Qt doesn't translate that to a unix path. Or rather it does, but
"\" is a proper character in a unix path, so QFileInfo("\\foo")
translates into <current-working-dir>/\foo
> However, if your presenting it to a user directly, and you want to make
> the presentation clean, I shouldn't have to do a replace afterwards...
No, presentation and storage of paths needs to be different, so at some
point you have to do a conversion. And with Qt you should store paths as
unix paths, thats the only cross-platform way to store em and directly
use them from your stored files.
> > > 3) QTs does not return a leading "." when the dir is the parent dir
> >
> > You mean for the relative path between /usr/local/lib and /usr/local,
> Qt
> > returns ".." only while your code returns "./.."? (maybe with trailing
> > slash) That aligns properly with 2), i.e. they omit ".".
>
>
> Actually /usr/local/lib and /usr/local return "lib" vs "./lib"
I meant /usr/local/lib is the base path (thats why I've written it
first), so the relative path from /usr/local/lib to /usr/local would be
"../" or "./../".
Andreas
--
[ signature omitted ]
> Huh? I thought all return unix-paths, except the toNativeSeparators?
> Which ones do not do that?
I filed it as a bug.. but there are a couple of QDir I believe that
return windows when your on windows and unix otherwise...
>
> > My thoughts are... it should always return platform specific...
Since
> > the QT classes can use either... its no harm no foul there.
>
> Uhm, no. If you put windows paths into a QFileInfo on unix, that won't
> work. Qt doesn't translate that to a unix path. Or rather it does, but
> "\" is a proper character in a unix path, so QFileInfo("\\foo")
> translates into <current-working-dir>/\foo
Misunderstanding of what I said... My intent, is all QString return
values should be in the format presentable to the OS its being run on...
So for instance, absoluteFilePath should return "/" based strings on
unix and "\" on windows...
>
> > However, if your presenting it to a user directly, and you want to
make
> > the presentation clean, I shouldn't have to do a replace
afterwards...
>
> No, presentation and storage of paths needs to be different, so at
some
> point you have to do a conversion. And with Qt you should store paths
as
> unix paths, thats the only cross-platform way to store em and directly
> use them from your stored files.
But I'm not talking about storing them....
I'm talking about purely about QString return value... How QT internally
stores them should be any thing they feel is most appropriate (unix or
for that matter using arrays depending on need/usage)...
But, if I ask for a string representation of a value, I'm asking for a
displayable object. If I wanted to store it, I would use QFileInfo, or
QDir depending on what the object represents...
But strings are for display... IMHO... your opinion may vary and I can
respect that...
As to cross platform... from a presentation POV you're not presenting a
cross platform solution... that's the beauty of QT... you're platform
specific on presentation... And again, my opinion, when a file based
object is asked for a string representation, you're asking for
presentation...
If you asking for it, to interact with native calls... then it doesn't
matter either... since the native call will take the native string...
Frankly, I have given up o nthis subject, since TT has said no to my
bugs... even when they were shown to be inconsistent :( SO I move on :)
Though I still would consider this a bug...
QString dir = QFileDialog::getExitingDirectory(....)
QString file = QFileDialog::getExistingFile(....);
QString relPath = QDir( dir ).relativeFilePath( file );
if the dir and file were "windows based separators" relPath should be as
well...
Scott
>
> > > > 3) QTs does not return a leading "." when the dir is the parent
dir
> > >
> > > You mean for the relative path between /usr/local/lib and
/usr/local,
> > Qt
> > > returns ".." only while your code returns "./.."? (maybe with
trailing
> > > slash) That aligns properly with 2), i.e. they omit ".".
> >
> >
> > Actually /usr/local/lib and /usr/local return "lib" vs "./lib"
>
> I meant /usr/local/lib is the base path (thats why I've written it
> first), so the relative path from /usr/local/lib to /usr/local would
be
> "../" or "./../".
>
NP ... then I misunderstood and you are correct.
--
[ signature omitted ]
On 19.01.08 01:05:38, Scott Aron Bloom wrote:
> > Huh? I thought all return unix-paths, except the toNativeSeparators?
> > Which ones do not do that?
>
> I filed it as a bug.. but there are a couple of QDir I believe that
> return windows when your on windows and unix otherwise...
I hope you don't count C:/foo/bar as "windows path". I'd still be
interested in an example (without having to try all the functions
myself), maybe you can find the bugreport number?
> > > My thoughts are... it should always return platform specific...
> Since
> > > the QT classes can use either... its no harm no foul there.
> >
> > Uhm, no. If you put windows paths into a QFileInfo on unix, that won't
> > work. Qt doesn't translate that to a unix path. Or rather it does, but
> > "\" is a proper character in a unix path, so QFileInfo("\\foo")
> > translates into <current-working-dir>/\foo
>
> Misunderstanding of what I said... My intent, is all QString return
> values should be in the format presentable to the OS its being run on...
> So for instance, absoluteFilePath should return "/" based strings on
> unix and "\" on windows...
Thats not portable, which is the whole reason to use QFile/QDir&Friends
in the first place.
> > > However, if your presenting it to a user directly, and you want to
> make
> > > the presentation clean, I shouldn't have to do a replace
> afterwards...
> >
> > No, presentation and storage of paths needs to be different, so at
> some
> > point you have to do a conversion. And with Qt you should store paths
> as
> > unix paths, thats the only cross-platform way to store em and directly
> > use them from your stored files.
>
> But I'm not talking about storing them....
>
> I'm talking about purely about QString return value... How QT internally
> stores them should be any thing they feel is most appropriate (unix or
> for that matter using arrays depending on need/usage)...
I'm not talking about internal storage in Qt. I'm talking about your app
using such a QString return value and storing it in some file. That file
might be exchanged via SVN and/or other means between OS's. The whole
reason of using QDir/QFile (apart from some convenience) is to be able
to use the same format for Qstring input parameters on all platforms.
> But, if I ask for a string representation of a value, I'm asking for a
> displayable object. If I wanted to store it, I would use QFileInfo, or
> QDir depending on what the object represents...
Huh? How do I store a QFileInfo? I'm not talking about a member variable
either, I'm talking about making that return value persistent.
> But strings are for display... IMHO... your opinion may vary and I can
> respect that...
Then we disagree here :)
Andreas
--
[ signature omitted ]