wxruby users - Jul 2005 - wxruby (was: Some questions)

Roy Sutton wrote (on the FreeRIDE list):
> Really?  That''s interesting.  I haven''t checked out
WxRuby but I would
> be much happier using something that interfaces to the underlying 
> operating system''s widgets.  
As a member (and former leader) of the wxruby team, I thought I would 
share the state of the wxruby world.

The current release is 0.6, and it has pretty good widget support, but 
has a few stability problems, and some pretty bad memory leaks. We are 
rewriting wxruby from scratch using swig, which has some significant 
benefits:
- Fixes the leaks and other memory problems
- Provides much better support for subclassing wx classes
- Makes it easier for non-coders to add support for more classes

Unfortunately, none of us on the team have had time to bring wxruby-swig 
up to the level where it supports all the classes that are in wxruby 
0.6. So wxruby-swig has not yet been released. And although we still 
believe in wxruby, none of us are actively developing it right now. A 
motivated person could rapidly make a lot of progress, even if they 
don''t know C++. I can offer quick and deep technical support to anyone 
interested in working on wxruby-swig.

Oh...one other issue. We are a bit caught between supporting the 
upstream wx 2.4 library and the recently-released 2.6 version. So far, 
we have focused on 2.4, but as time goes by, more and more people would 
rather have a version that works with 2.6.

Kevin

Kevin,

You are in luck!

Over the last week or so I have been hacking on wxruby swig version
from CVS. I have made it compile and run on wxWidgets 2.6.1 on Mac OS
X and Windows XP using VS .Net.

I have added support for:
XMLResource
ProgressDialog
Validator
Icon
FindReplaceDialog

I have tested the following sample projects successfully:
caret
dialogs
etc
images
minimal
xrc

I am working on getting the controls sample working

After working on this for awhile I think the project should only focus
on wxWidgets 2.6.1 and beyond. If anyone wants to use wxWidgets 2.4.x
they can use the old wxRuby 0.6 path.

I also think we should look into getting rid of the
wxclasses-2.4.2.xml for class and method definitions and do it all
with *.i. With the *.i files we have more control over conditional
compilation for the different platforms and libraries that people may
want to leave out when compiling wxruby. Not to mention it really
slows down the development process having to parse the XML files
every-time something is added to extractxml.rb.

Since I can not write back to the CVS repository I am posting my
changes zipped up to:
http://www.hailstonesoftware.com/wxruby/wxruby-swig_07_16_2005.zip
it is 2.71 MB

NOTES:
- I renamed rake.bat in the root directory to rake2.bat because it
messed up rake usage on Windows for me.
- In extconf.rb ENV[''WXWIN''] did not work for me so I have
$WXDIR hard
coded for the windows version.
- Also note I have not used SWIG before so excuse any stupid looking mistakes :)

Used:
SWIG 1.3.24
Rake 0.5.3
Ruby 1.8.2
wxWidgets 2.6.1
Windows XP Pro Service pack 2
Mac OS X 10.4.2

Sean Long


On 7/16/05, Kevin Smith <wxruby@qualitycode.com>
wrote:
> Roy Sutton wrote (on the FreeRIDE list):
> > Really?  That''s interesting.  I haven''t checked out
WxRuby but I would
> > be much happier using something that interfaces to the underlying
> > operating system''s widgets.
> 
> As a member (and former leader) of the wxruby team, I thought I would
> share the state of the wxruby world.
> 
> The current release is 0.6, and it has pretty good widget support, but
> has a few stability problems, and some pretty bad memory leaks. We are
> rewriting wxruby from scratch using swig, which has some significant
> benefits:
> - Fixes the leaks and other memory problems
> - Provides much better support for subclassing wx classes
> - Makes it easier for non-coders to add support for more classes
> 
> Unfortunately, none of us on the team have had time to bring wxruby-swig
> up to the level where it supports all the classes that are in wxruby
> 0.6. So wxruby-swig has not yet been released. And although we still
> believe in wxruby, none of us are actively developing it right now. A
> motivated person could rapidly make a lot of progress, even if they
> don''t know C++. I can offer quick and deep technical support to
anyone
> interested in working on wxruby-swig.
> 
> Oh...one other issue. We are a bit caught between supporting the
> upstream wx 2.4 library and the recently-released 2.6 version. So far,
> we have focused on 2.4, but as time goes by, more and more people would
> rather have a version that works with 2.6.
> 
> Kevin
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>

Roy Sutton wrote (on the FreeRIDE list):
>  And although we still believe in wxruby, none of us are actively
developing
> it right now.
hmm, well i guess that pretty  much makes up my mind :/


-- 
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org

Tony,

See my post under ''wxruby (was: [FR-devel] Some questions)'',
the core
group may not be actively developing it right now but others may be,
myself included.

Sean Long

On 7/17/05, tony summerfelt <snowzone5@hotmail.com>
wrote:
> Roy Sutton wrote (on the FreeRIDE list):
> 
> >  And although we still believe in wxruby, none of us are actively
developing
> > it right now.
> 
> hmm, well i guess that pretty  much makes up my mind :/
> 
> 
> --
> http://home.cogeco.ca/~tsummerfelt1
> telnet://ventedspleen.dyndns.org
> 
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>

This is great. I really want to leverage your momentum, so I''m setting 
aside some other important work to try to incorporate your changes into 
the main wxruby-swig codebase.

