> You're right about FileRef taking only const char *, and yes
> QStringToTString doesn't help. But in addition, the function doesn't work.
> ÂI don't know if it's with the new qt libraries (I'm using 4.5.2). I took a
> Âlook at the macro definition for the function and it looks outdated. viz.
> #define QStringToTString(s) TagLib::String(s.utf8().data(),
> QString no longer has a utf8() function.
> But there is one thing I took away from this function that seems to work in
> addition to toAscii() and that's toUtf8().data().
> For some reason toUtf8().constData() doesn't work, but toUtf8().data()
> TagLib::FileRef tagFile(qstr.toUtf8().data());
> Would this be a more preferable way to do it than toAscii()?
> PS: I also noticed that both Qt and taglib support utf16, but I tried it
> Âand it didn't work and also I don't know much about UTF.
> 2009/12/6 LukÃÅ LalinskÃ <lalinsky@xxxxxxxxx
> > On Sat, Dec 5, 2009 at 10:29 PM, Michael Pyne <mpyne@xxxxxxxxxxxx
> > > On Saturday 05 December 2009 15:25:13 Plasty Grove wrote:
> > >> That makes sense, but even the following doesn't work:
> > >>
> > >> QString qstr = "/home/mydir/music/song.mp3";
> > >> QByteArray qbArray = qstr.toLocal8Bit();
> > >> const char* str = qbArray.constData();
> > >> TagLib::FileRef tagFile(str);
> > >>
> > >> In this case, I've got a local object which stores the value returned
> > >> by toLocal8Bit() and which is in scope when I'm using str. Does
> > >> qbArray get destroyed whenever constData() is called on it? When I'm
> > >> debugging, I
> > can
> > >> still see str holding a value when it goes to the next step.
> > >
> > > Perhaps an encoding issue if you don't use straight US-ASCII for your
> > file
> > > names? In that case if "local8Bit" is not the encoding Taglib is
> > expecting
> > > you'll get weirdness.
> > >
> > > The KDE JuK music manager uses taglib and has TString/QString
> > > conversion
> > code
> > > (and I'm sure Amarok has the same thing) if you want to see how those
> > projects
> > > do it.
> > TagLib::String will not help in this case, because it also represents
> > Unicode string, like QString. FileRef's filename parameter on
> > non-Windows platforms is char*, so you need the actual encoded bytes.
> > In Qt you can use QFile::encodeName(string) to encode the filename the
> > same way Qt does it for file dialogs or other places that interact
> > with the filesystem. This can still fail in some cases (different
> > mounted filesystems using different encodings), but it's the best you
> > can do if you store filenames as Unicode strings.
> > --
> > Lukas Lalinsky
> > lalinsky@xxxxxxxxx
> > _______________________________________________
> > taglib-devel mailing list
> > taglib-devel@xxxxxxx
> > https://mail.kde.org/mailman/listinfo/taglib-devel
taglib-devel mailing list