Re: Rer [Wxruby-dev] Building on OS X...SUCCESS!

[Kevin Smith]

On Fri, 2003-07-04 at 00:01, Gour wrote:
> wxtest.cpp:5: no matching function for call to `wxString::wxString (const 
> char[1])'
> /usr/local/include/wx/string.h:288: candidates are: wxString::wxString(int)
> /usr/local/include/wx/string.h:293:                 wxString::wxString()
> /usr/local/include/wx/string.h:295:                 wxString::wxString(const 
> wxString &)
> /usr/local/include/wx/string.h:310:                 
> wxString::wxString(__wchar_t, unsigned int = 1)

Aha! Your wxWindows was compiled to use unicode (wide chars).

We do want to support that mode--it's one of the reasons the freeRIDE
team is interested in wxWindows in the first place. But I'm not sure we
can support it yet.

It looks like we'll need to call a different constructor, passing an
additional object that can convert UTF-8 to unicode. (Assuming we want
to specify UTF-8 for all ruby strings that get passed into or come out
of wxruby).

Unfortunately, the wxWindows folks apparently didn't include the same
constructor signature for the non-unicode version. So we'll need to have
completely different C++ code for unicode and non-unicode versions of
wxRuby.

We can hide this behind a macro ourselves, but every current call to a
string constructor (and some other methods) will have to be switched to
use this macro. If we were already using templates everywhere, this will
be easy. Trying to support unicode before then will be tedious and
possibly error-prone.

So, for now, if you can get a non-unicode version of wxWindows, it
should work fine for you. Otherwise, I think you'll have to wait a bit,
unless you want to work on the wxruby code yourself.

After we get the 0.1 Alpha release out, I'll spend more time thinking
about this to see if there is an easier way to support unicode. I do
think it is important.

Thanks,

Kevin