My approach is to pick one change at a time from your zipped source 
tree, apply it to a copy of the "official" tree, and check it into
CVS.
It''s a bit tedious, but is safe, and helps me understand what
you''ve done.

I''m not sure I''m willing to target only 2.6 yet, since my own
system
(Ubuntu) only has 2.5 on it. Perhaps targeting 2.5+ for now would be a 
reasonable compromise.

I agree that it is time to drop the .xml file. It has served its purpose 
as a quick way to build a set of clean wx .h files. However, since it is 
not very accurate, and especially since it is not being updated 
upstream, we should stop using it.

However, I do want to retain the split between our own .i files and the 
generic .h files.

I''ll let you know as I make progress integrating your changes.

Thanks!

Kevin


Sean Long wrote:
> Kevin,
> 
> You are in luck!
> 
> Over the last week or so I have been hacking on wxruby swig version
> from CVS. I have made it compile and run on wxWidgets 2.6.1 on Mac OS
> X and Windows XP using VS .Net.
> 
> I have added support for:
> XMLResource
> ProgressDialog
> Validator
> Icon
> FindReplaceDialog
> 
> I have tested the following sample projects successfully:
> caret
> dialogs
> etc
> images
> minimal
> xrc
> 
> I am working on getting the controls sample working
> 
> After working on this for awhile I think the project should only focus
> on wxWidgets 2.6.1 and beyond. If anyone wants to use wxWidgets 2.4.x
> they can use the old wxRuby 0.6 path.
> 
> I also think we should look into getting rid of the
> wxclasses-2.4.2.xml for class and method definitions and do it all
> with *.i. With the *.i files we have more control over conditional
> compilation for the different platforms and libraries that people may
> want to leave out when compiling wxruby. Not to mention it really
> slows down the development process having to parse the XML files
> every-time something is added to extractxml.rb.
> 
> Since I can not write back to the CVS repository I am posting my
> changes zipped up to:
> http://www.hailstonesoftware.com/wxruby/wxruby-swig_07_16_2005.zip
> it is 2.71 MB
> 
> NOTES:
> - I renamed rake.bat in the root directory to rake2.bat because it
> messed up rake usage on Windows for me.
> - In extconf.rb ENV[''WXWIN''] did not work for me so I
have $WXDIR hard
> coded for the windows version.
> - Also note I have not used SWIG before so excuse any stupid looking
mistakes :)
> 
> Used:
> SWIG 1.3.24
> Rake 0.5.3
> Ruby 1.8.2
> wxWidgets 2.6.1
> Windows XP Pro Service pack 2
> Mac OS X 10.4.2
> 
> Sean Long
> 
> 
> On 7/16/05, Kevin Smith <wxruby@qualitycode.com> wrote:
> 
>>Roy Sutton wrote (on the FreeRIDE list):
>>
>>>Really?  That''s interesting.  I haven''t checked
out WxRuby but I would
>>>be much happier using something that interfaces to the underlying
>>>operating system''s widgets.
>>
>>As a member (and former leader) of the wxruby team, I thought I would
>>share the state of the wxruby world.
>>
>>The current release is 0.6, and it has pretty good widget support, but
>>has a few stability problems, and some pretty bad memory leaks. We are
>>rewriting wxruby from scratch using swig, which has some significant
>>benefits:
>>- Fixes the leaks and other memory problems
>>- Provides much better support for subclassing wx classes
>>- Makes it easier for non-coders to add support for more classes
>>
>>Unfortunately, none of us on the team have had time to bring wxruby-swig
>>up to the level where it supports all the classes that are in wxruby
>>0.6. So wxruby-swig has not yet been released. And although we still
>>believe in wxruby, none of us are actively developing it right now. A
>>motivated person could rapidly make a lot of progress, even if they
>>don''t know C++. I can offer quick and deep technical support to
anyone
>>interested in working on wxruby-swig.
>>
>>Oh...one other issue. We are a bit caught between supporting the
>>upstream wx 2.4 library and the recently-released 2.6 version. So far,
>>we have focused on 2.4, but as time goes by, more and more people would
>>rather have a version that works with 2.6.
>>
>>Kevin
>>_______________________________________________
>>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

Quick update:

I have checked in most of Sean''s wxruby-swig changes, except for those 
in the swig/ and sample/ directories (which, I realize, are the most 
interesting ones). It still compiles and the minimal sample still runs, 
at least on my Ubuntu Linux box. It would be great if someone could do a 
quick test on Mac and on MS Windows to make sure I didn''t break
anything
big.

Xrc is not part of wx 2.4 (which is what I''m still using right now). So
I made the Xrc stuff optional. If you do a full build with WXRUBY_XRC in 
your environment, you should get Xrc support. Since I don''t have Xrc, I
wasn''t able to test this.

My next step (tomorrow, hopefully) will be to officially remove 
wxclasses-2.4.2.xml and extractxml from the project. After that, I will 
probably bring in the newly added classes, and then try to pull in the 
updates to existing classes. Finally, I''ll bring in the new samples,
and
whatever else I have forgotten.

Somewhere in there, I might take the big plunge to wxWidgets 2.5.3.2, 
and if that works, I would probably want to officially move wxruby-swig 
to wx 2.5+, which seemed to be the consensus direction as of a few 
months ago.

Cheers,

Kevin


