[Wxruby-dev] More concerns/problems

[Kevin Smith]

Greetings again. I'm hoping Park is still watching this list, because I
would like agreement on some changes to the official project as quickly
as possible. I would like to move forward, and would prefer not to fork
wxruby to get my work done. I consider the first three items to be
fairly urgent.

1. First, I would like to get an empty skeleton wx.h added to the
official sources. Every .cpp module should include wx.h, so we have a
place to put code common to all modules, such as my Ruby 1.6
compatibility wrappers. It could be named something different. It should
probably perform the includes of wx/wx.h and ruby.h so each .cpp file
doesn't have to.

2. I am still concerned about naming our shared library wx.so. What
happens when the perl or tkl folks want to create a wxWindows wrapper,
and also decide to call it just wx.so? From what I can tell, wxPython
appears to be named wxPython.so so I again propose wxruby.so or
wxRuby.so.

3. Does anyone know why wxNotebookSizer is not available on my system
with wxGTK 2.4.0? I have to comment out all the code that refers to it.

4. I noticed that many C++ methods that are invoked by Ruby (such as
WxApp::SetAppName) are declared as returning void. I thought this was
illegal, and that every C method invoked by Ruby had to return a VALUE,
such as Qnil. If true, this needs to be fixed to avoid possible
segfaults. But my templating system would make it easy to fix, so it
doesn't need to be fixed right away.

5. The current object allocation strategy is a bit odd. 'new' wraps a
NULL pointer as the object, and 'initialize' actually allocates the
wrapped wxWindows object. This means that if a Ruby app subclasses a Wx
class, and defines initialize, it MUST invoke super before doing
anything elwe. 

This seems like a brittle approach, and I would prefer to actually do
the allocation in 'new' instead. Fortunately, this is also the kind of
thing that will be easy after my templating system is in place, so I
don't think we need to change it now.

6. I notice that method names are upper case, which matches the
wxWindows standard but does not match the Ruby standard. As long as Ruby
won't get confused, I'm ok keeping them as upper case. I know Ruby does
treat variables differently depending on the case of the first letter,
so I'm slightly concerned.

Kevin