Sorry I sent the mail only to Hans, resubmitting to the list
-------- Message original --------
Sujet: Re: [wxruby-development] 2013 the year of wxRuby3
Date : Fri, 04 Jan 2013 22:55:02 +0100
De : Pascal Hurni
Pour : Hans Mackowiak
Hallo Hans!
Thanx for sharing your work, I put some inline comments in your message
Le 04.01.13 06:00, Hans Mackowiak a ?crit :> let me point you to something i did: https://github.com/Hanmac/rwx
>
> its an "rewrite" of wxRuby against wxWidgets2.9.* but with my own
hands.
>
> its may not be what you want becausethe binding is still monolithic, but
> it also comines features into the "main" functions ... so you
could use
> WX::Frame.new for loading xrc files too.
With wxWidgets 3.0 coming, XRC loading will also be included (I already
done that with custom ruby code on top of wxRuby2)
>
> there are other BIG differences, like
> - the IDs are not ugly constants anymore, they are automatic wrapped
> into beautyful symbols and user setted symbols are automatic wrapped
> into IDs
Yeah, I also target such things. Note that with more wxSugar like code,
we can get rid of ID completely.
> - the same is for ArtProvider icons, and enum values
> - wxWindow objects are rememberd so it does not create new ruby
> objects everytime you ask for it (like when you do get_child(name)) so
> you could add ruby instance variables to the objects
This should be investigated in wxRuby3, thanx for pointing it out.
> - wxVariant is automatic converted into the right ruby object and reverse
> - rwx does not use the EVTTABLE from wx2.8 but the newer Connect and
> Bind functions, the proc objects are used for bind are also protected
> like the window objects from the Rubys GC
Event binding will be completely reworked (getting rid of all the evt_*
methods), so we should come close to what you''ve done.
> - wxEvents are automatic mapped into the right ruby Class if defined
> (so wxKexEvent is WX::Event::Key but wxPaintEvent is generic WX::Event)
I also started working on that in wxRuby3.
> - eventTypes are like enums automatic turned into symbols too
> - all child classes of wxWindow support an opts Hash as parameter (and
> use then in the right order when doing the 2-step creation of the Objects)
This should be addressed by the second layer (currently known as wxSugar ;-)
> - generic classes like wxSize and wxColour automatic wrap from similar
> objects, so [10,20] can be used as size parameter too, while an ruby
> Struct with red,green,blue methods can be converted into an wxColour object
We want features like that too, by rewriting better typemaps (swig).
>
>
> BIGGEST Diff: i dont use swig because it is the root of evil and even
> its own creator does not like it
>
Well, I understand you on that. wxRuby upto 0.6 was hand written and was
really good. Then the following release was rewritten to use SWIG. The
first time I saw SWIG, I also disliked it, thought it was too bloated.
This was because I didn''t knew it very well (it''s still the
case).
The big point on using SWIG is really a faster development time for big
projects like wxWidgets. And much more important, faster upgrade when
the original projects evolves.
For these reasons, I think keeping SWIG is a good way to go. With the
goals stated on the wxRuby wiki, I think we can bring a robust way to
build wxRuby.
wxRuby3 will also be the first to take advantage of the wxWidgets
interface file, core members already accepted patches of my own to
support this (thanx to them).
>
> PS:
> your line changed a bit into
> WX::App.run { WX::Frame.new(nil, title: "Yop").show }
> would work on my system (this is only not commited yet)
>
> Best Regards
>
Once again, thanx for sharing this, we certainly will use some of your
ideas/implementation in wxRuby3.
Best Regards,
Pascal