Kevin Smith wrote:
> This is great. I really want to leverage your momentum, so I''m
setting
> aside some other important work to try to incorporate your changes into 
> the main wxruby-swig codebase.
> 
> My approach is to pick one change at a time from your zipped source 
> tree, apply it to a copy of the "official" tree, and check it
into CVS.
> It''s a bit tedious, but is safe, and helps me understand what
you''ve done.
> 
> I''m not sure I''m willing to target only 2.6 yet, since my
own system
> (Ubuntu) only has 2.5 on it. Perhaps targeting 2.5+ for now would be a 
> reasonable compromise.
> 
> I agree that it is time to drop the .xml file. It has served its purpose 
> as a quick way to build a set of clean wx .h files. However, since it is 
> not very accurate, and especially since it is not being updated 
> upstream, we should stop using it.
> 
> However, I do want to retain the split between our own .i files and the 
> generic .h files.
> 
> I''ll let you know as I make progress integrating your changes.
> 
> Thanks!
> 
> Kevin
> 
> 
> Sean Long wrote:
> 
>> Kevin,
>>
>> You are in luck!
>>
>> Over the last week or so I have been hacking on wxruby swig version
>> from CVS. I have made it compile and run on wxWidgets 2.6.1 on Mac OS
>> X and Windows XP using VS .Net.
>>
>> I have added support for:
>> XMLResource
>> ProgressDialog
>> Validator
>> Icon
>> FindReplaceDialog
>>
>> I have tested the following sample projects successfully:
>> caret
>> dialogs
>> etc
>> images
>> minimal
>> xrc
>>
>> I am working on getting the controls sample working
>>
>> After working on this for awhile I think the project should only focus
>> on wxWidgets 2.6.1 and beyond. If anyone wants to use wxWidgets 2.4.x
>> they can use the old wxRuby 0.6 path.
>>
>> I also think we should look into getting rid of the
>> wxclasses-2.4.2.xml for class and method definitions and do it all
>> with *.i. With the *.i files we have more control over conditional
>> compilation for the different platforms and libraries that people may
>> want to leave out when compiling wxruby. Not to mention it really
>> slows down the development process having to parse the XML files
>> every-time something is added to extractxml.rb.
>>
>> Since I can not write back to the CVS repository I am posting my
>> changes zipped up to:
>> http://www.hailstonesoftware.com/wxruby/wxruby-swig_07_16_2005.zip
>> it is 2.71 MB
>>
>> NOTES:
>> - I renamed rake.bat in the root directory to rake2.bat because it
>> messed up rake usage on Windows for me.
>> - In extconf.rb ENV[''WXWIN''] did not work for me so I
have $WXDIR hard
>> coded for the windows version.
>> - Also note I have not used SWIG before so excuse any stupid looking 
>> mistakes :)
>>
>> Used:
>> SWIG 1.3.24
>> Rake 0.5.3
>> Ruby 1.8.2
>> wxWidgets 2.6.1
>> Windows XP Pro Service pack 2
>> Mac OS X 10.4.2
>>
>> Sean Long
>>
>>
>> On 7/16/05, Kevin Smith <wxruby@qualitycode.com> wrote:
>>
>>> Roy Sutton wrote (on the FreeRIDE list):
>>>
>>>> Really?  That''s interesting.  I haven''t
checked out WxRuby but I would
>>>> be much happier using something that interfaces to the
underlying
>>>> operating system''s widgets.
>>>
>>>
>>> As a member (and former leader) of the wxruby team, I thought I
would
>>> share the state of the wxruby world.
>>>
>>> The current release is 0.6, and it has pretty good widget support,
but
>>> has a few stability problems, and some pretty bad memory leaks. We
are
>>> rewriting wxruby from scratch using swig, which has some
significant
>>> benefits:
>>> - Fixes the leaks and other memory problems
>>> - Provides much better support for subclassing wx classes
>>> - Makes it easier for non-coders to add support for more classes
>>>
>>> Unfortunately, none of us on the team have had time to bring
wxruby-swig
>>> up to the level where it supports all the classes that are in
wxruby
>>> 0.6. So wxruby-swig has not yet been released. And although we
still
>>> believe in wxruby, none of us are actively developing it right now.
A
>>> motivated person could rapidly make a lot of progress, even if they
>>> don''t know C++. I can offer quick and deep technical
support to anyone
>>> interested in working on wxruby-swig.
>>>
>>> Oh...one other issue. We are a bit caught between supporting the
>>> upstream wx 2.4 library and the recently-released 2.6 version. So
far,
>>> we have focused on 2.4, but as time goes by, more and more people
would
>>> rather have a version that works with 2.6.
>>>
>>> Kevin
>>> _______________________________________________
>>> 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
> 
> 
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users

Sean Long wrote:
> Ok I tried again and got the correct files. It does not compile out of
> the box on OS X with wxWidgets 2.6.1 because of:
> 
> void DrawRoundedRectangle(wxCoord  x , wxCoord  y , wxCoord  width ,
> wxCoord  height , double radius = 20)
> 
> which needs to be
> 
> void DrawRoundedRectangle(wxCoord x , wxCoord y , wxCoord width ,
> wxCoord height , double radius )
Hm. That looks backward to me, but I can''t check it right now.
> But once we get rid of the XML we can just put #ifdef''s in wxDc.h
for
> wxWidgets 2.4.x, 2.5.x , 2.6.x whatever.
Yup.
> Before you said you want to target wxWidgets 2.5.x the only problem I
> see with that it is no longer easy to find on the wxWidgets site since
> it was considered TESTING and 2.6.x is STABLE production quality so
> that is what they push.
True, but Ubuntu stable (Hoary) only has 2.5, so that''s what I 
personally want to target right now. We can primarily target 2.5 on 
Linux and 2.6 on Mac and Windows. Hopefully it will work with a broad 
range of 2.5 - 2.6 anyway.

