Ape tags, includes and portability
mETz
mETz81 at web.de
Tue Jul 18 16:57:02 CEST 2006
On Tuesday July 18 2006 16:28, Sebastian Pipping wrote:
> Lukáš Lalinský wrote:
> >
> > There are three ways how it could be done, with support for both APIs:
> >
> > * Windows-like way of doing this would be having two
> > TagLib::File contructors, one for wchar*, one for char*.
> > * Glib-like way, and using UTF-8 for file names.
> > * And one more option would be using TagLib::String instead of char*.
> >
> > I'd love to if TagLib 1.5 would include any of these solutions, but I
> > really don't like having it either Ansi-only or Unicode-only. In that
> > case I'd have to keep my own UTF-8 branch. :(
>
> --------------------------------------------------------
> i thought about your recommendations and i now strongly
> prefer the first one, the two-constructors-solution.
> this would save unnecessary conversions on windows and
> also not require two differently compiled versions.
> TagLib::String is not what i want since i mainly work
> with plain-c-"array"-strings.
Ok, so if I understand this correctly we would have
- File::File(const char *file)
which either takes utf-8 or ansi names on windows depending on the setting
made by the application. How will this work on unix? At least with Qt you can
either pass file.toLocal8Bit() or file.utf8() to this constructor so I see a
similar problem to ansi vs. utf-8 on unix-systems.
And we would have
- File::File(const wchar *file)
which always takes utf-16 on every OS.
Just correct me if any of my assumptions are wrong. I'd also favor this way
because developers can freely choose what they will support, I'd probably go
for utf-8 everywhere because Qt has good support for that :)
Bye,
Stefan aka mETz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/taglib-devel/attachments/20060718/5d57a041/attachment.pgp
More information about the taglib-devel
mailing list