Hi Everyone,
Over the past couple of weeks wxruby-swig has made a lot of progress.
Over 100 classes have been added with attempts to mimic the existing
wxruby interfaces. While still not as stable as wxruby, stability has
increased dramatically. Finally, it has been built on Linux, Mac, and MSVC.
This email is an invitation to try out wxruby-swig for yourself. The
source code is in CVS and downloadable from rubyforge. Those of you
doing it from the command line would do
cvs -d:pserver:anonymous@rubyforge.org:/var/cvs/wxruby login
cvs -z3 -d:pserver:anonymous@rubyforge.org:/var/cvs/wxruby co
wxruby-swig
Inside the src directory is the ever-popular extconf.rb. It requires
ruby 1.8 and has been tested on MSVC, Linux, and Mac OS X. wxruby-swig
currently creates a library named ''wx'', so you can try it by
replacing
by replacing the
require ''wxruby''
with
require ''wx''
I''m very interested in hearing what works or what breaks in existing
applications. We''ve been testing with the existing samples, but I know
those of you out there have a lot more abusive tests!
For people interested in assisting with wxruby-swig development, there
is a Wiki page that describes the process at:
http://wxruby.rubyforge.org/wiki/wiki.pl?How_To_Add_A_New_Class_To_Wxruby-Swig
This goes through setting up the build environment and a number of
pitfalls. I''d like to hear about what works and what does not.
I appreciate any time you can put into this. Any contribution only makes
wxruby that much better.
Nick
Does it work with wx 2.4.x and 2.5.x or just 2.4.x. thanks Sean Long Nick wrote:> > Hi Everyone, > > Over the past couple of weeks wxruby-swig has made a lot of progress. > Over 100 classes have been added with attempts to mimic the existing > wxruby interfaces. While still not as stable as wxruby, stability has > increased dramatically. Finally, it has been built on Linux, Mac, and MSVC. > > This email is an invitation to try out wxruby-swig for yourself. The > source code is in CVS and downloadable from rubyforge. Those of you > doing it from the command line would do > > cvs -d:pserver:anonymous@rubyforge.org:/var/cvs/wxruby login > > cvs -z3 -d:pserver:anonymous@rubyforge.org:/var/cvs/wxruby co > wxruby-swig > > Inside the src directory is the ever-popular extconf.rb. It requires > ruby 1.8 and has been tested on MSVC, Linux, and Mac OS X. wxruby-swig > currently creates a library named ''wx'', so you can try it by replacing > by replacing the > > require ''wxruby'' > > with > require ''wx'' > > I''m very interested in hearing what works or what breaks in existing > applications. We''ve been testing with the existing samples, but I know > those of you out there have a lot more abusive tests! > > For people interested in assisting with wxruby-swig development, there > is a Wiki page that describes the process at: > > > http://wxruby.rubyforge.org/wiki/wiki.pl?How_To_Add_A_New_Class_To_Wxruby-Swig > > > This goes through setting up the build environment and a number of > pitfalls. I''d like to hear about what works and what does not. > > I appreciate any time you can put into this. Any contribution only makes > wxruby that much better. > > Nick > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users >
> Does it work with wx 2.4.x and 2.5.x or just 2.4.x.Good question. Right now, it''s still 2.4, as 2.5 changes a number of internals and would require a little migration. Nick Sean Long wrote:> Does it work with wx 2.4.x and 2.5.x or just 2.4.x. > > thanks > > Sean Long > > > Nick wrote: > >> >> Hi Everyone, >> >> Over the past couple of weeks wxruby-swig has made a lot of progress. >> Over 100 classes have been added with attempts to mimic the existing >> wxruby interfaces. While still not as stable as wxruby, stability has >> increased dramatically. Finally, it has been built on Linux, Mac, and >> MSVC. >> >> This email is an invitation to try out wxruby-swig for yourself. The >> source code is in CVS and downloadable from rubyforge. Those of you >> doing it from the command line would do >> >> cvs -d:pserver:anonymous@rubyforge.org:/var/cvs/wxruby login >> >> cvs -z3 -d:pserver:anonymous@rubyforge.org:/var/cvs/wxruby co >> wxruby-swig >> >> Inside the src directory is the ever-popular extconf.rb. It requires >> ruby 1.8 and has been tested on MSVC, Linux, and Mac OS X. >> wxruby-swig currently creates a library named ''wx'', so you can try it >> by replacing by replacing the >> >> require ''wxruby'' >> >> with >> require ''wx'' >> >> I''m very interested in hearing what works or what breaks in existing >> applications. We''ve been testing with the existing samples, but I >> know those of you out there have a lot more abusive tests! >> >> For people interested in assisting with wxruby-swig development, >> there is a Wiki page that describes the process at: >> >> >> http://wxruby.rubyforge.org/wiki/wiki.pl?How_To_Add_A_New_Class_To_Wxruby-Swig >> >> >> This goes through setting up the build environment and a number of >> pitfalls. I''d like to hear about what works and what does not. >> >> I appreciate any time you can put into this. Any contribution only >> makes wxruby that much better. >> >> Nick >> _______________________________________________ >> wxruby-users mailing list >> wxruby-users@rubyforge.org >> http://rubyforge.org/mailman/listinfo/wxruby-users >> > > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > >
Nick wrote:> Over the past couple of weeks wxruby-swig has made a lot of progress. > Over 100 classes have been added with attempts to mimic the existing > wxruby interfaces. While still not as stable as wxruby, stability has > increased dramatically. Finally, it has been built on Linux, Mac, and MSVC.Great work, Nick! If you haven''t already, you should probably update the README and tag this version. Is it easy to generate a list of classes that are in wxruby but not yet in wxruby-swig? I know that''s not the whole story, since within each class there may be more (or fewer) unsupported methods. But it would be a nice objective metric. Thanks, Kevin Recovering from YET ANOTHER hurricane. Sigh.
> Is it easy to generate a list of classes that are in wxruby but not > yet in wxruby-swig? I know that''s not the whole story, since within > each class there may be more (or fewer) unsupported methods. But it > would be a nice objective metric.* The following classes are not in wxruby-swig as of yet... Config/ConfigBase DataFormat/DataObject/DataObjectSimple/FileDataObject/FileDropTarget/DropSource/DropTarget/TextDataObject/TextDropTarget HtmlWindow DateTime List/ListEvent/ListItem/ListItemAttr MDIClientWindow MenuItem OwnerDrawn Palette ProgressDialog Region SplitterEvent/SplitterWindow StaticLine StopWatch TextAttr ToolBarToolBase ToolTip TreeCtrl/TreeEvent/TreeItemData URL Validator XmlResource * The following classes aren''t in wxruby-swig, and probably won''t be added because it is easier to use the Ruby equivilants. FileOutputStream/InputStream/OutputStream/StreamBase Protocol Rect SocketBase/SocketClient/SocketEvent/SocketServer Timer - Nick Kevin Smith wrote:> Nick wrote: > >> Over the past couple of weeks wxruby-swig has made a lot of progress. >> Over 100 classes have been added with attempts to mimic the existing >> wxruby interfaces. While still not as stable as wxruby, stability has >> increased dramatically. Finally, it has been built on Linux, Mac, and >> MSVC. > > > Great work, Nick! > > If you haven''t already, you should probably update the README and tag > this version. > > Is it easy to generate a list of classes that are in wxruby but not > yet in wxruby-swig? I know that''s not the whole story, since within > each class there may be more (or fewer) unsupported methods. But it > would be a nice objective metric. > > Thanks, > > Kevin > Recovering from YET ANOTHER hurricane. Sigh. > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > >
I''m curious. Why would I want to use wxruby-swig when it isn''t as stable as wxruby? What are the pros and cons of wxruby-swig compared with wxruby? Thanks David On Wed, 2004-09-29 at 05:35, Nick wrote:> Hi Everyone, > > Over the past couple of weeks wxruby-swig has made a lot of progress. > Over 100 classes have been added with attempts to mimic the existing > wxruby interfaces. While still not as stable as wxruby, stability has > increased dramatically. Finally, it has been built on Linux, Mac, and MSVC. > > This email is an invitation to try out wxruby-swig for yourself. The > source code is in CVS and downloadable from rubyforge. Those of you > doing it from the command line would do > > cvs -d:pserver:anonymous@rubyforge.org:/var/cvs/wxruby login > > cvs -z3 -d:pserver:anonymous@rubyforge.org:/var/cvs/wxruby co > wxruby-swig > > Inside the src directory is the ever-popular extconf.rb. It requires > ruby 1.8 and has been tested on MSVC, Linux, and Mac OS X. wxruby-swig > currently creates a library named ''wx'', so you can try it by replacing > by replacing the > > require ''wxruby'' > > with > > require ''wx'' > > I''m very interested in hearing what works or what breaks in existing > applications. We''ve been testing with the existing samples, but I know > those of you out there have a lot more abusive tests! > > For people interested in assisting with wxruby-swig development, there > is a Wiki page that describes the process at: > > > http://wxruby.rubyforge.org/wiki/wiki.pl?How_To_Add_A_New_Class_To_Wxruby-Swig > > This goes through setting up the build environment and a number of > pitfalls. I''d like to hear about what works and what does not. > > I appreciate any time you can put into this. Any contribution only makes > wxruby that much better. > > Nick > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users-- David Mitchell Software Engineer Telogis NOTICE: This message (including any attachments) contains CONFIDENTIAL INFORMATION intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited.
As wxruby has grown, it''s hit a number of snags
1) Virtual methods need to be written by hand.
2) Currently, Wx objects are never GC''d. However, implementing GC-safe
objects requires custom mark methods, which would require a major
overhaul of the existing system.
3) Non-widget classes do not wrap as easily.
Looking over the work to improve wxruby, Kevin decided that the existing
wrapper system was inadequate. At the same time, SWIG had come a long
way as a wrapping utility for Ruby classes.
wxruby-swig is intended to replace wxruby. It will have a number of new
features
1) Virtual Methods
2) GC''able objects
3) Aliased methods (''pen='' instead of
''set_pen'')
In order to get there, it first needs to be as good as the existing
wxruby. It has come a long way in the past month (If you don''t believe
me, check out http://wxruby.rubyforge.org/statcvs/loc.html - and
remember that wxruby was checked into CVS in mid-july).
So by helping out now, you will get a superior wxruby in the future. The
migration will happen, but with some help, it will happen sooner than later.
Nick
David Mitchell wrote:
>I''m curious. Why would I want to use wxruby-swig when it
isn''t as stable
>as wxruby? What are the pros and cons of wxruby-swig compared with
>wxruby?
>
>Thanks
>
>David
>
>On Wed, 2004-09-29 at 05:35, Nick wrote:
>
>
>>Hi Everyone,
>>
>>Over the past couple of weeks wxruby-swig has made a lot of progress.
>>Over 100 classes have been added with attempts to mimic the existing
>>wxruby interfaces. While still not as stable as wxruby, stability has
>>increased dramatically. Finally, it has been built on Linux, Mac, and
MSVC.
>>
>>This email is an invitation to try out wxruby-swig for yourself. The
>>source code is in CVS and downloadable from rubyforge. Those of you
>>doing it from the command line would do
>>
>> cvs -d:pserver:anonymous@rubyforge.org:/var/cvs/wxruby login
>>
>> cvs -z3 -d:pserver:anonymous@rubyforge.org:/var/cvs/wxruby co
>>wxruby-swig
>>
>>Inside the src directory is the ever-popular extconf.rb. It requires
>>ruby 1.8 and has been tested on MSVC, Linux, and Mac OS X. wxruby-swig
>>currently creates a library named ''wx'', so you can try
it by replacing
>>by replacing the
>>
>> require ''wxruby''
>>
>>with
>>
>> require ''wx''
>>
>>I''m very interested in hearing what works or what breaks in
existing
>>applications. We''ve been testing with the existing samples, but
I know
>>those of you out there have a lot more abusive tests!
>>
>>For people interested in assisting with wxruby-swig development, there
>>is a Wiki page that describes the process at:
>>
>>
>>http://wxruby.rubyforge.org/wiki/wiki.pl?How_To_Add_A_New_Class_To_Wxruby-Swig
>>
>>This goes through setting up the build environment and a number of
>>pitfalls. I''d like to hear about what works and what does not.
>>
>>I appreciate any time you can put into this. Any contribution only makes
>>wxruby that much better.
>>
>>Nick
>>_______________________________________________
>>wxruby-users mailing list
>>wxruby-users@rubyforge.org
>>http://rubyforge.org/mailman/listinfo/wxruby-users
>>
>>
I take it from that then that old-style wxruby is going to be deprecated and development is soon to cease? New feature #3 - Aliased methods sounds really cool, so maybe I''ll try porting my big ol'' wxruby app to the new system. Cheers David On Wed, 2004-09-29 at 14:34, Nick wrote:> As wxruby has grown, it''s hit a number of snags > > 1) Virtual methods need to be written by hand. > 2) Currently, Wx objects are never GC''d. However, implementing GC-safe > objects requires custom mark methods, which would require a major > overhaul of the existing system. > 3) Non-widget classes do not wrap as easily. > > Looking over the work to improve wxruby, Kevin decided that the existing > wrapper system was inadequate. At the same time, SWIG had come a long > way as a wrapping utility for Ruby classes. > > wxruby-swig is intended to replace wxruby. It will have a number of new > features > > 1) Virtual Methods > 2) GC''able objects > 3) Aliased methods (''pen='' instead of ''set_pen'') > > In order to get there, it first needs to be as good as the existing > wxruby. It has come a long way in the past month (If you don''t believe > me, check out http://wxruby.rubyforge.org/statcvs/loc.html - and > remember that wxruby was checked into CVS in mid-july). > > So by helping out now, you will get a superior wxruby in the future. The > migration will happen, but with some help, it will happen sooner than later. > > Nick > > > David Mitchell wrote: > > >I''m curious. Why would I want to use wxruby-swig when it isn''t as stable > >as wxruby? What are the pros and cons of wxruby-swig compared with > >wxruby? > > > >Thanks > > > >David > > > >On Wed, 2004-09-29 at 05:35, Nick wrote: > > > > > >>Hi Everyone, > >> > >>Over the past couple of weeks wxruby-swig has made a lot of progress. > >>Over 100 classes have been added with attempts to mimic the existing > >>wxruby interfaces. While still not as stable as wxruby, stability has > >>increased dramatically. Finally, it has been built on Linux, Mac, and MSVC. > >> > >>This email is an invitation to try out wxruby-swig for yourself. The > >>source code is in CVS and downloadable from rubyforge. Those of you > >>doing it from the command line would do > >> > >> cvs -d:pserver:anonymous@rubyforge.org:/var/cvs/wxruby login > >> > >> cvs -z3 -d:pserver:anonymous@rubyforge.org:/var/cvs/wxruby co > >>wxruby-swig > >> > >>Inside the src directory is the ever-popular extconf.rb. It requires > >>ruby 1.8 and has been tested on MSVC, Linux, and Mac OS X. wxruby-swig > >>currently creates a library named ''wx'', so you can try it by replacing > >>by replacing the > >> > >> require ''wxruby'' > >> > >>with > >> > >> require ''wx'' > >> > >>I''m very interested in hearing what works or what breaks in existing > >>applications. We''ve been testing with the existing samples, but I know > >>those of you out there have a lot more abusive tests! > >> > >>For people interested in assisting with wxruby-swig development, there > >>is a Wiki page that describes the process at: > >> > >> > >>http://wxruby.rubyforge.org/wiki/wiki.pl?How_To_Add_A_New_Class_To_Wxruby-Swig > >> > >>This goes through setting up the build environment and a number of > >>pitfalls. I''d like to hear about what works and what does not. > >> > >>I appreciate any time you can put into this. Any contribution only makes > >>wxruby that much better. > >> > >>Nick > >>_______________________________________________ > >>wxruby-users mailing list > >>wxruby-users@rubyforge.org > >>http://rubyforge.org/mailman/listinfo/wxruby-users > >> > >> > > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users-- David Mitchell Software Engineer Telogis NOTICE: This message (including any attachments) contains CONFIDENTIAL INFORMATION intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited.
> (If you don''t believe me, check out > http://wxruby.rubyforge.org/statcvs/loc.html - and remember that > wxruby was checked into CVS in mid-july).That should read "and remember that wxruby-swig was initially checked into CVS in mid-july. Nick Nick wrote:> > As wxruby has grown, it''s hit a number of snags > > 1) Virtual methods need to be written by hand. > 2) Currently, Wx objects are never GC''d. However, implementing GC-safe > objects requires custom mark methods, which would require a major > overhaul of the existing system. > 3) Non-widget classes do not wrap as easily. > > Looking over the work to improve wxruby, Kevin decided that the > existing wrapper system was inadequate. At the same time, SWIG had > come a long way as a wrapping utility for Ruby classes. > > wxruby-swig is intended to replace wxruby. It will have a number of > new features > > 1) Virtual Methods > 2) GC''able objects > 3) Aliased methods (''pen='' instead of ''set_pen'') > > In order to get there, it first needs to be as good as the existing > wxruby. It has come a long way in the past month (If you don''t believe > me, check out http://wxruby.rubyforge.org/statcvs/loc.html - and > remember that wxruby was checked into CVS in mid-july). > > So by helping out now, you will get a superior wxruby in the future. > The migration will happen, but with some help, it will happen sooner > than later. > > Nick > > > David Mitchell wrote: > >> I''m curious. Why would I want to use wxruby-swig when it isn''t as stable >> as wxruby? What are the pros and cons of wxruby-swig compared with >> wxruby? >> >> Thanks >> >> David >> >> On Wed, 2004-09-29 at 05:35, Nick wrote: >> >> >>> Hi Everyone, >>> >>> Over the past couple of weeks wxruby-swig has made a lot of >>> progress. Over 100 classes have been added with attempts to mimic >>> the existing wxruby interfaces. While still not as stable as wxruby, >>> stability has increased dramatically. Finally, it has been built on >>> Linux, Mac, and MSVC. >>> >>> This email is an invitation to try out wxruby-swig for yourself. The >>> source code is in CVS and downloadable from rubyforge. Those of you >>> doing it from the command line would do >>> >>> cvs -d:pserver:anonymous@rubyforge.org:/var/cvs/wxruby login >>> >>> cvs -z3 -d:pserver:anonymous@rubyforge.org:/var/cvs/wxruby co >>> wxruby-swig >>> >>> Inside the src directory is the ever-popular extconf.rb. It requires >>> ruby 1.8 and has been tested on MSVC, Linux, and Mac OS X. >>> wxruby-swig currently creates a library named ''wx'', so you can try >>> it by replacing by replacing the >>> >>> require ''wxruby'' >>> >>> with >>> require ''wx'' >>> >>> I''m very interested in hearing what works or what breaks in existing >>> applications. We''ve been testing with the existing samples, but I >>> know those of you out there have a lot more abusive tests! >>> >>> For people interested in assisting with wxruby-swig development, >>> there is a Wiki page that describes the process at: >>> >>> >>> http://wxruby.rubyforge.org/wiki/wiki.pl?How_To_Add_A_New_Class_To_Wxruby-Swig >>> >>> >>> This goes through setting up the build environment and a number of >>> pitfalls. I''d like to hear about what works and what does not. >>> >>> I appreciate any time you can put into this. Any contribution only >>> makes wxruby that much better. >>> >>> Nick >>> _______________________________________________ >>> wxruby-users mailing list >>> wxruby-users@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wxruby-users >>> >> > > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > >
>I take it from that then that old-style wxruby is going to be deprecated >and development is soon to cease? > > >Thats the intention.>New feature #3 - Aliased methods sounds really cool, so maybe I''ll try >porting my big ol'' wxruby app to the new system. >FYI, those aren''t in yet, but are fairly straightforward to add. Nick David Mitchell wrote:>I take it from that then that old-style wxruby is going to be deprecated >and development is soon to cease? > >New feature #3 - Aliased methods sounds really cool, so maybe I''ll try >porting my big ol'' wxruby app to the new system. > >Cheers > >David > >On Wed, 2004-09-29 at 14:34, Nick wrote: > > >>As wxruby has grown, it''s hit a number of snags >> >>1) Virtual methods need to be written by hand. >>2) Currently, Wx objects are never GC''d. However, implementing GC-safe >>objects requires custom mark methods, which would require a major >>overhaul of the existing system. >>3) Non-widget classes do not wrap as easily. >> >>Looking over the work to improve wxruby, Kevin decided that the existing >>wrapper system was inadequate. At the same time, SWIG had come a long >>way as a wrapping utility for Ruby classes. >> >>wxruby-swig is intended to replace wxruby. It will have a number of new >>features >> >>1) Virtual Methods >>2) GC''able objects >>3) Aliased methods (''pen='' instead of ''set_pen'') >> >>In order to get there, it first needs to be as good as the existing >>wxruby. It has come a long way in the past month (If you don''t believe >>me, check out http://wxruby.rubyforge.org/statcvs/loc.html - and >>remember that wxruby was checked into CVS in mid-july). >> >>So by helping out now, you will get a superior wxruby in the future. The >>migration will happen, but with some help, it will happen sooner than later. >> >>Nick >> >> >>David Mitchell wrote: >> >> >> >>>I''m curious. Why would I want to use wxruby-swig when it isn''t as stable >>>as wxruby? What are the pros and cons of wxruby-swig compared with >>>wxruby? >>> >>>Thanks >>> >>>David >>> >>>On Wed, 2004-09-29 at 05:35, Nick wrote: >>> >>> >>> >>> >>>>Hi Everyone, >>>> >>>>Over the past couple of weeks wxruby-swig has made a lot of progress. >>>>Over 100 classes have been added with attempts to mimic the existing >>>>wxruby interfaces. While still not as stable as wxruby, stability has >>>>increased dramatically. Finally, it has been built on Linux, Mac, and MSVC. >>>> >>>>This email is an invitation to try out wxruby-swig for yourself. The >>>>source code is in CVS and downloadable from rubyforge. Those of you >>>>doing it from the command line would do >>>> >>>> cvs -d:pserver:anonymous@rubyforge.org:/var/cvs/wxruby login >>>> >>>> cvs -z3 -d:pserver:anonymous@rubyforge.org:/var/cvs/wxruby co >>>>wxruby-swig >>>> >>>>Inside the src directory is the ever-popular extconf.rb. It requires >>>>ruby 1.8 and has been tested on MSVC, Linux, and Mac OS X. wxruby-swig >>>>currently creates a library named ''wx'', so you can try it by replacing >>>>by replacing the >>>> >>>> require ''wxruby'' >>>> >>>>with >>>> >>>> require ''wx'' >>>> >>>>I''m very interested in hearing what works or what breaks in existing >>>>applications. We''ve been testing with the existing samples, but I know >>>>those of you out there have a lot more abusive tests! >>>> >>>>For people interested in assisting with wxruby-swig development, there >>>>is a Wiki page that describes the process at: >>>> >>>> >>>>http://wxruby.rubyforge.org/wiki/wiki.pl?How_To_Add_A_New_Class_To_Wxruby-Swig >>>> >>>>This goes through setting up the build environment and a number of >>>>pitfalls. I''d like to hear about what works and what does not. >>>> >>>>I appreciate any time you can put into this. Any contribution only makes >>>>wxruby that much better. >>>> >>>>Nick >>>>_______________________________________________ >>>>wxruby-users mailing list >>>>wxruby-users@rubyforge.org >>>>http://rubyforge.org/mailman/listinfo/wxruby-users >>>> >>>> >>>> >>>> >>_______________________________________________ >>wxruby-users mailing list >>wxruby-users@rubyforge.org >>http://rubyforge.org/mailman/listinfo/wxruby-users >> >>