I think the next Ubuntu release is scheduled for August. At the moment, 
it doesn''t have 2.5 or 2.6, but hopefully that will change.
> I did get my version without XML working, but will wait on your
> version to start implementing new functionality.
Ok.

Kevin

Kevin Smith wrote:
> My next step (tomorrow, hopefully) will be to officially remove 
> wxclasses-2.4.2.xml and extractxml from the project. 
Done.

I tagged this as 0.0.19, because my next step is to upgrade my system to 
wx 2.5, and (probably) break 2.4 compatibility.

Perhaps someone can help me figure out a weird situation on my box. My 
working copy of wxruby-swig seems to be working perfectly...except that 
it doesn''t know about the installers/ directory. cvs update
doesn''t
create it. I tried to copy in Sean''s version and check it in, but cvs 
got all flustered and refused it.

Is there something funky about it on the cvs server? Or is my local 
working copy of wxruby-swig hosed?

Kevin

Kevin Smith wrote:
> Perhaps someone can help me figure out a weird situation on my box. My 
> working copy of wxruby-swig seems to be working perfectly...except that 
> it doesn''t know about the installers/ directory. cvs update
doesn''t
> create it. I tried to copy in Sean''s version and check it in, but
cvs
> got all flustered and refused it.
There''s something funny going on on the server, I think - I had an 
existing repository without installers, but cvs up didn''t create the
dir
when I tried to update my sources with your recent check-ins. A new 
check-out seems to be working OK.

Thanks for pushing things forward, Kevin, Sean

alex

I just did a fresh check out and the installers directory was
generated with a sub directory called
windows. I probably won''t have any time today to test out your changes
but hopefully tomorrow I will.

Sean Long

On 7/18/05, Kevin Smith <wxruby@qualitycode.com>
wrote:
> Kevin Smith wrote:
> > My next step (tomorrow, hopefully) will be to officially remove
> > wxclasses-2.4.2.xml and extractxml from the project.
> 
> Done.
> 
> I tagged this as 0.0.19, because my next step is to upgrade my system to
> wx 2.5, and (probably) break 2.4 compatibility.
> 
> Perhaps someone can help me figure out a weird situation on my box. My
> working copy of wxruby-swig seems to be working perfectly...except that
> it doesn''t know about the installers/ directory. cvs update
doesn''t
> create it. I tried to copy in Sean''s version and check it in, but
cvs
> got all flustered and refused it.
> 
> Is there something funky about it on the cvs server? Or is my local
> working copy of wxruby-swig hosed?
> 
> Kevin
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>

Kevin Smith wrote:
> I tagged this as 0.0.19, because my next step is to upgrade my system to 
> wx 2.5, and (probably) break 2.4 compatibility.
Ugh. I just spent several hours trying to figure out why minimal.rb 
would crash immediately. Finally I realized that Ubuntu''s wxWidgets 
2.5.3 was compiled with UNICODE enabled.

Now I have to decide between:

a. going back to wx 2.4 (at least for now)
b. making it work with wx 2.5.3 unicode
c. manually installing wx 2.6 outside the Ubuntu package manager

I suspect (b) would be too difficult at this point, although it would be 
really cool if I could get it working. As much as I dislike bypassing 
apt/dpkg, I suspect (c) is a better long-term option than (a). Bah.

Kevin

Kevin Smith wrote:
> Ugh. I just spent several hours trying to figure out why minimal.rb 
> would crash immediately. Finally I realized that Ubuntu''s
wxWidgets
> 2.5.3 was compiled with UNICODE enabled.
> 
> Now I have to decide between:
> 
> a. going back to wx 2.4 (at least for now)
> b. making it work with wx 2.5.3 unicode
> c. manually installing wx 2.6 outside the Ubuntu package manager
Holy Freakin Smoke! I actually got it working with option (b). I can run 
minimal and calendar (that''s all I''ve tried) using a unicode
build of
wxWidgets 2.5.3. Woo-hoo!!!

It''s already past my bedtime, so I won''t check anything in
tonight.
Within the next day or two, I should be able to check in changes that 
will allow wxruby-swig to work with unicode or non-unicode builds of wx 
2.5 or 2.6. From now on, wxruby-swig will not support wx 2.4, unless 
someone else steps up to maintain 2.4 compatibility.

My current brain-dead approach assumes that all strings passed in from 
Ruby are UTF-8, and all strings returned to Ruby are also UTF-8. For 
those of you who aren''t familiar with UTF-8, it is a superset of 7-bit 
ASCII, so plain ASCII text will work fine. It shouldn''t be too
difficult
to support other encodings at run-time.

The changes were surprisingly small, thanks to SWIG.

Kevin

