wxruby development - Mar 2007 - Patch to 0.0.39

Hi

I''m developing software using wxruby2. At first I tried to use wxruby
0.6 but I couldn''t live without some of those new funky features :)
So, instead of writing my own code, I got a bit sidetracked and wrote
http://rubyforge.org/tracker/index.php?func=detail&aid=9297&group_id=35&atid=220

instead.
Seeing as this is my first foray in to the innards of wxruby2, I eagerly
await comments from the more seasoned wxrubyists.

A.K.

Hi Artur

Artur Kuptel wrote:
> So, instead of writing my own code, I got a bit sidetracked and wrote
>
http://rubyforge.org/tracker/index.php?func=detail&aid=9297&group_id=35&atid=220
>   
I haven''t tried to merge it yet, but this looks a very important and 
skilful patch, thanks. It addresses some major things we need to do (eg 
upgrade to 2.8.2) and a lot more.
> Seeing as this is my first foray in to the innards of wxruby2, I eagerly
> await comments from the more seasoned wxrubyists.
>   
I''ll add the cross-platform changes over the weekend and get 2.8.2 
working on OS X. I''m away for a week or so so won''t have
access to a
Win32 dev environment.

A minor comment - I find it easier to deal with smaller patches that 
address a single bug or improvement, where possible. We''re also happy
to
receive patches as attachments on this mailing list which might be more 
convenient than the patch tool if you''re already subscribed.

thanks again
Alex

Artur Kuptel wrote:
> Seeing as this is my first foray in to the innards of wxruby2, I eagerly
> await comments from the more seasoned wxrubyists.
I''ve created a branch for moving to Wx 2.8.2. Applied your changes
which
worked very well, with a few changes and additions to fix some OS X 
problems. We''ve now got a working wxruby2 on 2.8 - excellent - thanks 
again for the patch.

I don''t plan for this to be a long-lived branch as I don''t
think we have
the resources to support both 2.6 and 2.8 at the same time. There''s two
issues I''d like to fix before merging this onto trunk.

First, the 2.6 way of doing InitializeStockObjects causes infinite 
recursion when the library loads on OS X, so I''ve disabled it for now -
this means Wx::RED etc are not available. Wx has changed this between 
versions - this thread (esp Robin Dunn''s reply) should be useful:

http://groups.google.com/group/comp.soft-sys.wxwindows/browse_thread/thread/e675afd9aea1b9dc/243eabd232ad94bb?lnk=gst&rnum=1

Second, I''m getting segfaults on normal exit - seems maybe a
double-free
in gc_call_finaliser_on_exit.

Also need at some point to go through and add new methods to the header 
files.

Can I ask how general stability is at the moment on Windows - have we 
fixed the frequent crashes?

cheers
alex

Alex Fenton wrote:
> I''ve created a branch for moving to Wx 2.8.2. Applied your changes
which
> worked very well, with a few changes and additions to fix some OS X 
> problems. We''ve now got a working wxruby2 on 2.8 - excellent -
thanks
> again for the patch.
>
Thank you, and I hope my next one will be more
manageable.
> [...]
>
> Second, I''m getting segfaults on normal exit - seems maybe a
double-free
> in gc_call_finaliser_on_exit.
>
This seems to be a problem with free_wxRubyApp checking GcIsDeleted 
without GcMarkDeleted
in SwigDirector_App (swig objecttracking vs. custom tracking wxruby2 uses
?)
> Also need at some point to go through and add new methods to the header 
> files.
>
> Can I ask how general stability is at the moment on Windows - have we 
> fixed the frequent crashes?
I''ll have to check later, only thing I''m testing right now is
my main
project :)

