wxruby development - Jan 2008 - wxSockets

Hello guys,

Alright Alex.....  I need a few tips on where to start.  I know that
I''m
going to need to rewrite the wxSocket header files, in order to incorperate
them into wxRuby.  But some advice on stuff such as
wxSocketClient::new/connect, where it takes a wxIPAddress, and so forth.  I
know they are pretty friviolous structures for holding information about
Addresses in which to make connections to, so I figure the best route would
be to utilize Arrays or strings instead of relying on this class.  But where
do I start as far as that is concerned?

I also know that there are no "callbacks" in the way that wxWidgets
utilizes
them, within wxRuby, so I know I''ll have to remove certian functions
that
relay back to these methods, and implement them a different way.  But when I
try to do something like %ignore wxSocketBase::callback() and so forth, Swig
still tries to wrap them, and they faulter when compiling.

Any suggestions you guys can advise me of on getting some of these
straighten out, would be much appreciated.  Maybe a "Primer" on adding
classes to the Library would be something good to write up, and also post to
the Wiki for inclusion as well, so that we can get others to help add
classes to the library.  I think the current one we have, is pretty out
dated, considering all the new memory sweep, and such functions we now have,
compared to when that was written.  If I can get an Idea of what needs to be
done, when wrapping a class, I''ll more then happily add the tutorial to
the
Wiki.

TTFN,

Mario Steele

-- 
Mario Steele
http://www.trilake.net
http://www.ruby-im.net
http://rubyforge.org/projects/wxruby/
http://rubyforge.org/projects/wxride/
http://rubyforge.org/projects/vwmc/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/wxruby-development/attachments/20080116/bb0f179d/attachment.html

Hi Mario

To take your last point first: I think there are so few classes left 
needing adding that it''s not worth expanding the wiki page on this.
Most
of the stubborn ones will need a custom solution; if I knew the answers 
I would have added the class anyway. There''s a fair amount of 
explanatory comments on the features we''ve added in the last 18 months 
in the SWIG files.

What''s definitely needed is improved documentation for SWIG. The SWIG 
doc examples are simple and fine enough for a single class that wraps a 
couple of C functions in a ruby object. But for a complex C++ wrapping 
like wxWidgets there''s nowhere that explains the range of tools 
available (eg %extend, typemaps, typedefs, directors) and how to choose 
which strategy to use. I''ve been working on wxRuby2 for a couple of 
years and I still discover new things about SWIG.

Broadly speaking:
- %ignore the method and use %extend to deal with single problem 
methods. It''s easier to see what''s going on with %extend than
with typemaps
- use typemaps to deal with problems and conversions that apply to 
several methods (eg IPAddress)
- if your class needs directors (if C++ code should be able to call into 
ruby code and back) you''ll really need to use typemaps
- you may need to create private helper functions within particular .i 
classes
- make as much use as possible of shared/.i files rather than editing 
typemap.i or typedef.i, unless there''s something globally wrong
- always be alert to the possibility that it might be easier to fix 
something in ruby code in lib/wx/classes - it means less code and less 
tedious recompilation

Mario Steele wrote:
> Alright Alex.....  I need a few tips on where to start.  I know that 
> I''m going to need to rewrite the wxSocket header files, in order
to
> incorperate them into wxRuby.
Firstly, *don''t* do this unless the header files are actually *wrong* 
when compared to include/wx/xxx.h. But it looks like some of the socket 
ones might be ...

The header files should be an accurate description of the real wxWidgets 
API - i.e., the class''s public methods (don''t include
protected/private
methods, members, Wx Macros like IMPLEMENT_XXX_CLASS). The class''s .i 
file, or a shared .i file is the place to solve wxRuby problems, not the 
.h file. The only exception is cross-platform variation in the 
inheritance chain (eg wxTreeCtrl).

Some judgement is needed about which methods should be virtual in the 
header. Typically, many methods in the core wx declaration will be 
virtual because they are implemented in a platform-specific C++ class. 
But these methods shouldn''t be virtual from wxRuby''s point of
view.
However, any method noted "virtual" in the wxWidget documentation
should
definitely be declared virtual. A good rule of thumb is to ask yourself 
whether there''d ever be a useful way that ruby code could re-implement 
the method in a different way.
> But some advice on stuff such as wxSocketClient::new/connect, where it 
> takes a wxIPAddress, and so forth.  I know they are pretty friviolous 
> structures for holding information about Addresses in which to make 
> connections to, so I figure the best route would be to utilize Arrays 
> or strings instead of relying on this class.  But where do I start as 
> far as that is concerned?
Yes, it''s definitely good not to wrap trivial classes like wxIPAddress 
or wxURL as their own ruby classes. The way to deal with them is with 
typemaps. Good examples might be the typemaps for DataFormat and 
TreeItemId (in swig/shared), which allow a DataFormat to be specified as 
an integer constant (eg Wx::DF_BITMAP) or as a string.

You''ll need at least an "in" and and "out" typemap,
and possibly
"directorin" and "directorout" typemaps if the particular
type might be
passed from C++ to ruby in a director method and then back out to 
wxWidgets. "in" and "directorout" are usually similar as
they are
Ruby->C++ conversions; "out" and "directorin" are
C++->Ruby conversions.
> I also know that there are no "callbacks" in the way that
wxWidgets
> utilizes them, within wxRuby, so I know I''ll have to remove
certian
> functions that relay back to these methods, and implement them a 
> different way. 
"callbacks" in C++ usually map to ruby blocks - they are similar in 
concept. I couldn''t find the callbacks you''re referring to so
it''s
difficult to say how to tackle them. The easier way, if the callback 
block can be called once and then thrown away is to create a linking 
function that just calls rb_yield. See ListCtrl.i for an example in 
sort_items.

The more difficult way is if the block may be called at an arbitrary 
time later. This is the case with event handlers. What EvtHandler.i does 
is convert the passed block to a ruby object (by calling zero-args 
Proc.new, in C) then save that VALUE inside a Callback object that C++ 
will run and hence call the block when the event happens.

Easiest is to avoid callbacks altogether and see if that functionality 
can be done within existing mechanisms (such as event handling or 
directors - where the ruby subclass is expected to provide a particular 
method which is called from c++ when needed).
> But when I try to do something like %ignore wxSocketBase::callback() 
> and so forth, Swig still tries to wrap them, and they faulter when 
> compiling.
I can''t see this method in the current wxWidgets documentation. Check 
our wxRuby headers against the current 2.8 headers and see if it''s
still
there.

hope this is useful
alex