I am glad 2.4 will be dropped and the UTF-8 support sounds cool.
Earlier I said I would not have time to try the latest in CVS, well I
did have time and hit a few snags. Mostly just little things in a few
headers like having default parameters when actually the function does
not have defaults, they must have changed a few of these since 2.5.x.
The biggest problem I have is with the Xrc.i file, the following:
%init %{
    extern VALUE mWx;
    rb_define_module_function(mWx, "xrcid", VALUEFUNC(xrcid), 1);
%}

Causes this error when linking:
/usr/bin/ld: multiple definitions of symbol _Init_wxFunctions
Functions.o definition of _Init_wxFunctions in section (__TEXT,__text)
Xrc.o definition of _Init_wxFunctions in section (__TEXT,__text)

Which makes perfect sense but how can we get around this with SWIG? I
could not find anything in the documents like using %extend on %init
or _Init_wxFunctions.

This is where my lack of experience with SWIG hurts me.

Hope you have a slick work around

Sean

On 7/18/05, Kevin Smith <wxruby@qualitycode.com>
wrote:
> Kevin Smith wrote:
> > Ugh. I just spent several hours trying to figure out why minimal.rb
> > would crash immediately. Finally I realized that Ubuntu''s
wxWidgets
> > 2.5.3 was compiled with UNICODE enabled.
> >
> > Now I have to decide between:
> >
> > a. going back to wx 2.4 (at least for now)
> > b. making it work with wx 2.5.3 unicode
> > c. manually installing wx 2.6 outside the Ubuntu package manager
> 
> Holy Freakin Smoke! I actually got it working with option (b). I can run
> minimal and calendar (that''s all I''ve tried) using a
unicode build of
> wxWidgets 2.5.3. Woo-hoo!!!
> 
> It''s already past my bedtime, so I won''t check anything
in tonight.
> Within the next day or two, I should be able to check in changes that
> will allow wxruby-swig to work with unicode or non-unicode builds of wx
> 2.5 or 2.6. From now on, wxruby-swig will not support wx 2.4, unless
> someone else steps up to maintain 2.4 compatibility.
> 
> My current brain-dead approach assumes that all strings passed in from
> Ruby are UTF-8, and all strings returned to Ruby are also UTF-8. For
> those of you who aren''t familiar with UTF-8, it is a superset of
7-bit
> ASCII, so plain ASCII text will work fine. It shouldn''t be too
difficult
> to support other encodings at run-time.
> 
> The changes were surprisingly small, thanks to SWIG.
> 
> Kevin
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>

> I think the next Ubuntu release is scheduled for August. At the moment, 
> it doesn''t have 2.5 or 2.6, but hopefully that will change.
It is scheduled for mid October. Now that it looks that wxruby-swig is going to
work with
the default wx2.5 in ubuntu/debian I am even more interested in packaging it :)

BTW Kevin you still don''t like darcs ;) ? It would be nice if there was
a wxruby-swig repo
of a disconnected SCM, since it seems the number of people interested in
contributing is
growing

Jani

Jani Monoses wrote:
> 
>> I think the next Ubuntu release is scheduled for August. At the 
>> moment, it doesn''t have 2.5 or 2.6, but hopefully that will
change.
> 
> It is scheduled for mid October. Now that it looks that wxruby-swig is 
> going to work with the default wx2.5 in ubuntu/debian I am even more 
> interested in packaging it :)
Thanks for the schedule correction. I sure hope Breezy adds wx 2.5/2.6 
before it is released. It would be GREAT if you could package wxruby for 
Ubuntu, although I also really want to see it as a gem.
> BTW Kevin you still don''t like darcs ;) ? It would be nice if
there was
> a wxruby-swig repo of a disconnected SCM, since it seems the number of 
> people interested in contributing is growing
I am still completely committed to eventually using a distributed SCM. 
My current favorites are ArX[1] and Mercurial[2]. Darcs is a good tool 
in many ways, but has some attributes I don''t like. Same for Monotone, 
codeville, svk, GNU arch, FastCST, git/cogito, bazaar, bazaar-ng...

If my using ArX or Mercurial would increase contributions to wxruby, I 
might try to start using it, with a gateway to keep the CVS tree updated.

Kevin

[1] http://www.nongnu.org/arx/
[2] http://www.selenic.com/mercurial/

Sean Long wrote:
> Earlier I said I would not have time to try the latest in CVS, well I
> did have time and hit a few snags. Mostly just little things in a few
> headers like having default parameters when actually the function does
> not have defaults, they must have changed a few of these since 2.5.x.
Ok. I will rely on you to help us get to the point where it works with 
2.5 and 2.6. It would be perfect for me if you could re-target the rest 
of your source changes against the current HEAD, and send them to me as 
patches (or just paste the little .i fixes into an email).
> The biggest problem I have is with the Xrc.i file, the following:
> %init %{
>     extern VALUE mWx;
>     rb_define_module_function(mWx, "xrcid", VALUEFUNC(xrcid), 1);
> %}
> 
> Causes this error when linking:
> /usr/bin/ld: multiple definitions of symbol _Init_wxFunctions
> Functions.o definition of _Init_wxFunctions in section (__TEXT,__text)
> Xrc.o definition of _Init_wxFunctions in section (__TEXT,__text)
Actually, that was my mistake. At the top of Xrc.i, it should be:
   %module(directors="1") wxXrc

instead of
   %module(directors="1") wxFunctions

