[Wxruby-dev] analysis of current code

[repeater]

hello
so i've had some time and made a little study of Park's wxRuby
implementation, and it looks a bit better than i've suspected. mostly i read
through the source, comparing wxPy with wxRb side by side.

notes about the differences:
----------------------------
(disclaimer: sources casually browsed, no guarantee of accuracy)

1.) all classes starting with "wxPy" were removed. this usually indicates a
python aware class, thus a wxwindows class modified with python constructs.
if we use a Cable-like system, we will not get this either, and if you look
at the src from this perspective it seems rather comprehensive.


2.)     %addmethods {} modifying existing wxWindows classes with Python API code
example:
wxListBox.GetSelections
        -probably converts selected items to python tuples
wxCommandEvent.GetClientData
        -something to do with python reference counting, perhaps ignore worthy
wxDropFilesEvent.GetFiles
        -probably converts list of files to python list
...
pretty much %addmethods{} with "PyObject" or "Py_" mentioned within the wxPy
source

btw, %addmethods is deprecated, we should use %extend


3.)     a lot of pragma(python) code that defines custom class specific events
(thus like the methods in _extras.rb)
e.g "def EVT_XXX()". easy to convert to ruby


4.)     files like helpers.h are completely removed, and in wxPy there is an
amount of "noise" that seems to link python comfortably into the wxWindows
world (think coexistence with threads for example). so it is not just the
definition of the components.

another example: %pragma(python) addtomethod =
"__init__:self._setOORInfo(self)"
there are may of those. the only reference to "OOR" i found in wxPy
CHANGES.txt
"
   Implemented the first phase of OOR (Original Object Return).  See
   the text in the demo for more details of what this means, but in a
   nutshell methods such as wxWindow.GetParent or FindWindowById will
   now return a shadow object of the proper type if it can.  By
   "proper type" I mean that if the wxWindow pointer returned from
   FindWindowById really points to a wxButton then the Python object
   constructed will be of a wxButtonPtr class instead of wxWindowPtr
   as before.  This should reduce or eliminiate the need for
   wxPyTypeCast.  (Woo Hoo!)  The objects returned are still not the
   original Python object, but that is the next step.  (Although it
   will probably only work on Python 2.1 and beyond because it will
   use weak references.)
"
this is an example of a thing i do not know if we'd need, hopefully owning
to ruby's C api superiority or an improved SWIG

well the demo runs doesn't it <worried smiley>


5.)     little apparently harmless optimisations (better swig version or ruby),
e.g:
%name(wxPreListBox)wxListBox(); ->  wxListBox();


6.)     this is my main observation and change to the code
there is "%addmethods {void Connect ...}" snippets in wxTextCtrl and wxFrame
(the two classes used in the cvs demo). i don't know why these are there,
but if you move both to wxEvtHandler like it should according to wxPy, it
makes other classes functional too.

in this %addmethods block, that is now under wxEvtHandler, there should also
be Disconnect declarations as i glance at wxPy.

======================

well, i do not know how many people are subscribed and whether they are
willing to help out, but i've made a list of possible things to do now.

i know the main developers are keeping this a bit on a hold, but if they or
others wish to help push this project into existence it would be great for
the ruby community. else i guess we'll have to wait until freeRIDE really
needs it (if indeed ever), and see what happens from there.

todo:
-----
1.)     we need tons of examples and tests, so i recommend that we port some of
the examples/demo provided with wxPython. that could be a cool thing to do
for people that want to make a contribution without much effort or
experience needed.

2.)     people with ruby c api knowledge can try to port wxPyXXX classes. these
are classes that are not provided with wxWindows, but that are probably
designed according to a dynamic lang's requirements. so it seems like a good
idea

(note that above two items are independent of whether Cable will be used or
not)

3.)     solving the bug as the app exits, encapsulated by:

require 'wx'
include Wx

app = WxRbApp.new
frame = WxFrame.new(nil, -1, "test frame")
frame.Show
app.MainLoop
#crash!

it seems that ruby's garbage collector doesn't play nice with wxWindows (add
"frame = nil", "GC.start" and "frame.Destroy" at appropiate places). well it
is not really very clear

4.)     a new little event error, demonstrated by a new ported example app
(attached)
        -draw a bit
        -move the window outside the screen to activate redraw, causing OnPaint 
to
be called ad infinitum.
        whoops, watch that cpu meter go !

======================

<phew> i hope this project will benefit from this input, if it indeed
continues on the SWIG path.

regards
Peter

PS, i wanted to add it on the wiki, but couldn't find an appropriate spot.
not well versed in wiki lore, i am

doodle.rb
Description: Binary data