And a question, when i do get_event_objet, on an event i''m getting a 
proper class instance,
but when i try to overload filter_event() in my App class, i''m getting
a
plain wxEvent instead
of proper wx*Event subclass, is there a simple way to fix it (my work 
around with exposing
get_ruby_object to the ruby code and doing ''proper_event = 
get_ruby_object(ev)'' doesn''t look
right.
A.K.

Artur Kuptel wrote:
> This seems to be a problem with free_wxRubyApp checking GcIsDeleted 
> without GcMarkDeleted
> in SwigDirector_App (swig objecttracking vs. custom tracking wxruby2 uses
?)
>   
An underlying question is whether the custom wxruby2 tracking is needed 
now. It dates back to before ruby object tracking was available in SWIG 
and uses a similar approach, so there is duplication.

I''ve not tried to pick it apart for the simple reason of not wanting to
stir up problems. However in the longer run, as Kevin''s pointed out, 
it''s highly desirable that we reduce and remove our post-processing of 
SWIG output wherever possible, and use SWIG''s features
instead.
> And a question, when i do get_event_objet, on an event i''m getting
a
> proper class instance,
> but when i try to overload filter_event() in my App class, i''m
getting a
> plain wxEvent instead
> of proper wx*Event subclass, is there a simple way to fix it (my work 
> around with exposing
> get_ruby_object to the ruby code and doing ''proper_event = 
> get_ruby_object(ev)'' doesn''t look
> right
>   
get_ruby_object (in Window.i) is pretty much the canonical way to turn a 
Wx object of unknown C++ class into a Ruby object of the right specific 
class by using Wx''s ClassInfo facilities. What''s probably
needed is to
move get_ruby_object function definition into a shared file in 
swig/shared, then include it as needed.

In the case of FilterEvent, it would likely be easiest to add a 
director-type C++ method to wxRubyApp class (in App.i) that converts the 
Event object into a correct Ruby object and then uses rb_funcall to run 
the method in your ruby app subclass, then converts the result back to 
pass to the C++ API.

Sorry if this is all obvious to you... seems you have a v good knowledge 
of SWIG already.

cheers
alex

I''ve added ''virtual bool SetTransparent(wxByte
alpha)'' method to
wxWindow.h.
Now when doing
a = CustomDialog.new()
a.set_transparent(127)

the call is directed to wxWindow''s implementation which is not working.
I think problem lies in _wrap_wxWindow_SetTransparent wrapper:

  upcall = (director && (director->swig_get_self() == self));
  try {
    if (upcall) {
      result = (bool)(arg1)->wxWindow::SetTransparent(arg2);
    } else {
      result = (bool)(arg1)->SetTransparent(arg2);
    }

upcall is true so instead of calling SetTransparent method overloaded by 
TopLevelWindowMSW, base version gets called.
real class hierarchy:

wxWindow : first definition of SetTransparent
  wxTopLevelWindowBase
    wxTopLevelWindowMSW   : invisible to swig (SetTransparent is 
overloaded here)
      wxTopLevelWindow : second definition of SetTransparent will call 
proper wxTopLevelWindowMSW''s version
        wxDialogBase
           wxDialog
             wxDialog_Director
------
               CustomDialog

calling wxWindow::SetTransparent would work ok in non-virtual case.
But when we''re dealing with virtual methods this fails.
I''ve come up with a clunky workaround -> adding another definition
of
SetTransparent method in
wxTopLevelWindow.h but maybe there is more elegant way to do it ?

A.K.

Artur Kuptel wrote:
> I''ve added ''virtual bool SetTransparent(wxByte
alpha)'' method to
> wxWindow.h.
>   
Thanks for looking into this.
> Now when doing
> a = CustomDialog.new()
> a.set_transparent(127)
>
> the call is directed to wxWindow''s implementation which is not
working.
>   
<snip>
> calling wxWindow::SetTransparent would work ok in non-virtual case.
> But when we''re dealing with virtual methods this fails.
> I''ve come up with a clunky workaround -> adding another
definition of
> SetTransparent method in
> wxTopLevelWindow.h but maybe there is more elegant way to do it ?
>   
Not that I can think of - a more ''correct'' solution would
probably
involve a lot more coding in the .i file which we want to avoid when 
possible. I''d be inclined to declare it in wxTopLevelWindow.h with an 
explanatory comment that it''s not from the API but needed to have the 
right method called from ruby.

cheers
alex