Both Functions and Xrc were creating a "wxFunctions" module, causing
the
conflict. I have changed this in my local source, but have not yet 
committed it. Let me know if this change fixes it for you.
> Which makes perfect sense but how can we get around this with SWIG? I
> could not find anything in the documents like using %extend on %init
> or _Init_wxFunctions.
> 
> This is where my lack of experience with SWIG hurts me.
Actually, it''s a lack of experience with the tricks I had to use in 
wxRuby to work around SWIG limitations. SWIG really doesn''t support 
having multiple files combined into a single module. The workaround is 
to SWIG each C++ class as if it were going to end up in a separate 
module. Then the postprocessing .rb commands mangle the created .cpp 
files to all be in the same module. Then it''s up to us (seen at the 
bottom of wx.cpp) to initialize all the classes.

Thanks again,

Kevin

Kevin Smith wrote:
> Holy Freakin Smoke! 
(snip)
> I can run minimal and calendar (that''s all I''ve tried)
using a unicode
> build of wxWidgets 2.5.3. Woo-hoo!!!
Just a couple other notes on this:

1. My wxWidgets is also built to use GTK2, and I immediately noticed 
that the apps look more attractive than they did with wx 2.4 and GTK1.

2. The unicode support I built in should also work fine with non-unicode 
builds of wx, as long as wxruby is built with wx headers that match the 
wx library that it will run with. I guess that means we''ll eventually 
need to ship two wxruby binaries--one for unicode wx, and the other not. 
I''m not sure about that, though. There might be a way to work with both
entirely at runtime.

Kevin

> Holy Freakin Smoke! I actually got it working with option (b). I can run 
> minimal and calendar (that''s all I''ve tried) using a
unicode build of
> wxWidgets 2.5.3. Woo-hoo!!!
CVS HEAD still doesn''t build here with either g++ 3.4 or 4.0.1. I
wonder if something
particular needs to be set.

src/TextCtrl.cpp: In function `VALUE _wrap_wxTextCtrl___lshift____SWIG_0(int,
VALUE*, VALUE)'':
src/TextCtrl.cpp:2066: error: call of overloaded `operator<<(const
char*)'' is ambiguous
/usr/include/wx-2.5/wx/textctrl.h:375: note: candidates are: wxTextCtrl& 
wxTextCtrlBase::operator<<(const wxString&) <near match>
/usr/include/wx-2.5/wx/textctrl.h:376: note:                 wxTextCtrl& 
wxTextCtrlBase::operator<<(int) <near match>
/usr/include/wx-2.5/wx/textctrl.h:377: note:                 wxTextCtrl& 
wxTextCtrlBase::operator<<(long int) <near match>
/usr/include/wx-2.5/wx/textctrl.h:380: note:                 wxTextCtrl& 
wxTextCtrlBase::operator<<(wxChar) <near match>


other than that almost every file has these two warnings

src/StaticBoxSizer.cpp:529: warning: ''alive'' defined but not
used
src/StaticBoxSizer.cpp:535: warning: ''void SWIG_AsVal(VALUE,
int*)'' defined but not used


Jani

Jani Monoses wrote:
> 
> CVS HEAD still doesn''t build here with either g++ 3.4 or 4.0.1. I
wonder
> if something
> particular needs to be set.
> 
> src/TextCtrl.cpp: In function `VALUE 
> _wrap_wxTextCtrl___lshift____SWIG_0(int, VALUE*, VALUE)'':
> src/TextCtrl.cpp:2066: error: call of overloaded `operator<<(const 
Thanks for the report, and sorry about that. I had tweaked TextCtrl.i 
but not checked it in. I have committed it now.
> other than that almost every file has these two warnings
> 
> src/StaticBoxSizer.cpp:529: warning: ''alive'' defined but
not used
I also just checked in a fix to eliminate that.
> src/StaticBoxSizer.cpp:535: warning: ''void SWIG_AsVal(VALUE,
int*)''
> defined but not used
I couldn''t see an obvious place where this was being generated, so it 
will still be a problem.

Also, I checked in the Xrc.i fix that I mentioned earlier, so hopefully 
(fingers crossed) it will build if you set WXRUBY_XRC=YES in your 
environment. However, since xrc is part of wx 2.5+, I will be removing 
that environment setting shortly, and always including xrc.

Cheers,

Kevin

> Thanks for the report, and sorry about that. I had tweaked TextCtrl.i 
> but not checked it in. I have committed it now.
Still the .cpp is the same. If I understand correctly you generate the .cpp
files locally
from the .i files and commit them too? CVS up just gave the 3 modifications you
mentioned.
And I do not run SWIG myself, should I?

>> other than that almost every file has these two warnings
>>
>> src/StaticBoxSizer.cpp:529: warning: ''alive'' defined
but not used
Still there probably because of the same reason.

thanks
Jani

Jani Monoses wrote:
> Still the .cpp is the same. If I understand correctly you generate the 
> .cpp files locally from the .i files and commit them too? CVS up just 
> gave the 3 modifications you mentioned.
> And I do not run SWIG myself, should I?
You should not have to run SWIG yourself, although if you want to 
contribute code you will need to eventually. I just checked in 
EVERYTHING in my tree, so the HEAD should now have the fixed 
TextCtrl.cpp that works with 2.5, and it should avoid the "alive" 
warning, and it includes my unicode work.

Sorry for all the mess caused by my partial commits. I thought I was 
being safer not checking in my hacky unicode stuff last night, but I 
think I actually made things worse for you :-(

Anyway, what''s in the head now is what swigs, compiles, and runs for me
with wx 2.5.3 unicode. I definitely want to hear any problem reports.

Thanks again,

Kevin

> Anyway, what''s in the head now is what swigs, compiles, and runs
for me
> with wx 2.5.3 unicode. I definitely want to hear any problem reports.
Great, it works here too.
samples/etc/choice.rb and samples/dialogs/dialogs.rb (select log in the file
menu) still
give

(wxruby:32194): Pango-WARNING **: Invalid UTF-8 string passed to
pango_layout_set_text()

and no text is shown, some more areas need to be UTF8-ized?

while samples/controls/controls.rb crashes in TextCtrl.new(), something to do
with
arguments not being valid.

I started looking in the sources but it''s still intimidating to try and
track these down :)


thanks
Jani

Jani Monoses wrote:
> 
> samples/etc/choice.rb and samples/dialogs/dialogs.rb (select log in the 
> file menu) still give
> 
> (wxruby:32194): Pango-WARNING **: Invalid UTF-8 string passed to 
> pango_layout_set_text()
> 
> and no text is shown, some more areas need to be UTF8-ized?
I see the same thing here, but won''t touch it until after I get wx 2.6 
working on my system. Probably something needs to be added to 
swig/typemaps.i. If you can at least track down what ruby statement is 
triggering these warnings, it would help.
> while samples/controls/controls.rb crashes in TextCtrl.new(), something 
> to do with arguments not being valid.
If you look in src/TextCtrl.cpp, you''ll see a constructor wrapper that 
chooses which C++ constructor to invoke, based on the number and types 
of the ruby parameters passed in. If you could insert printf''s in this 
constructor, you can probably identify why it is falling through to the 
end without finding any match.

It could be a problem with the ruby code, or with the wxTextCtrl.h api 
file. Typically with other classes that have had similar problems, I 
have added a %ignore to the .i file to eliminate all but one 
constructor. That''s not the right long-term solution, but it has gotten
several classes to work.
> I started looking in the sources but it''s still intimidating to
try and
> track these down :)
Yup. Hopefully with the information above you can make an attempt. If 
not, I''ll get back to it in a few days.

