On Mon, Jan 21, 2008 at 09:29:03PM -0500, Barry deFreese wrote:
> We are currently in the process of trying to remove wx2.4 from the
> archive, hence the serious severity of this bug. There are 5 packages
> packages remaining depending on 2.4 and 3 of those are pending patches
> and/or uploads.
Survex actually works well with wx 2.6 and 2.8 (better than with 2.4 in
fact - it's irked me for some time that Survex is stuck with wx 2.4 on
Debian). And I certainly can see why people are keen to drop wx 2.4 and
Gtk 1.x at this point.
The problem is that Survex doesn't handle wide characters internally -
for Unicode it uses UTF-8.
The wx 2.4 packages Survex uses are what wx terms "ANSI", which really
means a single byte character set. The Debian wx 2.6 packages are what
wx terms "Unicode", which really means a double byte encoding.
So you can't just build Survex with the Debian wx 2.6 packages - you'd
have to either convert aven to use wide-byte Unicode (which as upstream
I'm afraid I'm unlikely to accept patches for) or wrap every place
where aven passes or receives a string from wx to convert it from/to
UTF-8.
I've asked Ron Lee in the past about doing ANSI wx 2.6 packages, but he
doesn't seem keen.
> I will attempt to try to help create a patch if that helps you at all,
> or maybe the 1.1.x versions are getting close to stable for inclusion?
Survex 1.1.x is pretty stable now, but has the exact same issues. If
you're going to try to address this, it would certainly make more sense
to do so in 1.1.x though. I'm currently in the middle of relocating to
the other side of the planet, but once that's done, I'm aiming to
finally push towards a Survex 1.2 release.
For the record, I think the correct way to fix this is to switch Aven
from using wxString to std::string, such that wxString only gets used
to talk to the wx API. So data in std::string is UTF-8 and data in
wxString is "whatever wx wants", which should make it harder to miss a
conversion.
We had enquires from Ubuntu people about a year ago offering to help with
migration, and I explained the issues, but never got any patches. I
also took a look myself more recently, but it's a mind-numbingly dull
job, so I decided to give up until wx 3.0 is out and see how things
look then.
Probably the easiest fix right now is to either package an ANSI build of
wx 2.6 (or 2.8), or if nobody else is at all interested in that, to just
bundle such a build with Survex (a full packaged wx variant build does
generate rather a lot of packages). Private builds are rightly
generally frowned upon, but policy does explicitly note that they're
acceptable if non-default compile-time options are needed.
Cheers,
Olly
