I was contacted as Debian maintainer of Audacity to weigh in
on the issue of gtk2 and unicode issues with wxgtk. Since
I'm not that familiar with the ramifications, I wanted to pass
----- Forwarded message from Ron <ron@...> -----
Date: Fri, 10 Jan 2003 13:44:32 -0800
From: Ron <ron@...>
To: Andreas Tille <tille@...>, "Kevin M. Rosenberg" <kmr@...>,
Robert Millan <zeratul2@...>, Wookey <wookey@...>,
Yooseong Yang <yooseong@...>,
Daniel Martin <fizbin@...>,
Josselin Mouette <joss@...>,
Joshua Haberman <joshua@...>
Subject: gtk2 and unicode
Ok, I'm trolling for opinions here as much as giving a heads up
for the future. Email along the lines of "why aren't you using
gtk2" is starting to flow in already and I need to know what works
for you people in particular.
IMO the biggest advantage to switching to gtk2 is the possibility
for unicode support -- it is also one of the biggest problems, since
unless you are using wxChar and _T("foo") (or _("foo") for i18n
literals) everyewhere in your apps, they are going to fail to compile
and/or run under wx-gtk2-unicode.
Of course you should already be doing this in any case, but it's a
fair bet to assume not everyone is doing it everywhere yet.
What I'm after then is some idea of how people want to manage this
transition -- my current plan is to switch to gtk2 when debian makes
this the default gtk version in sid, and at that point I'll probably
switch to use unicode as well.
Before then you'll need to update your apps to be wide char safe,
and/or hassle upstream maintainers to do the same.
I am likely to fairly strongly resist the 'easy' suggestion that
we just have all possible combinations in sid together on two
fronts -- one being that I don't really want to compete with X, KDE,
Gnome etc. for: most packages in the distro, most open bugs, longest
time to build. -- the other (more importantly in my mind) is that wx
is already confusing enough to many people in its numerous permutations
and multiple parallel lib flavours that we should try to keep the
available versions in debian as relevant and simple as possible.
Ideally we'll have a single package of the current stable release
conforming to whatever the current notion of 'best practice' is and
current Debian defaults, and whatever legacy packages we need to support
people until they transition to the new 'head'. When new development
releases stabilise enough to be useful, I'll introduce them for early
migration testing and then yank them once the new stable version is
How does this sound?
Lastly, I'm probably going to do something semi-evil for the mesa5 soname
change and just replace/conflict the next 2.4 packages with the existing
2.4.0. I'll almost surely have to bump the soname of wx (I'll try to
keep it to just the gl lib, but that may cause even more problems than
it solves), so you might have to rebuild with a dep on > 2.4.0 after the
next upload. On the whole that seems the best way to get from where we
are today to where I hoped we'd be after the first upload. There is
certainly no reason to keep the mesa3 version floating around if mesa5
will build on all arches. Branden has new xlibmesa5 in incoming so
I'll see how that is doing before making a final decision.
----- End forwarded message -----
Debian GNU/Linux developer