Thanks,

Kevin

Kevin Smith wrote:
> Jani Monoses wrote:
> 
>>
>> samples/etc/choice.rb and samples/dialogs/dialogs.rb (select log in 
>> the file menu) still give
>>
>> (wxruby:32194): Pango-WARNING **: Invalid UTF-8 string passed to 
>> pango_layout_set_text()
>>
>> and no text is shown, some more areas need to be UTF8-ized?
> 
> 
> I see the same thing here, but won''t touch it until after I get wx
2.6
> working on my system. Probably something needs to be added to 
> swig/typemaps.i. If you can at least track down what ruby statement is 
> triggering these warnings, it would help.
I haven''t looked at this back then , but I might this weekend.
>> while samples/controls/controls.rb crashes in TextCtrl.new(), 
>> something to do with arguments not being valid.
> 
> 
> If you look in src/TextCtrl.cpp, you''ll see a constructor wrapper
that
> chooses which C++ constructor to invoke, based on the number and types 
> of the ruby parameters passed in. If you could insert printf''s in
this
> constructor, you can probably identify why it is falling through to the 
> end without finding any match.
I actually inserted printfs there and modified the TextcCtrl.new() invocation in
ruby
so it bailed out at different stages of that large if() statement
But what I could not figure out is what types ans how many args that initializer
must have
t behave correctly.
But it probably has to do with the fact you mention that you only allowed one
type of
constructor and the ruby code used another one.

Jani

Sean Long wrote:
> Kevin,
> 
> After working on this for awhile I think the project should only focus
> on wxWidgets 2.6.1 and beyond. If anyone wants to use wxWidgets 2.4.x
> they can use the old wxRuby 0.6 path.
Kevin,

I hope wxruby will support wxWidgets 2.6.0 instead of requiring 2.6.1.

I''m not allowed to use wxWidgets 2.6.1 because the change in license 
(from 2.6.0) forces derived *binary* works to require distribution terms 
to allow reverse-engineering and modifications by end users.

We use wxWidgets 2.6.0 primarily with C++ but I''m trying to spread the 
use of both ruby and wxruby at work.  Requiring 2.6.1 will make wxruby 
unusable by us because we are not allowed to link anything we develop 
with it.

I''m hoping wxWidgets 2.6.2 will revert back to the less restrictive 
license found in the wxWidgets 2.6.0 Manual.

DJB wrote:
> 
> I hope wxruby will support wxWidgets 2.6.0 instead of requiring 2.6.1.
> 
> I''m not allowed to use wxWidgets 2.6.1 because the change in
license
> (from 2.6.0) forces derived *binary* works to require distribution terms 
> to allow reverse-engineering and modifications by end users.
Very interesting. Personally, I think reverse-engineering should always 
be allowed, but my position as wxRuby lead has always been that our 
library should be useable by pretty much anyone in pretty much any way 
they wish.

Can you point to the 2.6.1 license text that causes a problem? I''m 
looking at the wxWidgets CVS repository. It seems that for at least 6 
years, the LGPL v2 has said:

---
6. As an exception to the Sections above, you may also compile
or link a "work that uses the Library" with the Library to
produce a work containing portions of the Library, and
distribute that work under terms of your choice, provided that
the terms permit modification of the work for the customer''s own
use and reverse engineering for debugging such modifications.
---

But it appears that the wxWindows/wxWidgets library allows you to 
override this with your own exception, as it says in the wxWidgets v3 
license (which hasn''t changed for 14 months):

--
2. The exception is that you may use, copy, link, modify and distribute
under the user''s own terms, binary object code versions of works based
on the Library.
--

My interpretation of that (and I am not a lawyer) would be that as long 
as you only distributed binary code, you could do so under your "own 
terms", which could prevent modifications and reverse-engineering.

Kevin

Jani Monoses wrote:
>>> while samples/controls/controls.rb crashes in TextCtrl.new(), 
>>> something to do with arguments not being valid.
I fixed this for now by disabling the second constructor, which isn''t 
really necessary anyway.

Kevin

DISCLAIMER:  Seek the advice of an intellectual property attorney before 
taking any action related to copyright and licensing. This message is 
for entertainment purposes only and may contain numerous factual errors.

Kevin Smith wrote:
> Can you point to the 2.6.1 license text that causes a problem? I''m
> looking at the wxWidgets CVS repository. It seems that for at least 6 
> years, the LGPL v2 has said:
The differences can be seen in the .chm manual files distributed with 
wxWidgets and online at:

http://www.wxwidgets.org/manuals/2.6.1/wx_wxlicense.html#wxlicense
http://www.wxwidgets.org/manuals/2.6.0/wx_wxlicense.html#wxlicense
> My interpretation of that (and I am not a lawyer) would be that as long 
> as you only distributed binary code, you could do so under your "own 
> terms", which could prevent modifications and reverse-engineering.
> 
> Kevin
LGPL only allows distribution of works based on an LGPL library under 
"terms of your choice" only if your terms permit reverse-engineering
and
modifications by end users (see LGPL Section 6).

wxWidgets is covered by LGPL but exceptions to various terms of LGPL are 
granted for binaries.  These exceptions to LGPL terms differ between 
2.6.0 and 2.6.1.

This means vendors distributing shareware or trial versions of software 
linked to LGPL libraries must do something that doesn''t make sense for 
their situation.  Many customers won''t pay if the vendors give them
full
LEGAL permission to patch the trial or shareware version. Or pay for 
expensive Enterprise editions if the cheaper Standard edition can be 
patched legally.

The 2.6.0 license made it clear that binaries are not subject to LGPL 
restrictions when being distributed on your own terms because of the 
phrase "distribute [...] unrestricted under terms of your choice".

The 2.6.1 license removed the word "unrestricted", among other things,
so that if the binaries are distributed under non-LGPL terms, those 
terms must permit reverse-engineering and modifications by end users.

One more confusion 2.6.1 license introduced is the use of the word 
"user''s" when the licensee ("you") was already
identified as "you" in
the same sentence:

2.6.1: "you may [...] distribute under the user''s own terms"
2.6.0: "you may [...] distribute [...] unrestricted under terms of your 
choice"

Since the licensee was referred in the sentence as "you", the use of
the
word "user''s" cannot simply be assumed to refer to the same. 
It is not
unreasonable to believe "user''s" now refers to the end-user
of the
combined product, especially given that the wxWidgets is free and open 
source.

In other words, the 2.6.1 license is a big risk for closed-source 
commercial products.  If 2.6.2 doesn''t fix the license, I
wouldn''t be
surprised if a bunch of closed source projects migrates away from wxWidgets.

ps

Please ask a GPL Compliance Engineer at Free Software Foundation 
(fsf.org) before dismissing my explanation.  A helpful expert like David 
Turner will probably respond with a detailed explanation within a week 
or so.  The LGPL is one of the most misunderstood licenses because 
people don''t bother reading it or they don''t bother asking the
right
people for clarifications.

DJB wrote:
> The differences can be seen in the .chm manual files distributed with 
> wxWidgets and online at:
> 
> http://www.wxwidgets.org/manuals/2.6.1/wx_wxlicense.html#wxlicense
> http://www.wxwidgets.org/manuals/2.6.0/wx_wxlicense.html#wxlicense
Perhaps, but I believe the software would be covered by the LICENSE.TXT 
that is distributed with the software itself, and as far as I can tell 
the change you refer to was actually made 14 months ago. So based on 
what I''m seeing in the wxWidgets CVS tree, all wxWidgets versions from 
2.5.2 on are bound by the license terms you dislike. Which version of 
the license is in the 2.6.0 wxWidgets tarball that you downloaded?
> Since the licensee was referred in the sentence as "you", the use
of the
> word "user''s" cannot simply be assumed to refer to the
same.  It is not
> unreasonable to believe "user''s" now refers to the
end-user of the
> combined product, especially given that the wxWidgets is free and open 
> source.
I agree that the new wording is confusing and should be changed.
> Please ask a GPL Compliance Engineer at Free Software Foundation 
> (fsf.org) before dismissing my explanation.  A helpful expert like David 
> Turner will probably respond with a detailed explanation within a week 
> or so.  The LGPL is one of the most misunderstood licenses because 
> people don''t bother reading it or they don''t bother
asking the right
> people for clarifications.
For this, I probably wouldn''t rely on an FSF interpretation, because
the
wording in question is in the wx-specific exception. The LGPL is clear, 
but it''s not entirely clear whether the wx exception bypasses the LGPL 
or not.

Thanks,

Kevin