From alex at pressure.to  Wed Apr  5 09:45:42 2006
From: alex at pressure.to (Alex Fenton)
Date: Wed, 05 Apr 2006 14:45:42 +0100
Subject: [Wxruby-users] RubyConstants.i patch
In-Reply-To: <442B6F70.3030105@mindspring.com>
References: <442B6F70.3030105@mindspring.com>
Message-ID: <4433CA06.7090906@pressure.to>

Hi Roy

Thanks for the patch. It fixes the problem with undefined constants, but 
I still get a compile error for the ART_ constants:

src/RubyConstants.cpp:3555: error: cannot convert `const wchar_t*' to 
`const
   char*' for argument `1' to `VALUE SWIG_FromCharPtr(const char*)'

I wonder if I'm seeing this because I'm using a unicode build of WxWidgets?

alex

Roy Sutton wrote:
> This patch fixes the problem with the undefined constants.  Apologies 
> to Alex as I didn't apply his patches yet.  The fix is to just removed 
> the _C from the end of the ones that won't compile anymore.
>
> Roy
> ------------------------------------------------------------------------
>
>
> C:\RubyDev>diff -b -u wxruby2_old/swig/RubyConstants.i wxruby2/swig/RubyConstants.i  
> --- wxruby2_old/swig/RubyConstants.i	2005-09-18 12:57:20.000000000 -0400
> +++ wxruby2/swig/RubyConstants.i	2006-03-30 00:34:50.582779900 -0500
> @@ -1896,13 +1896,13 @@
>  
>  %constant const char *FILE_SELECTOR_DEFAULT_WILDCARD_STR = "*.*";
>  
> -%constant const char * ART_TOOLBAR               = wxART_TOOLBAR_C;
> -%constant const char * ART_MENU                  = wxART_MENU_C;
> -%constant const char * ART_FRAME_ICON            = wxART_FRAME_ICON_C;
> -%constant const char * ART_CMN_DIALOG            = wxART_CMN_DIALOG_C;
> -%constant const char * ART_HELP_BROWSER          = wxART_HELP_BROWSER_C;
> -%constant const char * ART_MESSAGE_BOX           = wxART_MESSAGE_BOX_C;
> -%constant const char * ART_OTHER                 = wxART_OTHER_C;
> +%constant const char * ART_TOOLBAR               = wxART_TOOLBAR;
> +%constant const char * ART_MENU                  = wxART_MENU;
> +%constant const char * ART_FRAME_ICON            = wxART_FRAME_ICON;
> +%constant const char * ART_CMN_DIALOG            = wxART_CMN_DIALOG;
> +%constant const char * ART_HELP_BROWSER          = wxART_HELP_BROWSER;
> +%constant const char * ART_MESSAGE_BOX           = wxART_MESSAGE_BOX;
> +%constant const char * ART_OTHER                 = wxART_OTHER;
>  
>  %constant const char * ART_ADD_BOOKMARK          = wxART_ADD_BOOKMARK;
>  %constant const char * ART_DEL_BOOKMARK          = wxART_DEL_BOOKMARK;
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users


From tyamadajp at list.rakugaki.org  Fri Apr  7 05:28:39 2006
From: tyamadajp at list.rakugaki.org (Taisuke Yamada)
Date: Fri, 07 Apr 2006 18:28:39 +0900
Subject: [Wxruby-users] Pointer position on keypress event?
Message-ID: <7vnhg3xasd.ln2@home.rakugaki.org>

Hi.

Is there any straightforward way to tell pointer position (x, y)
upon keypress? In original wxWidgets, wxKeyEvent supports GetX()
and GetY() methods, but wxRuby's KeyEvent object does not have
one. I also checked with event.methods and event.instance_variables.

Do I need to keep track of pointer position by evt_motion?

--
Taisuke Yamada <tyamadajp at spam.rakugaki.org>, http://rakugaki.org/
2268 E9A2 D4F9 014E F11D  1DF7 DCA3 83BC 78E5 CD3A

Message to my public address may not be handled in a timely manner.
For a direct contact, please use my private address on my namecard.


From alex at pressure.to  Sun Apr  9 05:59:43 2006
From: alex at pressure.to (Alex Fenton)
Date: Sun, 09 Apr 2006 10:59:43 +0100
Subject: [Wxruby-users] Pointer position on keypress event?
In-Reply-To: <7vnhg3xasd.ln2@home.rakugaki.org>
References: <7vnhg3xasd.ln2@home.rakugaki.org>
Message-ID: <4438DB0F.3060101@pressure.to>

Hi

Are you using wxruby 0.6.0 or wxruby2? I know several event classes are 
missing in wxruby 0.6.0 which isn't being developed. The event handler 
is fired correctly, but a generic WxEvent is returned which doesn't have 
all the expected methods.

I have just tried evt_key_down in wxruby2 which is currently being 
developed. The KeyEvent has the get_x(), get_y() and get_position() methods.

However, the value of get_x and get_y seems to be always 0. This may be 
a bug - perhaps someone else could try and confirm, and then we can work 
on a fix. Do you have a short sample we could see please?

cheers
alex


> Is there any straightforward way to tell pointer position (x, y)
> upon keypress?
> In original wxWidgets, wxKeyEvent supports GetX()
> and GetY() methods, but wxRuby's KeyEvent object does not have
> one. I also checked with event.methods and event.instance_variables.
>
> Do I need to keep track of pointer position by evt_motion?
>
> --
> Taisuke Yamada <tyamadajp at spam.rakugaki.org>, http://rakugaki.org/
> 2268 E9A2 D4F9 014E F11D  1DF7 DCA3 83BC 78E5 CD3A
>
> Message to my public address may not be handled in a timely manner.
> For a direct contact, please use my private address on my namecard.
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>   


From wxruby at qualitycode.com  Sun Apr  9 22:29:16 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sun, 09 Apr 2006 22:29:16 -0400
Subject: [Wxruby-users] Patch for Swig 1.3.29
In-Reply-To: <442806EE.3090300@mindspring.com>
References: <442806EE.3090300@mindspring.com>
Message-ID: <1144636156.8424.1.camel@localhost.localdomain>

Nice work Roy. Thanks.

I have updated fixmodule.rb to accomplish the same effect without
needing to patch swig itself.

But I don't want to check it in until I get everything working again,
which I will describe in another email.

Kevin


On Mon, 2006-03-27 at 10:38 -0500, Roy Sutton wrote:
> Attached is a patch for Swig that at least allows us to link the 
> library.  I am experiencing a number of bugs that will need to be 
> tracked down and squashed.   I haven't even had time to look at the 
> newer Swig features yet.
> 
> Roy


From wxruby at qualitycode.com  Sun Apr  9 22:33:18 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sun, 09 Apr 2006 22:33:18 -0400
Subject: [Wxruby-users] Patch for wxControl.h
In-Reply-To: <442B6D3C.8030107@mindspring.com>
References: <442B6D3C.8030107@mindspring.com>
Message-ID: <1144636398.8424.6.camel@localhost.localdomain>

On Thu, 2006-03-30 at 00:31 -0500, Roy Sutton wrote:
> Hello all.  This gets past the problem in bigdemo where it won't start 
> the application at all.  That was where it was overflowing the stack on 
> get_label.

This one is driving me INSANE. When I made this same change, my compiler
(gcc 4.0.2 I believe) complains that wxControl is not a base class of
wxTreeCtrl. But *it is*. I have a couple things left to try, but at this
point I am completely confused. It knows that wxWindow is an ancestor,
but not wxControlBase or wxControl. ARGH!

Has anyone else tried this patch, and has it worked?

Kevin



From wxruby at qualitycode.com  Sun Apr  9 22:34:19 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sun, 09 Apr 2006 22:34:19 -0400
Subject: [Wxruby-users] RubyConstants.i patch
In-Reply-To: <442B6F70.3030105@mindspring.com>
References: <442B6F70.3030105@mindspring.com>
Message-ID: <1144636459.8424.8.camel@localhost.localdomain>

On Thu, 2006-03-30 at 00:41 -0500, Roy Sutton wrote:
> This patch fixes the problem with the undefined constants.  Apologies to 
> Alex as I didn't apply his patches yet.  The fix is to just removed the 
> _C from the end of the ones that won't compile anymore.

Yup. I have made this change, but have not yet checked it in due to the
GetLabel problem mentioned in the other email.

Kevin



From wxruby at qualitycode.com  Sun Apr  9 22:35:15 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sun, 09 Apr 2006 22:35:15 -0400
Subject: [Wxruby-users] RubyConstants.i patch
In-Reply-To: <4433CA06.7090906@pressure.to>
References: <442B6F70.3030105@mindspring.com> <4433CA06.7090906@pressure.to>
Message-ID: <1144636516.8424.10.camel@localhost.localdomain>

On Wed, 2006-04-05 at 14:45 +0100, Alex Fenton wrote:
> I still get a compile error for the ART_ constants:
> 
> src/RubyConstants.cpp:3555: error: cannot convert `const wchar_t*' to 
> `const
>    char*' for argument `1' to `VALUE SWIG_FromCharPtr(const char*)'
> 
> I wonder if I'm seeing this because I'm using a unicode build of WxWidgets?

I saw the same problem. Changing those "char" to "wchar_t" fixed it. I
haven't checked it in yet.

Kevin



From wxruby at qualitycode.com  Mon Apr 10 00:22:28 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Mon, 10 Apr 2006 00:22:28 -0400
Subject: [Wxruby-users] Patch for wxControl.h
In-Reply-To: <1144636398.8424.6.camel@localhost.localdomain>
References: <442B6D3C.8030107@mindspring.com>
	<1144636398.8424.6.camel@localhost.localdomain>
Message-ID: <1144642948.11292.2.camel@localhost.localdomain>

On Sun, 2006-04-09 at 22:33 -0400, Kevin Smith wrote:
> This one is driving me INSANE. When I made this same change, my compiler
> (gcc 4.0.2 I believe) complains that wxControl is not a base class of
> wxTreeCtrl. But *it is*. I have a couple things left to try, but at this
> point I am completely confused. It knows that wxWindow is an ancestor,
> but not wxControlBase or wxControl. ARGH!

Quick update: I haven't solved it, but at least I know mostly what is
going on. With my wx installation, for whatever reason, wxTreeCtrl
inherits from wxGenericTreeCtrl, which inherits from wxScrolledWindow.
So it bypasses wxControl, which means our classes/include/wxTreeCtrl.h
is incorrect.

Hopefully later this week I'll be able to go back and fix this, somehow.
Hopefully in a way that will work on all platforms.

By the way, the tool I used to figure this out was to add -E to the
compiler flags. That sends the preprocessor results to the .o file
instead of actual object code. With that, I was able to see the actual
class hierarchy, rather than the one that I thought I was seeing when I
looked at the wx header files.

Kevin



From roys at mindspring.com  Mon Apr 10 00:29:52 2006
From: roys at mindspring.com (Roy Sutton)
Date: Mon, 10 Apr 2006 00:29:52 -0400
Subject: [Wxruby-users] Patch for wxControl.h
In-Reply-To: <1144642948.11292.2.camel@localhost.localdomain>
References: <442B6D3C.8030107@mindspring.com>	<1144636398.8424.6.camel@localhost.localdomain>
	<1144642948.11292.2.camel@localhost.localdomain>
Message-ID: <4439DF40.4000004@mindspring.com>

Glad to see you're getting to the bottom of this.  I imagine this won't 
be the last time different hierarchies will bite us in the butt.  I'm 
taking a bit of time to get more familiar with Swig so that I won't feel 
so lost when we get into the object tracking portion.

Kevin Smith wrote:
> On Sun, 2006-04-09 at 22:33 -0400, Kevin Smith wrote:
>   
>> This one is driving me INSANE. When I made this same change, my compiler
>> (gcc 4.0.2 I believe) complains that wxControl is not a base class of
>> wxTreeCtrl. But *it is*. I have a couple things left to try, but at this
>> point I am completely confused. It knows that wxWindow is an ancestor,
>> but not wxControlBase or wxControl. ARGH!
>>     
>
> Quick update: I haven't solved it, but at least I know mostly what is
> going on. With my wx installation, for whatever reason, wxTreeCtrl
> inherits from wxGenericTreeCtrl, which inherits from wxScrolledWindow.
> So it bypasses wxControl, which means our classes/include/wxTreeCtrl.h
> is incorrect.
>
> Hopefully later this week I'll be able to go back and fix this, somehow.
> Hopefully in a way that will work on all platforms.
>
> By the way, the tool I used to figure this out was to add -E to the
> compiler flags. That sends the preprocessor results to the .o file
> instead of actual object code. With that, I was able to see the actual
> class hierarchy, rather than the one that I thought I was seeing when I
> looked at the wx header files.
>
> Kevin
>
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>
>   

From tyamadajp at list.rakugaki.org  Mon Apr 10 21:48:33 2006
From: tyamadajp at list.rakugaki.org (Taisuke Yamada)
Date: Tue, 11 Apr 2006 10:48:33 +0900
Subject: [Wxruby-users] Pointer position on keypress event?
In-Reply-To: <4438DB0F.3060101@pressure.to>
References: <7vnhg3xasd.ln2@home.rakugaki.org> <4438DB0F.3060101@pressure.to>
Message-ID: <443B0AF1.6010408@list.rakugaki.org>

I'm using wxruby 0.6.0 (binary package downloaded from sourceforge).
Attached is a sample script, but I can confirm 0.6.0 does not
have get_x/get_y methods nor equivalent instance variables.

Guess it's time for wxruby2?
Is there any compiled package available?

BTW, I tested similar code on C++ wxWidgets, and wxKeyEvent did
return proper pointer location with GetX()/GetY(). So wxruby2
seems to have its own issue.

> Are you using wxruby 0.6.0 or wxruby2? I know several event classes are 
> missing in wxruby 0.6.0 which isn't being developed. The event handler 
> is fired correctly, but a generic WxEvent is returned which doesn't have 
> all the expected methods.
> 
> I have just tried evt_key_down in wxruby2 which is currently being 
> developed. The KeyEvent has the get_x(), get_y() and get_position() methods.
> 
> However, the value of get_x and get_y seems to be always 0. This may be 
> a bug - perhaps someone else could try and confirm, and then we can work 
> on a fix. Do you have a short sample we could see please?
> 
>> Is there any straightforward way to tell pointer position (x, y)
>> upon keypress?
>> In original wxWidgets, wxKeyEvent supports GetX()
>> and GetY() methods, but wxRuby's KeyEvent object does not have
>> one. I also checked with event.methods and event.instance_variables.
>>
>> Do I need to keep track of pointer position by evt_motion?

--
Taisuke Yamada <tyamadajp at spam.rakugaki.org>, http://rakugaki.org/
2268 E9A2 D4F9 014E F11D  1DF7 DCA3 83BC 78E5 CD3A

Message to my public address may not be handled in a timely manner.
For a direct contact, please use my private address on my namecard.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: wx-keydown-and-pointer.rb
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060411/700cb713/attachment.bat 

From alex at pressure.to  Tue Apr 11 20:14:38 2006
From: alex at pressure.to (Alex Fenton)
Date: Wed, 12 Apr 2006 01:14:38 +0100
Subject: [Wxruby-users] Pointer position on keypress event?
In-Reply-To: <443B0AF1.6010408@list.rakugaki.org>
References: <7vnhg3xasd.ln2@home.rakugaki.org> <4438DB0F.3060101@pressure.to>
	<443B0AF1.6010408@list.rakugaki.org>
Message-ID: <443C466E.10502@pressure.to>



Taisuke Yamada wrote:
> I'm using wxruby 0.6.0 (binary package downloaded from sourceforge).
> Attached is a sample script, but I can confirm 0.6.0 does not
> have get_x/get_y methods nor equivalent instance variables.
That sounds familiar
> Guess it's time for wxruby2?
> Is there any compiled package available?
We hope to have one soon; people are working on it now. Rapid 
development of ruby-SWIG has caused a few breakages
> BTW, I tested similar code on C++ wxWidgets, and wxKeyEvent did
> return proper pointer location with GetX()/GetY(). So wxruby2
> seems to have its own issue.
OK, sounds like a bug on Mac OS X at least. What platform are you on?

I've just tested evt_motion with Wx::Window and Wx::TextCtrl and it does 
have the x and y position available - if you feel like writing a little 
tracking code.

alex


From alex at pressure.to  Wed Apr 12 07:46:31 2006
From: alex at pressure.to (Alex Fenton)
Date: Wed, 12 Apr 2006 12:46:31 +0100
Subject: [Wxruby-users] Patch for wxControl.h
In-Reply-To: <1144636398.8424.6.camel@localhost.localdomain>
References: <442B6D3C.8030107@mindspring.com>
	<1144636398.8424.6.camel@localhost.localdomain>
Message-ID: <443CE897.7070007@pressure.to>

Kevin Smith wrote:
> Has anyone else tried this patch, and has it worked?
>   
I tried it, and had to back out to get it to wxruby2 to compile.

With it applied, on OS X I get the output below:

alex


core_name: TreeCtrl
g++ -c -I/usr/local/lib/wx/include/mac-unicode-release-static-2.6 
-I/usr/local/include/wx-2.6 -D__WXMAC__ -D_FILE_OFFSET_BITS=64 
-D_LARGE_FILES -DNO_GCC_PRAGMA   -O2 -pipe -fno-common -x objective-c++  
-I /usr/local/lib/ruby/gems/1.8/gems/rake-0.7.0/bin -I 
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.0/lib -I 
/Applications/Emacs.app/Contents/Resources/lib/ruby/site_ruby -I 
/usr/local/lib/ruby/site_ruby/1.8 -I 
/usr/local/lib/ruby/site_ruby/1.8/powerpc-darwin7.9.0 -I 
/usr/local/lib/ruby/site_ruby -I /usr/local/lib/ruby/1.8 -I 
/usr/local/lib/ruby/1.8/powerpc-darwin7.9.0 -I . -o obj/TreeCtrl.o 
src/TreeCtrl.cpp
src/TreeCtrl.cpp: In member function `virtual wxString
   SwigDirector_wxTreeCtrl::GetLabel()':
src/TreeCtrl.cpp:2904: error: cannot call member function `virtual wxString
   wxWindowBase::GetLabel() const' without object
src/TreeCtrl.cpp: In member function `virtual void
   SwigDirector_wxTreeCtrl::SetLabel(const wxString&)':
src/TreeCtrl.cpp:3419: error: cannot call member function `virtual void
   wxControlBase::SetLabel(const wxString&)' without object
rake aborted!

From alex at pressure.to  Wed Apr 12 09:17:16 2006
From: alex at pressure.to (Alex Fenton)
Date: Wed, 12 Apr 2006 14:17:16 +0100
Subject: [Wxruby-users] *OUTPUT/*INPUT typemaps
Message-ID: <443CFDDC.9050009@pressure.to>

Hi

Have been looking again at SWIG output pointer parameters, as:
http://www.swig.org/Doc1.3/Ruby.html#Ruby_nn32

The problem is, whenever I tried to include the SWIG/Ruby 'typemaps.i' 
file, it threw loads of errors.

A bit more investigation pinned the problem down to some secondary files 
that typemaps.i includes to map 'special' types like File.

So I tried just copying the section from SWIG's ruby/typemaps.i that 
deals with output, input and inout mapping of simple types like int, 
long etc. It's attached. I pasted this into our own swig/typemap.i file 
and recompiled.

And it seems to work. For example, with Wx::Window#get_text_extent, I 
added the directives

%apply int *OUTPUT { int*  x , int*  y , int*  descent, int*  
externalLeading};
%apply wxFont *INPUT { const wxFont*  font };

And then the method correctly returns a four-element array containing 
width, height, descent and leading. I also tried 
Wx::TextCtrl#position_to_xy.

This could help us fix quite a few useful methods, but I'm not sure if 
this is generally the right approach (block-copying from typemaps.i to 
our typemap.i).

If it sounds right, let me know and I'll generate proper patches and 
send them in.

cheers
alex


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: inout_typemaps.i
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060412/f864987c/attachment-0001.bat 

From wxruby at qualitycode.com  Wed Apr 12 19:48:38 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Wed, 12 Apr 2006 19:48:38 -0400
Subject: [Wxruby-users] wxTreeCtrl has different parents on different
	platforms (was:	Patch for wxControl.h)
In-Reply-To: <443CE897.7070007@pressure.to>
References: <442B6D3C.8030107@mindspring.com>
	<1144636398.8424.6.camel@localhost.localdomain>
	<443CE897.7070007@pressure.to>
Message-ID: <1144885719.8808.48.camel@localhost.localdomain>

Thanks Alex. That's the same error I have seen.

I think I know how to fix it, but it's not very pretty. Right now,
there's a C++ class (wxTreeCtrl) which inherits from either wxControl or
wxGenericTreeCtrl, depending on platform. Thanks to SWIG directors, we
are creating a DirectorTreeCtrl (not the real name, but let's pretend it
is) which inherits from wxTreeCtrl.

The problem comes in when there are virtual methods in an ancestor that
are not implemented in the bottom class. For example, wxWindow defines a
virtual getLabel method which is overridden in wxControl. It is critical
that calls to DirectorTreeCtrl get forwarded to the correct ancestor
method, which ends up in the generated C++ file as something like
wxControl::GetLabel(). At swig-time, we would need to alter the class
hierarchy, but that's declared in the swig/classes/include/*.h files, so
it's hard to change them.

My workaround (partially shown to maybe work) is to do what we did with
wxApp, and insert a new C++ class into the hierarchy within the .i file.
In TreeCtrl.i we would declare a RubyTreeCtrl class that inherits from
wxTreeCtrl. It would implement any virtual methods in the ancestors, but
the code body for each would be to just delegate to
wxTreeCtrl::Method().

Then, we would tell SWIG to wrap RubyTreeCtrl (instead of wxTreeCtrl),
and we would also rename the result as TreeCtrl (instead of
RubyTreeCtrl).

Yuck. Cross-platform stuff is messy. Hopefully I'll have more time this
weekend to implement what I've described here. 

Kevin


On Wed, 2006-04-12 at 12:46 +0100, Alex Fenton wrote:
> Kevin Smith wrote:
> > Has anyone else tried this patch, and has it worked?
> >   
> I tried it, and had to back out to get it to wxruby2 to compile.
> 
> With it applied, on OS X I get the output below:
> 
> alex
> 
> 
> core_name: TreeCtrl
> g++ -c -I/usr/local/lib/wx/include/mac-unicode-release-static-2.6 
> -I/usr/local/include/wx-2.6 -D__WXMAC__ -D_FILE_OFFSET_BITS=64 
> -D_LARGE_FILES -DNO_GCC_PRAGMA   -O2 -pipe -fno-common -x objective-c++  
> -I /usr/local/lib/ruby/gems/1.8/gems/rake-0.7.0/bin -I 
> /usr/local/lib/ruby/gems/1.8/gems/rake-0.7.0/lib -I 
> /Applications/Emacs.app/Contents/Resources/lib/ruby/site_ruby -I 
> /usr/local/lib/ruby/site_ruby/1.8 -I 
> /usr/local/lib/ruby/site_ruby/1.8/powerpc-darwin7.9.0 -I 
> /usr/local/lib/ruby/site_ruby -I /usr/local/lib/ruby/1.8 -I 
> /usr/local/lib/ruby/1.8/powerpc-darwin7.9.0 -I . -o obj/TreeCtrl.o 
> src/TreeCtrl.cpp
> src/TreeCtrl.cpp: In member function `virtual wxString
>    SwigDirector_wxTreeCtrl::GetLabel()':
> src/TreeCtrl.cpp:2904: error: cannot call member function `virtual wxString
>    wxWindowBase::GetLabel() const' without object
> src/TreeCtrl.cpp: In member function `virtual void
>    SwigDirector_wxTreeCtrl::SetLabel(const wxString&)':
> src/TreeCtrl.cpp:3419: error: cannot call member function `virtual void
>    wxControlBase::SetLabel(const wxString&)' without object
> rake aborted!
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users


From wxruby at qualitycode.com  Thu Apr 13 22:48:30 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Thu, 13 Apr 2006 22:48:30 -0400
Subject: [Wxruby-users] *OUTPUT/*INPUT typemaps
In-Reply-To: <443CFDDC.9050009@pressure.to>
References: <443CFDDC.9050009@pressure.to>
Message-ID: <1144982910.18295.17.camel@localhost.localdomain>

On Wed, 2006-04-12 at 14:17 +0100, Alex Fenton wrote:
> Hi
> 
> Have been looking again at SWIG output pointer parameters, as:
> http://www.swig.org/Doc1.3/Ruby.html#Ruby_nn32

Excellent! This is going to be really important for wxruby.

> The problem is, whenever I tried to include the SWIG/Ruby 'typemaps.i' 
> file, it threw loads of errors.
> 
> A bit more investigation pinned the problem down to some secondary files 
> that typemaps.i includes to map 'special' types like File.
> 
> So I tried just copying the section from SWIG's ruby/typemaps.i that 
> deals with output, input and inout mapping of simple types like int, 
> long etc. It's attached. I pasted this into our own swig/typemap.i file 
> and recompiled.
(snip)
> This could help us fix quite a few useful methods, but I'm not sure if 
> this is generally the right approach (block-copying from typemaps.i to 
> our typemap.i).
> 
> If it sounds right, let me know and I'll generate proper patches and 
> send them in.

I really don't want copied code. Is there any hope of fixing the compile
errors in ruby/typemaps.i? That seems like the "right" solution. If not,
I wonder if we could have a little script that copies ruby/typemaps.i
into our swig directory, and then comments out the offending includes?
That way, at least, we would automatically gain the benefits of any
improvements by the swig folks.

Can you take a stab at those compile errors, and post any specific
messages that you have trouble working around?

Thanks,

Kevin



From alex at pressure.to  Fri Apr 14 05:43:41 2006
From: alex at pressure.to (Alex Fenton)
Date: Fri, 14 Apr 2006 10:43:41 +0100
Subject: [Wxruby-users] *OUTPUT/*INPUT typemaps
In-Reply-To: <1144982910.18295.17.camel@localhost.localdomain>
References: <443CFDDC.9050009@pressure.to>
	<1144982910.18295.17.camel@localhost.localdomain>
Message-ID: <443F6ECD.3040007@pressure.to>

Kevin Smith wrote:
> I really don't want copied code. Is there any hope of fixing the compile
> errors in ruby/typemaps.i? That seems like the "right" solution. 
Fair enough, I agree with your rationale. There's no chance I can fix 
it, but every chance someone else here can ;)

If SWIG's 'typemap.i'file' is properly %included, it includes SWIG 
'file.i', which starts with

#ifdef __cplusplus
extern "C" {
#endif
#include "rubyio.h"
#ifdef __cplusplus
}
#endif

This turns up in App.cpp (for example), and causes the compile to fail 
with a lot of errors like:

/usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:30: error: parse error
   before `(' token
In file included from src/App.cpp:1591:
/usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:30:46: pasting "L" 
and "(" does not give a valid preprocessing token
/usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:64: error: syntax 
error
   before `(' token
/usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:64:44: pasting "L" 
and "(" does not give a valid preprocessing token
/usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:65: error: syntax 
error
   before `(' token

cheers
alex

From alec at arlross.demon.co.uk  Fri Apr 14 07:13:09 2006
From: alec at arlross.demon.co.uk (Alec Ross)
Date: Fri, 14 Apr 2006 12:13:09 +0100
Subject: [Wxruby-users] *OUTPUT/*INPUT typemaps
In-Reply-To: <443F6ECD.3040007@pressure.to>
References: <443CFDDC.9050009@pressure.to>
	<1144982910.18295.17.camel@localhost.localdomain>
	<443F6ECD.3040007@pressure.to>
Message-ID: <wXNIpzEFP4PEFw1h@arlross.demon.co.uk>

Sorry if any of the comments below are too obvious, but ...

In message <443F6ECD.3040007 at pressure.to>, Alex Fenton 
<alex at pressure.to> writes
>Kevin Smith wrote:
>> I really don't want copied code. Is there any hope of fixing the compile
>> errors in ruby/typemaps.i? That seems like the "right" solution.
>Fair enough, I agree with your rationale. There's no chance I can fix
>it, but every chance someone else here can ;)
>
>If SWIG's 'typemap.i'file' is properly %included, it includes SWIG
>'file.i', which starts with
>
>#ifdef __cplusplus
>extern "C" {
>#endif
>#include "rubyio.h"
>#ifdef __cplusplus
>}
>#endif
>
This is a fairly standard approach for being able to link C++ code to 
compiled C functions.  Where it is embedded in C/C++ code, when the 
preprocessor detects that this source is being compiled as C++ (via the 
__cplusplus symbol0, the contents of rubio.h are bracketed by:

extern "C" {
...
}

This allows functions declared in this .h file to be known as C 
functions, and callable from the C++.

>This turns up in App.cpp (for example), and causes the compile to fail
>with a lot of errors like:
>
>/usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:30: error: parse error
>   before `(' token
>In file included from src/App.cpp:1591:
>/usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:30:46: pasting "L"
>and "(" does not give a valid preprocessing token
>/usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:64: error: syntax
>error
>   before `(' token
>/usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:64:44: pasting "L"
>and "(" does not give a valid preprocessing token
>/usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:65: error: syntax
>error
>   before `(' token
>
The message about "L(" being an invalid token seems correct to me; and I 
don't see how the extern "C" ... above could cause this, other than 
letting the build process continue until it hits this problem.  (On the 
face of it, a macro token pasting one.)

Not much, I know, but HTH.

Regards,

Alec
-- 
Alec Ross

From robin at nibor.org  Fri Apr 14 09:56:42 2006
From: robin at nibor.org (Robin Stocker)
Date: Fri, 14 Apr 2006 15:56:42 +0200
Subject: [Wxruby-users] *OUTPUT/*INPUT typemaps
In-Reply-To: <443F6ECD.3040007@pressure.to>
References: <443CFDDC.9050009@pressure.to>	<1144982910.18295.17.camel@localhost.localdomain>
	<443F6ECD.3040007@pressure.to>
Message-ID: <443FAA1A.30807@nibor.org>

Alex Fenton wrote:
> If SWIG's 'typemap.i'file' is properly %included, it includes SWIG 
> 'file.i', which starts with
> 
> #ifdef __cplusplus
> extern "C" {
> #endif
> #include "rubyio.h"
> #ifdef __cplusplus
> }
> #endif
> 
> This turns up in App.cpp (for example), and causes the compile to fail 
> with a lot of errors like:
> 
> /usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:30: error: parse error
>    before `(' token
> In file included from src/App.cpp:1591:
> /usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:30:46: pasting "L" 
> and "(" does not give a valid preprocessing token
> /usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:64: error: syntax 
> error
>    before `(' token
> /usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:64:44: pasting "L" 
> and "(" does not give a valid preprocessing token
> /usr/local/lib/ruby/1.8/powerpc-darwin7.9.0/rubyio.h:65: error: syntax 
> error
>    before `(' token
> 
> cheers
> alex

Maybe the _ macro isn't defined like it should be. Could you try a 
#include "defines.h" before #include "rubyio.h" in file.i?

   Robin Stocker

From roffe at extern.uio.no  Sat Apr 15 04:27:18 2006
From: roffe at extern.uio.no (=?iso-8859-1?Q?Rolf_Marvin_B=F8e_Lindgren?=)
Date: Sat, 15 Apr 2006 10:27:18 +0200
Subject: [Wxruby-users] Further problems with rubyt2 on MacOS X (intel)
Message-ID: <lbz3bgf2qhl.fsf@klodrik.uio.no>

List,

I'm trying to build wxRuby on MacOS X 10.4.6 (intel).  I've come across
some of the problems mentioned on the list, i.e. the RubyConstant issue
and the "id" keyword conflict issue.  however somethings's happening
that as far as I can see has not been mentioned on the list.  here's the
first few lines of the build fail report:



------------------------------------------------------------------------
./rake/rakelinux.rb:16: warning: global variable `$link_wx_statically' not initialized
g++  -c -I/usr/lib/wx/include/mac-ansi-release-2.6 -I/usr/include/wx-2.6 -D__WXMAC__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DNO_GCC_PRAGMA  -g -O2  -fno-common -pipe -fno-common -Wno-unused-function  -I /usr/lib/ruby/site_ruby/1.8 -I /usr/lib/ruby/site_ruby/1.8/i686-darwin8.6.1 -I /usr/lib/ruby/site_ruby -I /usr/lib/ruby/1.8 -I /usr/lib/ruby/1.8/i686-darwin8.6.1 -I . -o obj/Mac.o src/Mac.cpp 
(in /usr/local/src/wxruby-cvs/wxruby2)
In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:12,
                 from /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12,
                 from src/Mac.cpp:1596:
/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:60: error: stray '@' in program
In file included from /System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:6,
                 from /System/Library/Frameworks/Foundation.framework/Headers/NSAffineTransform.h:8,
                 from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:13,
------------------------------------------------------------------------

NSObjCRuntime.h, around line 60, reads:
------------------------------------------------------------------------
#define NSFoundationVersionNumber10_3_2 500.3
#define NSFoundationVersionNumber10_3_3 500.54
#define NSFoundationVersionNumber10_3_4 500.56

@class NSString;

FOUNDATION_EXPORT NSString *NSStringFromSelector(SEL aSelector);
FOUNDATION_EXPORT SEL NSSelectorFromString(NSString *aSelectorName);
FOUNDATION_EXPORT Class NSClassFromString(NSString *aClassName);
------------------------------------------------------------------------

any suggestions?

thank you,

-- 
Rolf Lindgren                                            http://www.roffe.com/
roffe at extern.uio.no                                      http://www.dignus.no/

From alex at pressure.to  Sat Apr 15 07:17:55 2006
From: alex at pressure.to (Alex Fenton)
Date: Sat, 15 Apr 2006 12:17:55 +0100
Subject: [Wxruby-users] *OUTPUT/*INPUT typemaps
In-Reply-To: <443FAA1A.30807@nibor.org>
References: <443CFDDC.9050009@pressure.to>	<1144982910.18295.17.camel@localhost.localdomain>	<443F6ECD.3040007@pressure.to>
	<443FAA1A.30807@nibor.org>
Message-ID: <4440D663.4020308@pressure.to>

Robin, Alec, thanks for the suggestions - I don't know c++ so no 
insight's too obvious.

Robin Stocker wrote:
> Maybe the _ macro isn't defined like it should be. Could you try a 
> #include "defines.h" before #include "rubyio.h" in file.i?
>   
I just tried adding #include "defines.h" to file.i, but the compile 
still fails with the same error. I've posted a query to SWIG mailing 
list to see if this looks familiar to anyone there.

alex


From alex at pressure.to  Sat Apr 15 07:32:23 2006
From: alex at pressure.to (Alex Fenton)
Date: Sat, 15 Apr 2006 12:32:23 +0100
Subject: [Wxruby-users] *OUTPUT/*INPUT typemaps
In-Reply-To: <443FAA1A.30807@nibor.org>
References: <443CFDDC.9050009@pressure.to>	<1144982910.18295.17.camel@localhost.localdomain>	<443F6ECD.3040007@pressure.to>
	<443FAA1A.30807@nibor.org>
Message-ID: <4440D9C7.9090008@pressure.to>


> Maybe the _ macro isn't defined like it should be. 
>   
I don't know if this has anything to do with it, but WxWidgets includes 
a _ macro for internationalisation

http://www.wxwidgets.org/manuals/2.6.3/wx_stringfunctions.html#underscore

alex

From roys at mindspring.com  Mon Apr 17 00:42:46 2006
From: roys at mindspring.com (Roy Sutton)
Date: Mon, 17 Apr 2006 00:42:46 -0400
Subject: [Wxruby-users] SWIG -autorename
Message-ID: <44431CC6.2000308@mindspring.com>

 From the SWIG manual:

-------8<---------------

SWIG 1.3.28 introduces the new -autorename command line parameter. When 
this parameter is specified, SWIG will automatically change constant, 
class and method names to conform with the standard Ruby naming 
conventions. ...

To disable renaming use the -noautorename command line option.

Since this change significantly changes the wrapper code generated by 
SWIG, it is turned off by default in SWIG 1.3.28. However, it is planned 
to become the default option in future releases.

-------8<---------------

I haven't tested how this does renaming but it may free us from parts of 
our rename script.  Also, we will, at the least, have to use the 
-noautorename flag if we don't wish to use SWIG's renamer.  Thoughts?

Roy

From wxruby at qualitycode.com  Mon Apr 17 01:54:02 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Mon, 17 Apr 2006 01:54:02 -0400
Subject: [Wxruby-users] Quick status report
Message-ID: <1145253242.9612.21.camel@localhost.localdomain>

Hi all,

I spent about 8 more hours tonight, and I think I'm close to having a
wxruby2 build that works with wxWidgets 2.6.3 and SWIG 1.3.29. It should
run bigdemo as well as the other samples. Unfortunately, I probably
won't have much time to work on it until next weekend :-(

Tonight's frustration was with wxART_INFORMATION. It's sort of a wxArtID
and sort of a wxString. I finally(!) got the generated C++ code to look
pretty good, but it segfaults deep within the wx code. So for now I plan
to disable wxArtProvider#get_icon and #get_bitmap, and comment those
calls out in the controls.rb sample.

One other quirk: In bigdemo, my splitter is stuck at the top of the
right pane. I think I saw this before (months ago), and can't remember
what caused it. I think I found a solution back then. If anyone knows
the answer, it will save me a visit to the mailing list archives.

Kevin

P.S. I wish we had an RCS that allowed easy branching so I could publish
my not-quite-working code in case anyone wanted to play with it. I'm
just not comfortable branching in CVS for something like this.



From roys at mindspring.com  Mon Apr 17 02:10:28 2006
From: roys at mindspring.com (Roy Sutton)
Date: Mon, 17 Apr 2006 02:10:28 -0400
Subject: [Wxruby-users] Quick status report
In-Reply-To: <1145253242.9612.21.camel@localhost.localdomain>
References: <1145253242.9612.21.camel@localhost.localdomain>
Message-ID: <44433154.4070305@mindspring.com>

I'm certainly interested in taking a look at what you've got.  I've been 
working a bit more on things and just started adding %predicate and 
%alias to some of the .i files so that we have a more rubyish interface 
to wx.  However, I don't see any reason for you to fork things just for 
that.  I think we'll all be happier when we've got a baseline checked 
into the RCS that we can begin working from again.

Roy

Kevin Smith wrote:
> Hi all,
>
> I spent about 8 more hours tonight, and I think I'm close to having a
> wxruby2 build that works with wxWidgets 2.6.3 and SWIG 1.3.29. It should
> run bigdemo as well as the other samples. Unfortunately, I probably
> won't have much time to work on it until next weekend :-(
>
> Tonight's frustration was with wxART_INFORMATION. It's sort of a wxArtID
> and sort of a wxString. I finally(!) got the generated C++ code to look
> pretty good, but it segfaults deep within the wx code. So for now I plan
> to disable wxArtProvider#get_icon and #get_bitmap, and comment those
> calls out in the controls.rb sample.
>
> One other quirk: In bigdemo, my splitter is stuck at the top of the
> right pane. I think I saw this before (months ago), and can't remember
> what caused it. I think I found a solution back then. If anyone knows
> the answer, it will save me a visit to the mailing list archives.
>
> Kevin
>
> P.S. I wish we had an RCS that allowed easy branching so I could publish
> my not-quite-working code in case anyone wanted to play with it. I'm
> just not comfortable branching in CVS for something like this.
>
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>
>   

From wxruby at qualitycode.com  Mon Apr 17 18:37:24 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Mon, 17 Apr 2006 18:37:24 -0400
Subject: [Wxruby-users] Further problems with rubyt2 on MacOS X (intel)
In-Reply-To: <lbz3bgf2qhl.fsf@klodrik.uio.no>
References: <lbz3bgf2qhl.fsf@klodrik.uio.no>
Message-ID: <1145313444.8433.83.camel@localhost.localdomain>

On Sat, 2006-04-15 at 10:27 +0200, Rolf Marvin B?e Lindgren wrote:
> List,
> 
> I'm trying to build wxRuby on MacOS X 10.4.6 (intel).  

> #define NSFoundationVersionNumber10_3_4 500.56
> 
> @class NSString;
> 
> FOUNDATION_EXPORT NSString *NSStringFromSelector(SEL aSelector);

Hm. That certainly doesn't look like valid C++. I'm not a Mac guy, but
isn't Cocoa natively an Objective-C thing? Is that Objective-C code?

Hopefully one of the Mac folks on the list can be of more help.

Kevin



From curt.hibbs at gmail.com  Mon Apr 17 22:55:00 2006
From: curt.hibbs at gmail.com (Curt Hibbs)
Date: Mon, 17 Apr 2006 21:55:00 -0500
Subject: [Wxruby-users] Quick status report
In-Reply-To: <1145253242.9612.21.camel@localhost.localdomain>
References: <1145253242.9612.21.camel@localhost.localdomain>
Message-ID: <31d15f490604171955t3b194e1r2437cde7cd1c7163@mail.gmail.com>

On 4/17/06, Kevin Smith <wxruby at qualitycode.com> wrote:
>
> P.S. I wish we had an RCS that allowed easy branching so I could publish
> my not-quite-working code in case anyone wanted to play with it. I'm
> just not comfortable branching in CVS for something like this.
>

RubyForge now supports both Subversion and CVS. Tom Copeland can switch us
to a subversion repo (the conversion process saves all change history). I've
already done this with the one-click installer and instant rails -- it
worked beautifully.

Just make sure you've got everything checked in and sen Tom a note asking
for the conversion (or I can do it if you like).

Curt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20060417/02910026/attachment.htm 

From sean.m.long at gmail.com  Tue Apr 18 01:23:03 2006
From: sean.m.long at gmail.com (Sean Long)
Date: Mon, 17 Apr 2006 22:23:03 -0700
Subject: [Wxruby-users] Further problems with rubyt2 on MacOS X (intel)
In-Reply-To: <1145313444.8433.83.camel@localhost.localdomain>
References: <lbz3bgf2qhl.fsf@klodrik.uio.no>
	<1145313444.8433.83.camel@localhost.localdomain>
Message-ID: <c2cd0d1d0604172223l6ca12050keb448b3c076d1517@mail.gmail.com>

I am guessing he has wxCocoa instead of wxMac installed.

to build wxMac (the version that uses Carbon and most stable) I do the
following:

download wxMac source
unzip
cd to the source dir
mkdir osx_build
cd osx_build
../configure --disable-shared  (if you need opengl or someother
nonstandard part of wxWidgets turn it on here)
make
sudo make install

as for wxRuby you will want to replace /powerpc-darwin/ with /darwin/
in rakeutil.rb in the rake dir.

Hope that helps.

Sean

On 4/17/06, Kevin Smith <wxruby at qualitycode.com> wrote:
> On Sat, 2006-04-15 at 10:27 +0200, Rolf Marvin B?e Lindgren wrote:
> > List,
> >
> > I'm trying to build wxRuby on MacOS X 10.4.6 (intel).
>
> > #define NSFoundationVersionNumber10_3_4 500.56
> >
> > @class NSString;
> >
> > FOUNDATION_EXPORT NSString *NSStringFromSelector(SEL aSelector);
>
> Hm. That certainly doesn't look like valid C++. I'm not a Mac guy, but
> isn't Cocoa natively an Objective-C thing? Is that Objective-C code?
>
> Hopefully one of the Mac folks on the list can be of more help.
>
> Kevin
>
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users


From roys at mindspring.com  Tue Apr 18 01:33:07 2006
From: roys at mindspring.com (Roy Sutton)
Date: Tue, 18 Apr 2006 01:33:07 -0400
Subject: [Wxruby-users] Update on SWIG
Message-ID: <44447A13.2050305@mindspring.com>

SWIG 1.3.29 isn't going to cut it for us.  We'll have to wait until 
1.3.30, unless I can hack together a nasty workaround for a problem with 
the object tracking.  It seem that each SWIG module gets its own hash 
for tracking objects.  This means that, for example, you create a find 
dialog (in FindReplaceDialog.cpp) events you get from it (from 
FindDialogEvent.cpp) won't be the same Ruby object, because those two 
modules don't share the same hash table.  We're getting painfully close 
now, though.  I think I know how this is supposed to work and will be 
able to have some things working soon.

The lack of unit tests is beginning to bug me.  I think I'll see if I 
can begin hooking in unit tests so we can start validating the new 
things we're doing.

Roy

From wxruby at qualitycode.com  Tue Apr 18 09:07:23 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Tue, 18 Apr 2006 09:07:23 -0400
Subject: [Wxruby-users] Update on SWIG
In-Reply-To: <44447A13.2050305@mindspring.com>
References: <44447A13.2050305@mindspring.com>
Message-ID: <1145365643.8433.11.camel@localhost.localdomain>

On Tue, 2006-04-18 at 01:33 -0400, Roy Sutton wrote:
> SWIG 1.3.29 isn't going to cut it for us.  We'll have to wait until 
> 1.3.30, unless I can hack together a nasty workaround for a problem with 
> the object tracking.  

Ugh. If true, it sounds like I shouldn't check in my current changes. Or
at least I should check in the wx 2.6.3 stuff, but not the swig 1.3.29
stuff. I don't suppose it's easy to disable the new swig memory tracking
code.

> It seem that each SWIG module gets its own hash 
> for tracking objects.  

Hm. I sure wish SWIG would support multiple-module linking. We could
give in to swig's wishes and cram every wx .i file into one single .cpp
file. It would be a huge file (maybe 300k?) that would take forever to
compile. But it would avoid one of our post-processing steps.

Can you point to the swig code in question? So far I've been pretty
successful at finding inexpensive ways to tweak the swig output to do
what we want.

> The lack of unit tests is beginning to bug me.  I think I'll see if I 
> can begin hooking in unit tests so we can start validating the new 
> things we're doing.

That would be fantastic!

Kevin



From wxruby at qualitycode.com  Tue Apr 18 09:12:32 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Tue, 18 Apr 2006 09:12:32 -0400
Subject: [Wxruby-users] Quick status report
In-Reply-To: <31d15f490604171955t3b194e1r2437cde7cd1c7163@mail.gmail.com>
References: <1145253242.9612.21.camel@localhost.localdomain>
	<31d15f490604171955t3b194e1r2437cde7cd1c7163@mail.gmail.com>
Message-ID: <1145365952.8433.17.camel@localhost.localdomain>

On Mon, 2006-04-17 at 21:55 -0500, Curt Hibbs wrote:
> RubyForge now supports both Subversion and CVS. 

Thanks for the reminder. I still view svn as "merely" an incremental
improvement over cvs, so I tend to forget that it's even an option. My
attention is on bzr (bazaar-ng) and other distributed RCS tools.

My hope is that wxruby can switch to a d-rcs system within the next year
or so. Since it is unlikely to happen within the next few months, it
might be worthwhile switching to svn for now, and switching again
later. 

Any strong opinions from the rest of you? Should we jump to svn now?

Kevin



From wxruby at qualitycode.com  Tue Apr 18 09:16:27 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Tue, 18 Apr 2006 09:16:27 -0400
Subject: [Wxruby-users] SWIG -autorename
In-Reply-To: <44431CC6.2000308@mindspring.com>
References: <44431CC6.2000308@mindspring.com>
Message-ID: <1145366187.8433.23.camel@localhost.localdomain>

On Mon, 2006-04-17 at 00:42 -0400, Roy Sutton wrote:
> I haven't tested how this does renaming but it may free us from parts of 
> our rename script.  Also, we will, at the least, have to use the 
> -noautorename flag if we don't wish to use SWIG's renamer.  Thoughts?

Hopefully their rules match ours. If so, it would probably work for us,
and we could get rid of our renamer.rb tool. I can't think of any
special cases that would hurt us, but I guess we'll have to try it to
know for sure.

Kevin



From roys at mindspring.com  Tue Apr 18 10:05:09 2006
From: roys at mindspring.com (Roy Sutton)
Date: Tue, 18 Apr 2006 10:05:09 -0400
Subject: [Wxruby-users] SWIG -autorename
In-Reply-To: <1145366187.8433.23.camel@localhost.localdomain>
References: <44431CC6.2000308@mindspring.com>
	<1145366187.8433.23.camel@localhost.localdomain>
Message-ID: <4444F214.5070406@mindspring.com>

Kevin Smith wrote:
> On Mon, 2006-04-17 at 00:42 -0400, Roy Sutton wrote:
>   
>> I haven't tested how this does renaming but it may free us from parts of 
>> our rename script.  Also, we will, at the least, have to use the 
>> -noautorename flag if we don't wish to use SWIG's renamer.  Thoughts?
>>     
>
> Hopefully their rules match ours. If so, it would probably work for us,
> and we could get rid of our renamer.rb tool. I can't think of any
> special cases that would hurt us, but I guess we'll have to try it to
> know for sure.
>   
I have been working with their renamer a bit.  It seems to do what ours 
do (at least for the cases I've tested so far).  I suppose I could write 
some tests to verify!  I was using it in conjunction with %predicate and 
%alias, which work pretty well.

Roy


From roys at mindspring.com  Tue Apr 18 10:13:14 2006
From: roys at mindspring.com (Roy Sutton)
Date: Tue, 18 Apr 2006 10:13:14 -0400
Subject: [Wxruby-users] Update on SWIG
In-Reply-To: <1145365643.8433.11.camel@localhost.localdomain>
References: <44447A13.2050305@mindspring.com>
	<1145365643.8433.11.camel@localhost.localdomain>
Message-ID: <4444F3FA.5010003@mindspring.com>

Kevin Smith wrote:
> On Tue, 2006-04-18 at 01:33 -0400, Roy Sutton wrote:
>   
>> SWIG 1.3.29 isn't going to cut it for us.  We'll have to wait until 
>> 1.3.30, unless I can hack together a nasty workaround for a problem with 
>> the object tracking.  
>>     
>
> Ugh. If true, it sounds like I shouldn't check in my current changes. Or
> at least I should check in the wx 2.6.3 stuff, but not the swig 1.3.29
> stuff. I don't suppose it's easy to disable the new swig memory tracking
> code.
>   
Object tracking is purely optional.  I am hacking around theirs with a 
bit of the fixmodules.rb magic.  However, it's not really how I want 
things done.
>> It seem that each SWIG module gets its own hash 
>> for tracking objects.  
>>     
>
> Hm. I sure wish SWIG would support multiple-module linking. We could
> give in to swig's wishes and cram every wx .i file into one single .cpp
> file. It would be a huge file (maybe 300k?) that would take forever to
> compile. But it would avoid one of our post-processing steps.
>
> Can you point to the swig code in question? So far I've been pretty
> successful at finding inexpensive ways to tweak the swig output to do
> what we want.
>   
The SWIG code in question is in rubytracking.swg.  swig_ruby_trackings 
and swig_ruby_hash_delete are static.  I also notified them of the 
swig_up 'bug' if you have multiple modules.  I don't think it is asking 
too much for multi-module support out of the box.  Of course, if they 
fix it, it'll break ours, but at least we might not have to have so many 
post-SWIG fixups.
>> The lack of unit tests is beginning to bug me.  I think I'll see if I 
>> can begin hooking in unit tests so we can start validating the new 
>> things we're doing.
>>     
>
> That would be fantastic!
>   
First test for getting the same object back you put in seems to be 
working!  One test down, ??? to go.
> Kevin
>   
Roy

From roys at mindspring.com  Tue Apr 18 10:26:58 2006
From: roys at mindspring.com (Roy Sutton)
Date: Tue, 18 Apr 2006 10:26:58 -0400
Subject: [Wxruby-users] Update on SWIG
In-Reply-To: <1145365643.8433.11.camel@localhost.localdomain>
References: <44447A13.2050305@mindspring.com>
	<1145365643.8433.11.camel@localhost.localdomain>
Message-ID: <4444F732.9010201@mindspring.com>

Kevin Smith wrote:
> Ugh. If true, it sounds like I shouldn't check in my current changes. Or
> at least I should check in the wx 2.6.3 stuff, but not the swig 1.3.29
> stuff.
What 1.3.29 specific stuff wouldn't be compatible with either future or 
past versions of SWIG?  I agree we need to 'drop anchor' on a SWIG 
version at some point. Object tracking looks to be implementable with 
external (to SWIG) changes and I think the upcoming changes to mark/free 
that Charlie Savage spoke of may be as well.  Can you drop your changes 
into an archive and either mail the list or place onto a Web site so I 
can take a look?

Roy

From sean.m.long at gmail.com  Tue Apr 18 11:12:56 2006
From: sean.m.long at gmail.com (Sean Long)
Date: Tue, 18 Apr 2006 08:12:56 -0700
Subject: [Wxruby-users] Quick status report
In-Reply-To: <1145365952.8433.17.camel@localhost.localdomain>
References: <1145253242.9612.21.camel@localhost.localdomain>
	<31d15f490604171955t3b194e1r2437cde7cd1c7163@mail.gmail.com>
	<1145365952.8433.17.camel@localhost.localdomain>
Message-ID: <c2cd0d1d0604180812i2bfa1429oc32fd03db9387c19@mail.gmail.com>

The only problem with Darcs right now is that the GHC compiler does
not work on Intel based Macs (which is my main home machine where I
work on wxRuby, if I have time). Hopefully the GHC group will get it
up and running soon so I can compile Darcs.

Sean

On 4/18/06, Kevin Smith <wxruby at qualitycode.com> wrote:
> On Mon, 2006-04-17 at 21:55 -0500, Curt Hibbs wrote:
> > RubyForge now supports both Subversion and CVS.
>
> Thanks for the reminder. I still view svn as "merely" an incremental
> improvement over cvs, so I tend to forget that it's even an option. My
> attention is on bzr (bazaar-ng) and other distributed RCS tools.
>
> My hope is that wxruby can switch to a d-rcs system within the next year
> or so. Since it is unlikely to happen within the next few months, it
> might be worthwhile switching to svn for now, and switching again
> later.
>
> Any strong opinions from the rest of you? Should we jump to svn now?
>
> Kevin
>
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>


From roys at mindspring.com  Tue Apr 18 22:14:54 2006
From: roys at mindspring.com (Roy Sutton)
Date: Tue, 18 Apr 2006 22:14:54 -0400
Subject: [Wxruby-users] Rubyfication of wxWindows
Message-ID: <44459D1E.4060201@mindspring.com>

As I posted to the list, at some point after we've fixed all the gaping 
huge holes we'll begin plastering over the rougher spots in wxRuby2.  I 
was giving some thoughts to predicate methods, of which there are quite 
a few in wxWindows.  My question is, how far from the wxWindows 
documentation do we want to move?  Do we want to have aliases for all 
renamed methods?

Example:


      wxPen::Ok

*bool* *Ok*() *const*

Returns true if the pen is initialised.


The 'correct' Ruby way to do this would be:   'ok?'   Should we also 
keep 'ok'?

Another example:


      wxCaret::IsOk

*bool* *IsOk*() *const*

Returns true if the caret was created successfully.

One possibly 'correct' Ruby way to do this, also, is:  'ok?'  Should we 
also have an 'is_ok?'  How about 'is_ok'?

There are quite a number of IsXxxx functions.

Roy

From wxruby at qualitycode.com  Wed Apr 19 09:06:36 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Wed, 19 Apr 2006 09:06:36 -0400
Subject: [Wxruby-users] Update on SWIG
In-Reply-To: <4444F732.9010201@mindspring.com>
References: <44447A13.2050305@mindspring.com>
	<1145365643.8433.11.camel@localhost.localdomain>
	<4444F732.9010201@mindspring.com>
Message-ID: <1145451996.8524.7.camel@localhost.localdomain>

On Tue, 2006-04-18 at 10:26 -0400, Roy Sutton wrote:
> What 1.3.29 specific stuff wouldn't be compatible with either future or 
> past versions of SWIG?  

All of our post-processing is fairly swig-version-specific. It's really
had to predict what might or might not work with any earlier or later
version of swig. It would have to be tested, and it's hard (and very
slow) to test multiple swig versions.

> Can you drop your changes 
> into an archive and either mail the list or place onto a Web site so I 
> can take a look?

Ok. I'll try to check it all in tonight. At least on my machine, it
compiles, and at least some of the samples run. They tend to crash
randomly, though, probably due to the object deletion tracking.

Kevin



From wxruby at qualitycode.com  Wed Apr 19 09:09:53 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Wed, 19 Apr 2006 09:09:53 -0400
Subject: [Wxruby-users] Rubyfication of wxWindows
In-Reply-To: <44459D1E.4060201@mindspring.com>
References: <44459D1E.4060201@mindspring.com>
Message-ID: <1145452193.8524.11.camel@localhost.localdomain>

On Tue, 2006-04-18 at 22:14 -0400, Roy Sutton wrote:
> My question is, how far from the wxWindows 
> documentation do we want to move?  Do we want to have aliases for all 
> renamed methods?
> 

I think it would be valuable to retain the complete set of original
methods, so people can use C++ or python wx docs and not have to guess
about what wxruby uses. 

>       wxCaret::IsOk
> 
> *bool* *IsOk*() *const*
> 
> Returns true if the caret was created successfully.
> 
> One possibly 'correct' Ruby way to do this, also, is:  'ok?'  Should we 
> also have an 'is_ok?'  How about 'is_ok'?
> 
> There are quite a number of IsXxxx functions.

My first reaction would be to have "is_ok" and "is_ok?". Presumably we
could automatically generate the ? versions with code.

Kevin



From roys at mindspring.com  Thu Apr 20 18:48:17 2006
From: roys at mindspring.com (Roy Sutton)
Date: Thu, 20 Apr 2006 18:48:17 -0400
Subject: [Wxruby-users] Update on SWIG
In-Reply-To: <1145451996.8524.7.camel@localhost.localdomain>
References: <44447A13.2050305@mindspring.com>	<1145365643.8433.11.camel@localhost.localdomain>	<4444F732.9010201@mindspring.com>
	<1145451996.8524.7.camel@localhost.localdomain>
Message-ID: <44480FB1.5030105@mindspring.com>

Any news on the checkin?

Roy

Kevin Smith wrote:
> On Tue, 2006-04-18 at 10:26 -0400, Roy Sutton wrote:
>   
>> What 1.3.29 specific stuff wouldn't be compatible with either future or 
>> past versions of SWIG?  
>>     
>
> All of our post-processing is fairly swig-version-specific. It's really
> had to predict what might or might not work with any earlier or later
> version of swig. It would have to be tested, and it's hard (and very
> slow) to test multiple swig versions.
>
>   
>> Can you drop your changes 
>> into an archive and either mail the list or place onto a Web site so I 
>> can take a look?
>>     
>
> Ok. I'll try to check it all in tonight. At least on my machine, it
> compiles, and at least some of the samples run. They tend to crash
> randomly, though, probably due to the object deletion tracking.
>
> Kevin
>
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>
>   

From wxruby at qualitycode.com  Thu Apr 20 22:29:39 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Thu, 20 Apr 2006 22:29:39 -0400
Subject: [Wxruby-users] Update on SWIG
In-Reply-To: <44480FB1.5030105@mindspring.com>
References: <44447A13.2050305@mindspring.com>
	<1145365643.8433.11.camel@localhost.localdomain>
	<4444F732.9010201@mindspring.com>
	<1145451996.8524.7.camel@localhost.localdomain>
	<44480FB1.5030105@mindspring.com>
Message-ID: <1145586580.8468.13.camel@localhost.localdomain>

On Thu, 2006-04-20 at 18:48 -0400, Roy Sutton wrote:
> Any news on the checkin?

:-)

Just before checking my email and finding your message, I finished the
checkin. I tagged it as 0.0.31, and noted in the README and Changelog
that it is VERY UNSTABLE.

The Changelog has a comprehensive list of all the changes I made to get
it to compile and somewhat work with wxWidgets 2.6.3 and SWIG 1.3.29.

Hopefully we can stabilize it quickly.

Kevin



From wxruby at qualitycode.com  Thu Apr 20 22:41:24 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Thu, 20 Apr 2006 22:41:24 -0400
Subject: [Wxruby-users] RubyConstants.i patch
In-Reply-To: <1144636516.8424.10.camel@localhost.localdomain>
References: <442B6F70.3030105@mindspring.com> <4433CA06.7090906@pressure.to>
	<1144636516.8424.10.camel@localhost.localdomain>
Message-ID: <1145587285.8468.15.camel@localhost.localdomain>

On Sun, 2006-04-09 at 22:35 -0400, Kevin Smith wrote:
> On Wed, 2006-04-05 at 14:45 +0100, Alex Fenton wrote:
> > I still get a compile error for the ART_ constants:
> > 
> > src/RubyConstants.cpp:3555: error: cannot convert `const wchar_t*' to 
> > `const
> >    char*' for argument `1' to `VALUE SWIG_FromCharPtr(const char*)'
> > 
> > I wonder if I'm seeing this because I'm using a unicode build of WxWidgets?
> 
> I saw the same problem. Changing those "char" to "wchar_t" fixed it. I
> haven't checked it in yet.

Just to follow up on this, my checkin tonight took a different approach.
See the Changelog.

Kevin



From roys at mindspring.com  Thu Apr 20 23:46:31 2006
From: roys at mindspring.com (Roy Sutton)
Date: Thu, 20 Apr 2006 23:46:31 -0400
Subject: [Wxruby-users] Update on SWIG
In-Reply-To: <1145586580.8468.13.camel@localhost.localdomain>
References: <44447A13.2050305@mindspring.com>	<1145365643.8433.11.camel@localhost.localdomain>	<4444F732.9010201@mindspring.com>	<1145451996.8524.7.camel@localhost.localdomain>	<44480FB1.5030105@mindspring.com>
	<1145586580.8468.13.camel@localhost.localdomain>
Message-ID: <44485597.6030208@mindspring.com>

Great work, Kevin!  I'm compiling now and it looks good except for one 
thing:  TextCtrl doesn't have a function called overflow (on Windows).  
I will submit a patch with that removed shortly if everything else 
compiles OK.

Roy

Kevin Smith wrote:
> On Thu, 2006-04-20 at 18:48 -0400, Roy Sutton wrote:
>   
>> Any news on the checkin?
>>     
>
> :-)
>
> Just before checking my email and finding your message, I finished the
> checkin. I tagged it as 0.0.31, and noted in the README and Changelog
> that it is VERY UNSTABLE.
>
> The Changelog has a comprehensive list of all the changes I made to get
> it to compile and somewhat work with wxWidgets 2.6.3 and SWIG 1.3.29.
>
> Hopefully we can stabilize it quickly.
>
> Kevin
>
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>
>   

From sean.m.long at gmail.com  Thu Apr 20 23:49:56 2006
From: sean.m.long at gmail.com (Sean Long)
Date: Thu, 20 Apr 2006 20:49:56 -0700
Subject: [Wxruby-users] Update on SWIG
In-Reply-To: <44485597.6030208@mindspring.com>
References: <44447A13.2050305@mindspring.com>
	<1145365643.8433.11.camel@localhost.localdomain>
	<4444F732.9010201@mindspring.com>
	<1145451996.8524.7.camel@localhost.localdomain>
	<44480FB1.5030105@mindspring.com>
	<1145586580.8468.13.camel@localhost.localdomain>
	<44485597.6030208@mindspring.com>
Message-ID: <c2cd0d1d0604202049j640a7f4m93afb3cf0c6886cf@mail.gmail.com>

I ran into that the TextCtrl overflow problem compiling on Mac OS X, I
only have wx2.6.2 installed and thought that was the problem. Going to
install wx2.6.3 before testing it again.

Sean

On 4/20/06, Roy Sutton <roys at mindspring.com> wrote:
> Great work, Kevin!  I'm compiling now and it looks good except for one
> thing:  TextCtrl doesn't have a function called overflow (on Windows).
> I will submit a patch with that removed shortly if everything else
> compiles OK.
>
> Roy
>
> Kevin Smith wrote:
> > On Thu, 2006-04-20 at 18:48 -0400, Roy Sutton wrote:
> >
> >> Any news on the checkin?
> >>
> >
> > :-)
> >
> > Just before checking my email and finding your message, I finished the
> > checkin. I tagged it as 0.0.31, and noted in the README and Changelog
> > that it is VERY UNSTABLE.
> >
> > The Changelog has a comprehensive list of all the changes I made to get
> > it to compile and somewhat work with wxWidgets 2.6.3 and SWIG 1.3.29.
> >
> > Hopefully we can stabilize it quickly.
> >
> > Kevin
> >
> >
> > _______________________________________________
> > wxruby-users mailing list
> > wxruby-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/wxruby-users
> >
> >
> >
> >
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>


From roys at mindspring.com  Thu Apr 20 23:52:23 2006
From: roys at mindspring.com (Roy Sutton)
Date: Thu, 20 Apr 2006 23:52:23 -0400
Subject: [Wxruby-users] Update on SWIG
In-Reply-To: <1145586580.8468.13.camel@localhost.localdomain>
References: <44447A13.2050305@mindspring.com>	<1145365643.8433.11.camel@localhost.localdomain>	<4444F732.9010201@mindspring.com>	<1145451996.8524.7.camel@localhost.localdomain>	<44480FB1.5030105@mindspring.com>
	<1145586580.8468.13.camel@localhost.localdomain>
Message-ID: <444856F7.9090704@mindspring.com>

Hmm, it also fails to link.  It appears to be pulling in the ruby 
tracking code even though I did not yet re-add the %trackobjects to any 
SWIG files.  Curiouser and curiouser.  I have a patch to the cleanup 
file which can fix the trackobjects.

Roy

Kevin Smith wrote:
> On Thu, 2006-04-20 at 18:48 -0400, Roy Sutton wrote:
>   
>> Any news on the checkin?
>>     
>
> :-)
>
> Just before checking my email and finding your message, I finished the
> checkin. I tagged it as 0.0.31, and noted in the README and Changelog
> that it is VERY UNSTABLE.
>
> The Changelog has a comprehensive list of all the changes I made to get
> it to compile and somewhat work with wxWidgets 2.6.3 and SWIG 1.3.29.
>
> Hopefully we can stabilize it quickly.
>
> Kevin
>
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>
>   

From wxruby at qualitycode.com  Fri Apr 21 09:09:40 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Fri, 21 Apr 2006 09:09:40 -0400
Subject: [Wxruby-users] Update on SWIG
In-Reply-To: <c2cd0d1d0604202049j640a7f4m93afb3cf0c6886cf@mail.gmail.com>
References: <44447A13.2050305@mindspring.com>
	<1145365643.8433.11.camel@localhost.localdomain>
	<4444F732.9010201@mindspring.com>
	<1145451996.8524.7.camel@localhost.localdomain>
	<44480FB1.5030105@mindspring.com>
	<1145586580.8468.13.camel@localhost.localdomain>
	<44485597.6030208@mindspring.com>
	<c2cd0d1d0604202049j640a7f4m93afb3cf0c6886cf@mail.gmail.com>
Message-ID: <1145624980.8431.9.camel@localhost.localdomain>

I forgot to mention that I'm targeting wx unicode myself. I assume we
also want it to work with non-unicode builds, but I think unicode is
preferred.

This weekend, I'm hoping to apply the dangling patches that have come in
over the last few months (like /darwin/ in the rakefile). So if y'all
(Roy and Sean) could submit any new patches soon, that would be great.
I'll take them in darcs or diff/patch format, or even just as a
description in English ("I removed the Xxx method").

Kevin


On Thu, 2006-04-20 at 20:49 -0700, Sean Long wrote:
> I ran into that the TextCtrl overflow problem compiling on Mac OS X, I
> only have wx2.6.2 installed and thought that was the problem. Going to
> install wx2.6.3 before testing it again.
> 
> Sean
> 
> On 4/20/06, Roy Sutton <roys at mindspring.com> wrote:
> > Great work, Kevin!  I'm compiling now and it looks good except for one
> > thing:  TextCtrl doesn't have a function called overflow (on Windows).
> > I will submit a patch with that removed shortly if everything else
> > compiles OK.
> >
> > Roy
> >
> > Kevin Smith wrote:
> > > On Thu, 2006-04-20 at 18:48 -0400, Roy Sutton wrote:
> > >
> > >> Any news on the checkin?
> > >>
> > >
> > > :-)
> > >
> > > Just before checking my email and finding your message, I finished the
> > > checkin. I tagged it as 0.0.31, and noted in the README and Changelog
> > > that it is VERY UNSTABLE.
> > >
> > > The Changelog has a comprehensive list of all the changes I made to get
> > > it to compile and somewhat work with wxWidgets 2.6.3 and SWIG 1.3.29.
> > >
> > > Hopefully we can stabilize it quickly.
> > >
> > > Kevin
> > >
> > >
> > > _______________________________________________
> > > wxruby-users mailing list
> > > wxruby-users at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/wxruby-users
> > >
> > >
> > >
> > >
> > _______________________________________________
> > wxruby-users mailing list
> > wxruby-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/wxruby-users
> >
> 
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users


From sean.m.long at gmail.com  Fri Apr 21 11:19:59 2006
From: sean.m.long at gmail.com (Sean Long)
Date: Fri, 21 Apr 2006 08:19:59 -0700
Subject: [Wxruby-users] Update on SWIG
In-Reply-To: <1145624980.8431.9.camel@localhost.localdomain>
References: <44447A13.2050305@mindspring.com>
	<1145365643.8433.11.camel@localhost.localdomain>
	<4444F732.9010201@mindspring.com>
	<1145451996.8524.7.camel@localhost.localdomain>
	<44480FB1.5030105@mindspring.com>
	<1145586580.8468.13.camel@localhost.localdomain>
	<44485597.6030208@mindspring.com>
	<c2cd0d1d0604202049j640a7f4m93afb3cf0c6886cf@mail.gmail.com>
	<1145624980.8431.9.camel@localhost.localdomain>
Message-ID: <c2cd0d1d0604210819s4a856bafr3601c5f95f2beb1e@mail.gmail.com>

Here is the first one in english:

in rakeutil.rb
change:
$macosx = /powerpc-darwin/ =~ RUBY_PLATFORM
to:
$macosx = /darwin/ =~ RUBY_PLATFORM

and then Mac OS X will be detected on PPC and Intel Macs

Sean

On 4/21/06, Kevin Smith <wxruby at qualitycode.com> wrote:
> I forgot to mention that I'm targeting wx unicode myself. I assume we
> also want it to work with non-unicode builds, but I think unicode is
> preferred.
>
> This weekend, I'm hoping to apply the dangling patches that have come in
> over the last few months (like /darwin/ in the rakefile). So if y'all
> (Roy and Sean) could submit any new patches soon, that would be great.
> I'll take them in darcs or diff/patch format, or even just as a
> description in English ("I removed the Xxx method").
>
> Kevin
>
>
> On Thu, 2006-04-20 at 20:49 -0700, Sean Long wrote:
> > I ran into that the TextCtrl overflow problem compiling on Mac OS X, I
> > only have wx2.6.2 installed and thought that was the problem. Going to
> > install wx2.6.3 before testing it again.
> >
> > Sean
> >
> > On 4/20/06, Roy Sutton <roys at mindspring.com> wrote:
> > > Great work, Kevin!  I'm compiling now and it looks good except for one
> > > thing:  TextCtrl doesn't have a function called overflow (on Windows).
> > > I will submit a patch with that removed shortly if everything else
> > > compiles OK.
> > >
> > > Roy
> > >
> > > Kevin Smith wrote:
> > > > On Thu, 2006-04-20 at 18:48 -0400, Roy Sutton wrote:
> > > >
> > > >> Any news on the checkin?
> > > >>
> > > >
> > > > :-)
> > > >
> > > > Just before checking my email and finding your message, I finished the
> > > > checkin. I tagged it as 0.0.31, and noted in the README and Changelog
> > > > that it is VERY UNSTABLE.
> > > >
> > > > The Changelog has a comprehensive list of all the changes I made to get
> > > > it to compile and somewhat work with wxWidgets 2.6.3 and SWIG 1.3.29.
> > > >
> > > > Hopefully we can stabilize it quickly.
> > > >
> > > > Kevin
> > > >
> > > >
> > > > _______________________________________________
> > > > wxruby-users mailing list
> > > > wxruby-users at rubyforge.org
> > > > http://rubyforge.org/mailman/listinfo/wxruby-users
> > > >
> > > >
> > > >
> > > >
> > > _______________________________________________
> > > wxruby-users mailing list
> > > wxruby-users at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/wxruby-users
> > >
> >
> > _______________________________________________
> > wxruby-users mailing list
> > wxruby-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/wxruby-users
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>


From alec at arlross.demon.co.uk  Sat Apr 22 17:16:48 2006
From: alec at arlross.demon.co.uk (Alec Ross)
Date: Sat, 22 Apr 2006 22:16:48 +0100
Subject: [Wxruby-users] Further problems with rubyt2 on MacOS X (intel)
In-Reply-To: <1145313444.8433.83.camel@localhost.localdomain>
References: <lbz3bgf2qhl.fsf@klodrik.uio.no>
	<1145313444.8433.83.camel@localhost.localdomain>
Message-ID: <HXxFpEAA1pSEFwK6@arlross.demon.co.uk>

In message <1145313444.8433.83.camel at localhost.localdomain>, Kevin Smith 
<wxruby at qualitycode.com> writes
>On Sat, 2006-04-15 at 10:27 +0200, Rolf Marvin B?e Lindgren wrote:
>> List,
>>
>> I'm trying to build wxRuby on MacOS X 10.4.6 (intel).

>> #define NSFoundationVersionNumber10_3_4 500.56

For C and C++, at least this looks as if it should be:

  #define NSFoundationVersionNumber 10_3_4 500.56

i.e. at least one item of white space    ^ here.

>>
>> @class NSString;
>>
>> FOUNDATION_EXPORT NSString *NSStringFromSelector(SEL aSelector);

>Hm. That certainly doesn't look like valid C++. I'm not a Mac guy, but
>isn't Cocoa natively an Objective-C thing? Is that Objective-C code?

>Hopefully one of the Mac folks on the list can be of more help.

>Kevin


>_______________________________________________
>wxruby-users mailing list
>wxruby-users at rubyforge.org
>http://rubyforge.org/mailman/listinfo/wxruby-users

-- 
Alec Ross


From roys at mindspring.com  Sat Apr 22 23:36:51 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sat, 22 Apr 2006 23:36:51 -0400
Subject: [Wxruby-users] StaticBoxSizer bug?
In-Reply-To: <200604230229.k3N2TIJb007312@gandalf.savarese.org>
References: <200604230229.k3N2TIJb007312@gandalf.savarese.org>
Message-ID: <444AF653.3060203@mindspring.com>

Daniel,

Thanks for the sample code.  Sizers do appear to have a problem and it's 
on the list to take a look at.  I'm currently reworking several classes 
and trying to fix some of the big compatibility bugs.  I will test your 
code with my latest builds but I don't think I've gotten to the sizers yet.

Roy

Daniel F. Savarese wrote:
> I've run into a disparity in the behavior of StaticBoxSizer between
> wxruby2 and straight C++ wxWindows or wxPython.  I've attached three
> equivalent test programs that place some text in a panel using a
> StaticBoxSizer to create a decorative rectangle around the text region.
> The C++ and wxPython programs create the desired result, with the
> StaticBox expanding to the available space in the window and adjusting
> as the window is resized.  In wxruby2, the StaticBox is displayed
> at its minimum size in the upper left hand corner of the window
> and does not resize.  I've tested all the programs on both Linux/GTK
> and Windows with the same results.  I've tried both an April 10th
> checkout of wxruby2 with SWIG 1.3.24 and the latest April 22nd
> checkout with SWIG 1.3.29 with the same result.
>
> After spending a lot of time assuming I was doing something wrong with
> either wxruby2 or the wxWindows API, I finally wrote the three
> test programs for comparison.  I've tried to find the source of the
> problem in wxruby2, but I've verified that the SWIG-generated code is
> calling StaticBoxSizer::Add with the proper parameter values.  I was
> hoping someone on the list might already be aware of the problem
> and point me to a workaround.  At the very least I figured I'd report
> the problem if it had not been identified previously.  I'll spend
> a bit more time trying to track down the source of the problem, but
> I bet it's something really obvious to someone with more experience
> than I at hacking the wxruby2 source.
>
> daniel
>
>   
> ------------------------------------------------------------------------
>
> #include <wx/wx.h>
>
> class SizerTestApp : public wxApp {
> public:
>   virtual bool OnInit();
> };
>
> class SizerTestFrame : public wxFrame {
> public:
>   SizerTestFrame(const wxString & title);
> };
>
> IMPLEMENT_APP(SizerTestApp);
>
> bool SizerTestApp::OnInit() {
>   SizerTestFrame *frame = new SizerTestFrame("Test");
>
>   frame->Show(true);
>
>   return true;
> }
>
> SizerTestFrame::SizerTestFrame(const wxString & title) :
>   wxFrame(NULL, wxID_ANY, title)
> {
>   wxPanel *panel       = new wxPanel(this, wxID_ANY);
>   wxBoxSizer *boxSizer = new wxBoxSizer(wxHORIZONTAL);
>   wxStaticBox *box     = new wxStaticBox(panel, wxID_ANY, wxT("BoxTitle"));
>   wxStaticText *text   = new wxStaticText(panel, wxID_ANY, wxT("Some text!"));
>   wxStaticBoxSizer *staticBoxSizer = new wxStaticBoxSizer(box, wxVERTICAL);
>
>   staticBoxSizer->Add(text, 1, wxEXPAND | wxALL, 16);
>   boxSizer->Add(staticBoxSizer, 1, wxEXPAND | wxALL, 16);
>   panel->SetSizerAndFit(boxSizer);
> }
>   
> ------------------------------------------------------------------------
>
> #!/usr/bin/env python
>
> from wxPython.wx import *
>
> class SizerTestFrame(wxFrame):
>   def __init__(self, parent, ID, title):
>     wxFrame.__init__(self, parent, ID, title)
>     panel    = wxPanel(self, wxID_ANY)
>     boxSizer = wxBoxSizer(wxHORIZONTAL)
>     box      = wxStaticBox(panel, wxID_ANY, "BoxTitle")
>     text     = wxStaticText(panel, wxID_ANY, "Some text!")
>     staticBoxSizer = wxStaticBoxSizer(box, wxVERTICAL)
>
>     staticBoxSizer.Add(text, 1, wxEXPAND | wxALL, 16)
>     boxSizer.Add(staticBoxSizer, 1, wxEXPAND | wxALL, 16)
>     panel.SetSizerAndFit(boxSizer)
>
> class SizerTestApp(wxApp):
>   def __init__( self  ):
>     wxApp.__init__( self )
>
>   def OnInit(self):
>     self.frame = SizerTestFrame(NULL, wxID_ANY, "Test")
>     self.frame.Show(true)
>     return true
>
> SizerTestApp().MainLoop()
>   
> ------------------------------------------------------------------------
>
> #!/usr/bin/env ruby
>
> require 'wx'
>
> class SizerTestFrame < Wx::Frame
>   def initialize(*args)
>     super(*args)
>
>     panel     = Wx::Panel.new(self, Wx::ID_ANY)
>     box_sizer = Wx::BoxSizer.new(Wx::HORIZONTAL)
>     box       = Wx::StaticBox.new(panel, Wx::ID_ANY, 'Box Title')
>     text      = Wx::StaticText.new(panel, Wx::ID_ANY, 'Some text!')
>     static_box_sizer = Wx::StaticBoxSizer.new(box, Wx::VERTICAL)
>
>     static_box_sizer.add(text, 1, Wx::EXPAND | Wx::ALL, 16)
>     box_sizer.add(static_box_sizer, 1, Wx::EXPAND | Wx::ALL, 16)
>     panel.set_sizer_and_fit(box_sizer)
>   end
> end
>
> class SizerTestApp < Wx::App
>   def on_init
>     frame = SizerTestFrame.new(nil, Wx::ID_ANY, 'Test')
>     frame.show
>   end
> end
>
> SizerTestApp.new.main_loop
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users

From roys at mindspring.com  Sun Apr 23 01:33:26 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sun, 23 Apr 2006 01:33:26 -0400
Subject: [Wxruby-users] Bigdemo Menu Demo
Message-ID: <444B11A6.8090109@mindspring.com>

Does anyone know how the wxMenu.rbw files was going to be competed?  I 
believe we have the code now to finish it off but I don't want to guess 
what the demo writer had in mind (though I think it's obvious).  
Specifically, it's the code that adds and removes menu items.

I've made some progress on other fronts:

o Test case for object tracking
o Object tracking enabled
o Fix to the Bigdemo Combo Box demo (fixed append to work (hopefully))
o Other minor changes

Some other problems I'm looking at:

o The gauge example crashes after running for some time
o The MDI sample doesn't work at all anymore
o GetTextExtent problem (double click on grid cell with text in it)
o Why don't drop down lists open up?
o The get_view_start problem (any bigdemo that uses the scrolled window)

For those interested I have made a Visual C++ 6.0 workspace/project file 
for wxRuby2.  Whether this was necessary or not I don't know but it 
allowed me to get debugging working so that I can step through the 
code.  This has sped up the debugging of problems immensely.

Roy

From roys at mindspring.com  Sun Apr 23 12:21:49 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sun, 23 Apr 2006 12:21:49 -0400
Subject: [Wxruby-users] UnregisterClass Error
Message-ID: <444BA99D.70503@mindspring.com>

Several of the problems I'm seeing result in a crash that gives the 
following error:

UnregisterClass error: _wx_SysTabCtl32

I haven't been able to track this down.  It may be a Windows specific 
problem, I don't know.  Has anyone else seen this?

Roy

From roys at mindspring.com  Sun Apr 23 13:08:55 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sun, 23 Apr 2006 13:08:55 -0400
Subject: [Wxruby-users] ComboBox patch files
Message-ID: <444BB4A7.9030100@mindspring.com>

The following two files correct problems with the ComboBox 
implementation.  You will also need my typemap.i.patch file 
(forthcoming) in order for the void * typemap to work properly (I think).

Roy
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: wxControlWithItems.h.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060423/bc5ef5a5/attachment.bat 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: wxComboBox.h.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060423/bc5ef5a5/attachment-0001.bat 

From roys at mindspring.com  Sun Apr 23 13:28:00 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sun, 23 Apr 2006 13:28:00 -0400
Subject: [Wxruby-users] Patches for object tracking
Message-ID: <444BB920.9050502@mindspring.com>

The following patches implement object tracking.  Note nasty games I 
play to make the tracking global.  SWIG 1.3.30 won't need this.  I also 
updated the minimum required SWIG version to 1.3.29.

Roy
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: typemap.i.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060423/ae0a5630/attachment-0004.bat 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fixmainmodule.rb.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060423/ae0a5630/attachment-0005.bat 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fixmodule.rb.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060423/ae0a5630/attachment-0006.bat 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rakewx.rb.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060423/ae0a5630/attachment-0007.bat 

From roys at mindspring.com  Sun Apr 23 13:34:37 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sun, 23 Apr 2006 13:34:37 -0400
Subject: [Wxruby-users] Fixes for ListControl
Message-ID: <444BBAAD.9050603@mindspring.com>

These patches fix the ListCtrl_virtual demo.  Note I changed the loading 
of the icon to the loading of a bitmap.  I remember discussing this 
before.  For some reason the .xpm loader isn't initialized properly for 
Wx::Icon.  However, the function will take a bitmap just fine so this 
works.  This also adds directors for wxListItem and wxListEvent

Roy
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: wxListItemAttr.h.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060423/7a8b85fb/attachment.bat 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: wxListCtrl.h.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060423/7a8b85fb/attachment-0001.bat 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: wxListCtrl_virtual.rbw.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060423/7a8b85fb/attachment-0002.bat 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: EvtHandler.i.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060423/7a8b85fb/attachment-0003.bat 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ListEvent.i
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060423/7a8b85fb/attachment-0004.bat 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ListItem.i
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060423/7a8b85fb/attachment-0005.bat 

From roys at mindspring.com  Sun Apr 23 13:37:29 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sun, 23 Apr 2006 13:37:29 -0400
Subject: [Wxruby-users] Patches for some object tracking
Message-ID: <444BBB59.5090105@mindspring.com>

The following two patches (theoretically) tell Ruby that it no longer 
owns menu items after they have been attached to a frame.  We'll need 
several more of these DISOWN typemaps as we get further into this.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Frame.i.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060423/430ef3a7/attachment.bat 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: MDIParentFrame.i.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060423/430ef3a7/attachment-0001.bat 

From roys at mindspring.com  Sun Apr 23 13:39:06 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sun, 23 Apr 2006 13:39:06 -0400
Subject: [Wxruby-users] wxTextCtr.h.patch
Message-ID: <444BBBBA.2010008@mindspring.com>

I think I had to do this to get the tarball to compile on Windows
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: wxTextCtrl.h.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060423/d1221341/attachment.bat 

From alex at pressure.to  Sun Apr 23 13:41:24 2006
From: alex at pressure.to (Alex Fenton)
Date: Sun, 23 Apr 2006 18:41:24 +0100
Subject: [Wxruby-users] *INPUT/*OUTPUT params patches
Message-ID: <444BBC44.5020303@pressure.to>

Hi

The attached patches enable the use of SWIG's *INPUT *OUTPUT and *INOUT 
typemaps as described in the manual. It's done by including SWIG's own 
'typemaps.i' file so it'll allow us to benefit from future upgrades to that.

The problem was a collision between a Ruby macro _ (fixing for old 
compilers) and a WxWidgets macro _ (for text translation) - which was 
undef'd anyway. Thanks for the hints that got me to this, eventually.

cheers
alex

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: common.i.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060423/f58d2951/attachment.bat 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: typemap.i.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060423/f58d2951/attachment-0001.bat 

From robin at nibor.org  Sun Apr 23 13:50:41 2006
From: robin at nibor.org (Robin Stocker)
Date: Sun, 23 Apr 2006 19:50:41 +0200
Subject: [Wxruby-users] wxTextCtr.h.patch
In-Reply-To: <444BBBBA.2010008@mindspring.com>
References: <444BBBBA.2010008@mindspring.com>
Message-ID: <444BBE71.2000801@nibor.org>

Roy Sutton wrote:
> I think I had to do this to get the tarball to compile on Windows

Yes, I also had to comment the overflow-line to be able to compile it on 
Mac OS X.

   Robin

From alex at pressure.to  Sun Apr 23 13:54:07 2006
From: alex at pressure.to (Alex Fenton)
Date: Sun, 23 Apr 2006 18:54:07 +0100
Subject: [Wxruby-users] Wx::Window#get_text_extent patch
Message-ID: <444BBF3F.2040602@pressure.to>

Here's a patch to fix Wx::Window#get_text_extent - it requires that the 
patches from teh last message are applied, to enable *INPUT etc typemaps.

Roy - though the function works correctly when called from Ruby, it 
still causes a crash when called internally when clicking on a Wx::Grid 
cell. Saw your message on SWIG mailing list, hopefully someone there can 
help out.

alex
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Window.i.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060423/c864bf3a/attachment.bat 

From roys at mindspring.com  Sun Apr 23 20:39:57 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sun, 23 Apr 2006 20:39:57 -0400
Subject: [Wxruby-users] Patch for wxToolBar.rbw
Message-ID: <444C1E5D.3050901@mindspring.com>

This patch fixes the toolbar in bigdemo
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: wxToolBar.rbw.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060423/2f42b087/attachment.bat 

From roys at mindspring.com  Mon Apr 24 00:00:27 2006
From: roys at mindspring.com (Roy Sutton)
Date: Mon, 24 Apr 2006 00:00:27 -0400
Subject: [Wxruby-users] StaticBoxSizer bug?
In-Reply-To: <200604240111.k3O1BgPK013682@gandalf.savarese.org>
References: <200604240111.k3O1BgPK013682@gandalf.savarese.org>
Message-ID: <444C4D5B.6060801@mindspring.com>

Daniel F. Savarese wrote:
> I'm not very intimate with SWIG, so it's taken me a lot longer to figure
> out what's going on than it would have otherwise.
Now you know how we all feel. :)
> After that, I realized the overridden virtual method was missing in
> wxStaticBoxSizer.h.  I've attached a patch.
>   
The patch didn't apply for me.  I have created a new patch for the two 
affected files.
> Now that I've spent enough time getting familiar with the way the
> code is generated, I'm left wondering if there's an alternative to
> maintaining custom wxFoo.h headers.  Is there a way to generate them
> from existing wxWidgets headers?  It seems error prone and a lot of
> work to maintain a separate set of headers.  I'm probably just
> revealing my general ignorance of SWIG.
As to the reason for the header files....  Well....  Perhaps Kevin can 
get into that some more.   SWIG is very good at certain things and it 
may even be able to do much of what's needed with the raw headers now.
> Is there a convention
> being used to decide which methods/constructors are included and
> which omitted?  For example, the second wxStaticBoxSizer constructor
> is omitted.  My guess was it might have something to do with memory
> allocation, so I didn't add it even though on the surface it worked.
> If there's some documentation about this sort of stuff, I'd appreciate
> any pointers so I can contribute conformant patches as I run into issues.
> I'll be brushing up on the SWIG manual too.
>   
I added in the 2nd constructor.  There's not much reason for it to be 
missing.  The SWIG manual only reveals its wisdom slowly. Good luck! :)

Roy
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: wxBoxSizer.h.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060424/13151f5e/attachment-0002.bat 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: wxStaticBoxSizer.h.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060424/13151f5e/attachment-0003.bat 

From robin at nibor.org  Mon Apr 24 17:50:25 2006
From: robin at nibor.org (Robin Stocker)
Date: Mon, 24 Apr 2006 23:50:25 +0200
Subject: [Wxruby-users] Summer of Code for wxRuby?
Message-ID: <444D4821.4000903@nibor.org>

Hi all,

You've probably heard of Google's Summer of Code. As this year Ruby 
Central is registered as a mentoring organisation, it is possible to do 
Ruby projects or work on existing ones, for example wxRuby :).

I would be interested to work on wxRuby as a student. So, my question 
is, are there tasks that need to be done and would be suitable for a 
Summer of Code project? If there are, who would be willing to be a 
mentor? The way I understand it, it would have to be someone who is 
familiar with the code and can give guidance and lend a hand.

What do you think?

   Robin Stocker

From wxruby at qualitycode.com  Mon Apr 24 20:30:10 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Mon, 24 Apr 2006 20:30:10 -0400
Subject: [Wxruby-users] Update on SWIG
In-Reply-To: <c2cd0d1d0604210819s4a856bafr3601c5f95f2beb1e@mail.gmail.com>
References: <44447A13.2050305@mindspring.com>
	<1145365643.8433.11.camel@localhost.localdomain>
	<4444F732.9010201@mindspring.com>
	<1145451996.8524.7.camel@localhost.localdomain>
	<44480FB1.5030105@mindspring.com>
	<1145586580.8468.13.camel@localhost.localdomain>
	<44485597.6030208@mindspring.com>
	<c2cd0d1d0604202049j640a7f4m93afb3cf0c6886cf@mail.gmail.com>
	<1145624980.8431.9.camel@localhost.localdomain>
	<c2cd0d1d0604210819s4a856bafr3601c5f95f2beb1e@mail.gmail.com>
Message-ID: <1145925011.25718.0.camel@localhost.localdomain>

On Fri, 2006-04-21 at 08:19 -0700, Sean Long wrote:
> Here is the first one in english:
> 
> in rakeutil.rb
> change:
> $macosx = /powerpc-darwin/ =~ RUBY_PLATFORM
> to:
> $macosx = /darwin/ =~ RUBY_PLATFORM
> 
> and then Mac OS X will be detected on PPC and Intel Macs

Checked in. Thanks.

Kevin



From wxruby at qualitycode.com  Mon Apr 24 20:36:24 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Mon, 24 Apr 2006 20:36:24 -0400
Subject: [Wxruby-users] Bigdemo Menu Demo
In-Reply-To: <444B11A6.8090109@mindspring.com>
References: <444B11A6.8090109@mindspring.com>
Message-ID: <1145925384.25718.4.camel@localhost.localdomain>

On Sun, 2006-04-23 at 01:33 -0400, Roy Sutton wrote:
> Does anyone know how the wxMenu.rbw files was going to be competed?  I 
> believe we have the code now to finish it off but I don't want to guess 
> what the demo writer had in mind (though I think it's obvious).  
> Specifically, it's the code that adds and removes menu items.

At this point, I think it's fine to guess. Or, better yet, just decide
what we (you) want it to do, and make it so.

> I've made some progress on other fronts:

Cool.

> Some other problems I'm looking at:
> 
> o The gauge example crashes after running for some time
> o The MDI sample doesn't work at all anymore
> o GetTextExtent problem (double click on grid cell with text in it)
> o Why don't drop down lists open up?
> o The get_view_start problem (any bigdemo that uses the scrolled window)

My problem at the moment is one I've seen before, but I can't remember
how I solved it back then. The splitter in the right panel is stuck at
the top, and resists being dragged down so all I can see is the debug
pane.

> For those interested I have made a Visual C++ 6.0 workspace/project file 
> for wxRuby2.  Whether this was necessary or not I don't know but it 
> allowed me to get debugging working so that I can step through the 
> code.  This has sped up the debugging of problems immensely.

Also cool. I would gladly check that in if it's general enough that
other folks could use it.

Kevin



From wxruby at qualitycode.com  Mon Apr 24 20:37:36 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Mon, 24 Apr 2006 20:37:36 -0400
Subject: [Wxruby-users] UnregisterClass Error
In-Reply-To: <444BA99D.70503@mindspring.com>
References: <444BA99D.70503@mindspring.com>
Message-ID: <1145925456.25718.6.camel@localhost.localdomain>

On Sun, 2006-04-23 at 12:21 -0400, Roy Sutton wrote:
> Several of the problems I'm seeing result in a crash that gives the 
> following error:
> 
> UnregisterClass error: _wx_SysTabCtl32
> 
> I haven't been able to track this down.  It may be a Windows specific 
> problem, I don't know.  Has anyone else seen this?

I haven't seen it, and it does look like a Windows-specific thing to me.
Both the SysTabCtl32 name, and the concept of "UnregisterClass". Of
course, I could be wrong.

Quite possible (likely?) that it's related to the general problem we're
having with memory management and frequent semi-random crashing.

Kevin



From wxruby at qualitycode.com  Mon Apr 24 21:10:18 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Mon, 24 Apr 2006 21:10:18 -0400
Subject: [Wxruby-users] Patches for object tracking
In-Reply-To: <444BB920.9050502@mindspring.com>
References: <444BB920.9050502@mindspring.com>
Message-ID: <1145927418.25718.17.camel@localhost.localdomain>

I'm reluctant to check these in, as they have made things distinctly
worse for me. These are the first patches I have tried to apply tonight,
and they make almost anything in bigdemo crash immediately. Here's the
stack trace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211263296 (LWP 27912)]
0xb7866816 in SWIG_Ruby_NewPointerObj (ptr=0xbfd556a0, type=0xb7c6d0a0,
flags=Variable "flags" is not available.
) at src/Button.cpp:1312
1312            if (strcmp(type->name, type_name) == 0) {
Current language:  auto; currently c++
(gdb) bt
#0  0xb7866816 in SWIG_Ruby_NewPointerObj (ptr=0xbfd556a0,
type=0xb7c6d0a0, flags=Variable "flags" is not available.
) at src/Button.cpp:1312
#1  0xb786d740 in SwigDirector_wxButton::ProcessEvent (this=0x82d2520,
event=@0xbfd556a0) at src/Button.cpp:3236
#2  0xb73c4581 in wxAppBase::SendIdleEvents (this=0x8122a28,
win=0x82d2520, event=@0xbfd556a0) at ../src/common/appcmn.cpp:431
#3  0xb73c45e5 in wxAppBase::SendIdleEvents (this=0x8122a28,
win=0x8226400, event=@0xbfd556a0) at ../src/common/appcmn.cpp:440
#4  0xb73c4456 in wxAppBase::ProcessIdle (this=0x8122a28)
at ../src/common/appcmn.cpp:406
#5  0xb731072e in wxapp_idle_callback () at ../src/gtk/app.cpp:281
#6  0xb69b5750 in g_child_watch_add () from /usr/lib/libglib-2.0.so.0
#7  0xb69b34ee in g_main_context_dispatch ()
from /usr/lib/libglib-2.0.so.0
#8  0xb69b64f6 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#9  0xb69b67e3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#10 0xb6d6ce65 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#11 0xb73311c0 in wxEventLoop::Run (this=0x82a0c88)
at ../src/gtk/evtloop.cpp:80
#12 0xb73c4123 in wxAppBase::MainLoop (this=0x8122a28)
at ../src/common/appcmn.cpp:272
#13 0xb73c42af in wxAppBase::OnRun (this=0x8122a28)
at ../src/common/appcmn.cpp:340
#14 0xb70c3441 in wxEntry (argc=@0xb7c6d3c8, argv=0xb7c6d3c0)
at ../src/common/init.cpp:439
#15 0xb784b558 in _wrap_App_main_loop (argc=0, argv=0x0,
self=3061730980) at src/App.cpp:1650
#16 0xb7e9264a in rb_iterator_p () from /usr/lib/libruby1.8.so.1.8
#17 0xb7e9d07c in rb_thread_trap_eval () from /usr/lib/libruby1.8.so.1.8
#18 0xb7e9db82 in rb_thread_trap_eval () from /usr/lib/libruby1.8.so.1.8
#19 0xb7e9a478 in rb_thread_trap_eval () from /usr/lib/libruby1.8.so.1.8
#20 0xb7ea7586 in rb_eval_string () from /usr/lib/libruby1.8.so.1.8
#21 0xb7ea75d6 in ruby_exec () from /usr/lib/libruby1.8.so.1.8
#22 0xb7ea9715 in ruby_run () from /usr/lib/libruby1.8.so.1.8
#23 0x080486ac in main ()


Any thoughts before I dive in and try to figure it out myself?

Kevin



On Sun, 2006-04-23 at 13:28 -0400, Roy Sutton wrote:
> The following patches implement object tracking.  Note nasty games I 
> play to make the tracking global.  SWIG 1.3.30 won't need this.  I also 
> updated the minimum required SWIG version to 1.3.29.
> 
> Roy



From wxruby at qualitycode.com  Mon Apr 24 21:15:21 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Mon, 24 Apr 2006 21:15:21 -0400
Subject: [Wxruby-users] Summer of Code for wxRuby?
In-Reply-To: <444D4821.4000903@nibor.org>
References: <444D4821.4000903@nibor.org>
Message-ID: <1145927721.25718.21.camel@localhost.localdomain>

On Mon, 2006-04-24 at 23:50 +0200, Robin Stocker wrote:
> I would be interested to work on wxRuby as a student. So, my question 
> is, are there tasks that need to be done and would be suitable for a 
> Summer of Code project? If there are, who would be willing to be a 
> mentor? The way I understand it, it would have to be someone who is 
> familiar with the code and can give guidance and lend a hand.

Hi,

I would be very willing to be a mentor for wxRuby work. 

There are so many things that wxRuby needs, but I'm not sure how well
they would fit into a specific TODO list. 

How comfortable are you with C++? Most of the current wxRuby problems
are cases where we are generating bad C++ code for some reason, so it
helps to be able to understand what's going wrong. You don't need to be
a C++ expert, but should understand basic C++.

Are you familiar with SWIG? Many of the "missing" wx methods are because
none of us have been familiar enough with SWIG to add them. Roy is now
stepping up in this area, which is great. I assume he would welcome
additional help.

There is also the "rubyified" API that we would like to see. The current
API is just a thin wrapper over the C++ API. A rubyish (and
higher-level) wrapper would be much more pleasant to work with. I always
use the example of how much nicer FXRuby is vs. plain FOX.

Another nice project would be to build a good unit test suite. I know
Roy is working on this also. I made an attempt many months ago, but
didn't get very far.

There's also building gems for wxruby, but hopefully that wouldn't take
a whole summer.

And, of course, we could always use better samples, and better user
documentation.

Kevin



From roys at mindspring.com  Mon Apr 24 22:14:23 2006
From: roys at mindspring.com (Roy Sutton)
Date: Mon, 24 Apr 2006 22:14:23 -0400
Subject: [Wxruby-users] Bigdemo Menu Demo
In-Reply-To: <1145925384.25718.4.camel@localhost.localdomain>
References: <444B11A6.8090109@mindspring.com>
	<1145925384.25718.4.camel@localhost.localdomain>
Message-ID: <444D85FF.6090203@mindspring.com>

Kevin Smith wrote:
> On Sun, 2006-04-23 at 01:33 -0400, Roy Sutton wrote:
>   
>> Does anyone know how the wxMenu.rbw files was going to be competed?  I 
>> believe we have the code now to finish it off but I don't want to guess 
>> what the demo writer had in mind (though I think it's obvious).  
>> Specifically, it's the code that adds and removes menu items.
>>     
>
> At this point, I think it's fine to guess. Or, better yet, just decide
> what we (you) want it to do, and make it so.
>   
If I get a chance I'll take a whack at it.
> My problem at the moment is one I've seen before, but I can't remember
> how I solved it back then. The splitter in the right panel is stuck at
> the top, and resists being dragged down so all I can see is the debug
> pane.
>   
Odd.  Don't see this on Windows, obviously.  Anyone see this elsewhere?
>> For those interested I have made a Visual C++ 6.0 workspace/project file 
> lso cool. I would gladly check that in if it's general enough that
> other folks could use it.
>   
Well...  I need to add the SWIG steps to it and update a few things.  
The only problem with the script is it's not quite as nice as the 
rakefile.  If I can write up docs on debugging without the project 
workspace then we might not need it.


Roy

From roys at mindspring.com  Mon Apr 24 22:57:19 2006
From: roys at mindspring.com (Roy Sutton)
Date: Mon, 24 Apr 2006 22:57:19 -0400
Subject: [Wxruby-users] Patches for object tracking
In-Reply-To: <1145927418.25718.17.camel@localhost.localdomain>
References: <444BB920.9050502@mindspring.com>
	<1145927418.25718.17.camel@localhost.localdomain>
Message-ID: <444D900F.3070705@mindspring.com>

Kevin Smith wrote:
> I'm reluctant to check these in, as they have made things distinctly
> worse for me. These are the first patches I have tried to apply tonight,
> and they make almost anything in bigdemo crash immediately. Here's the
> stack trace:
Wow.  On Windows I couldn't detect any differences between tracking and 
no tracking.  I have set up an Ubuntu box with the idea of checking out 
wxRuby on it (and also doing some Rails stuff), maybe it's time to try 
testing it there.  The box is at the office, though, so I don't get to 
work on it much.  Some days working on this stuff is like carving 
something out of wood and discovering a big rotted area beneath what 
looks like good wood.  I'm looking forward to the day when some change 
doesn't uncover a ton of other problems!

Roy

From roys at mindspring.com  Mon Apr 24 23:00:06 2006
From: roys at mindspring.com (Roy Sutton)
Date: Mon, 24 Apr 2006 23:00:06 -0400
Subject: [Wxruby-users] Summer of Code for wxRuby?
In-Reply-To: <1145927721.25718.21.camel@localhost.localdomain>
References: <444D4821.4000903@nibor.org>
	<1145927721.25718.21.camel@localhost.localdomain>
Message-ID: <444D90B6.1040107@mindspring.com>

Kevin Smith wrote:
> On Mon, 2006-04-24 at 23:50 +0200, Robin Stocker wrote:
>   
>> I would be interested to work on wxRuby as a student. So, my question 
>> is, are there tasks that need to be done and would be suitable for a 
>> Summer of Code project? If there are, who would be willing to be a 
>> mentor? The way I understand it, it would have to be someone who is 
>> familiar with the code and can give guidance and lend a hand.
>>     
>
> Hi,
>
> I would be very willing to be a mentor for wxRuby work. 
>
> There are so many things that wxRuby needs, but I'm not sure how well
> they would fit into a specific TODO list. 
>
> How comfortable are you with C++? Most of the current wxRuby problems
> are cases where we are generating bad C++ code for some reason, so it
> helps to be able to understand what's going wrong. You don't need to be
> a C++ expert, but should understand basic C++.
>
> Are you familiar with SWIG? Many of the "missing" wx methods are because
> none of us have been familiar enough with SWIG to add them. Roy is now
> stepping up in this area, which is great. I assume he would welcome
> additional help.
>
> There is also the "rubyified" API that we would like to see. The current
> API is just a thin wrapper over the C++ API. A rubyish (and
> higher-level) wrapper would be much more pleasant to work with. I always
> use the example of how much nicer FXRuby is vs. plain FOX.
>
> Another nice project would be to build a good unit test suite. I know
> Roy is working on this also. I made an attempt many months ago, but
> didn't get very far.
>
> There's also building gems for wxruby, but hopefully that wouldn't take
> a whole summer.
>
> And, of course, we could always use better samples, and better user
> documentation.
>   
I originally suggested wxRuby for the Summer of Code on the Ruby mailing 
list.  I think it would be great to get someone in here who can really 
focus on the issues that the rest of us are mostly dabbling at.  Kevin 
is right, though, that much of what we're knocking our heads against is 
C++, not Ruby.  The exciting stuff will be the ruby-style interface, 
however, the stability of wxRuby2 right now doesn't quite justify it.  
That said, I'm glad to help out anyone who wants to throw in a shoulder 
here.

Roy

From roys at mindspring.com  Mon Apr 24 23:07:36 2006
From: roys at mindspring.com (Roy Sutton)
Date: Mon, 24 Apr 2006 23:07:36 -0400
Subject: [Wxruby-users] -fvirtual and compactdefaultargs
 (was	StaticBoxSizer bug?)
In-Reply-To: <200604242112.k3OLCAT7032209@gandalf.savarese.org>
References: <200604242112.k3OLCAT7032209@gandalf.savarese.org>
Message-ID: <444D9278.7060106@mindspring.com>

Daniel F. Savarese wrote:
> In message <444C4D5B.6060801 at mindspring.com>, Roy Sutton writes:
>   
>> The patch didn't apply for me.  I have created a new patch for the two 
>> affected files.
>>     
>
> You probably needed a -p0 (assuming application from inside wxruby2/)
> or we had slightly different versions of the source files or maybe
> the .orig file suffix threw off your version of patch and it prefers
> the top-level directories to differ.  If the convention for wxruby2
> patch submissions is to generate them from a level above the source
> tree, I can do that in the future.  Is the mailing list the preferred
> patch submission medium?  I noticed that there's a little-used Patch
> category in the issue tracker.
>   
We've been using the mailing list.  We were working on getting a darcs 
repository going but I really don't recall now whether that's up and 
running (anyone?).

> How do people feel about adding -fvirtual to swig_options in
> rake/rakewx.rb to eliminate redundant wrapper generation?  I
> raise this question because prior to declaring RecalcSize() in the
> wxStaticBoxSizer.h, the wrapper generated for it in StaticBoxSizer.cpp
> was a redundant version of what was generated for BoxSizer.  Also, how
> about using %feature("compactdefaultargs") across the board (putting it
> in common.i) to reduce the library size?  It shaved off 700KB
> of object code for me.  For example, Sizer::Add went from having
> 18 wrapper functions to just 6.
>   
Hmm.  I will test all my samples.  I actually think "compactdefaultargs" 
will fix at least one bug (the listbox bug) in the SWIG wrappers.  I 
will do a complete rebuild and try each of these options.

Roy

From roys at mindspring.com  Tue Apr 25 00:47:22 2006
From: roys at mindspring.com (Roy Sutton)
Date: Tue, 25 Apr 2006 00:47:22 -0400
Subject: [Wxruby-users] Wx::Window#get_text_extent patch
In-Reply-To: <444BBF3F.2040602@pressure.to>
References: <444BBF3F.2040602@pressure.to>
Message-ID: <444DA9DA.5000309@mindspring.com>

Alex,

I meant to mention there are typemaps for that call in typemap.i.  
Perhaps we should update that one instead?

Roy

Alex Fenton wrote:
> Here's a patch to fix Wx::Window#get_text_extent - it requires that 
> the patches from teh last message are applied, to enable *INPUT etc 
> typemaps.
>
> Roy - though the function works correctly when called from Ruby, it 
> still causes a crash when called internally when clicking on a 
> Wx::Grid cell. Saw your message on SWIG mailing list, hopefully 
> someone there can help out.
>
> alex
> ------------------------------------------------------------------------
>
> Index: wxruby2/swig/classes/Window.i
> ===================================================================
> RCS file: /var/cvs/wxruby/wxruby2/swig/classes/Window.i,v
> retrieving revision 1.13
> diff -b -u -r1.13 Window.i
> --- wxruby2/swig/classes/Window.i	18 Sep 2005 17:08:05 -0000	1.13
> +++ wxruby2/swig/classes/Window.i	23 Apr 2006 17:45:00 -0000
> @@ -11,6 +11,10 @@
>  %ignore wxWindow::PopEventHandler;
>  # %ignore wxWindow::SetCaret;
>  
> +# For Wx::Window#get_text_extent
> +%apply int *OUTPUT { int*  x , int*  y , int*  descent, int*  externalLeading};
> +%apply wxFont *INPUT { const wxFont*  font };
> +
>  %rename(SetDimensions) wxWindow::SetSize(int  x , int  y , int  width , int  height , int sizeFlags = wxSIZE_AUTO) ;
>  
>  %{
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users

From alex at pressure.to  Tue Apr 25 03:23:09 2006
From: alex at pressure.to (Alex Fenton)
Date: Tue, 25 Apr 2006 08:23:09 +0100
Subject: [Wxruby-users] Wx::Window#get_text_extent patch
In-Reply-To: <444DA9DA.5000309@mindspring.com>
References: <444BBF3F.2040602@pressure.to> <444DA9DA.5000309@mindspring.com>
Message-ID: <444DCE5D.2000902@pressure.to>

Yep, I see DC and WindowDC have methods with the same or similar 
signatures - if it covers several classes it should live in typemap.i. 
I'll send in an updated patch.

thanks
alex



Roy Sutton wrote:
> Alex,
>
> I meant to mention there are typemaps for that call in typemap.i.  
> Perhaps we should update that one instead?
>
> Roy
>
> Alex Fenton wrote:
>   
>> Here's a patch to fix Wx::Window#get_text_extent - it requires that 
>> the patches from teh last message are applied, to enable *INPUT etc 
>> typemaps.
>>
>> Roy - though the function works correctly when called from Ruby, it 
>> still causes a crash when called internally when clicking on a 
>> Wx::Grid cell. Saw your message on SWIG mailing list, hopefully 
>> someone there can help out.
>>
>> alex
>> ------------------------------------------------------------------------
>>
>> Index: wxruby2/swig/classes/Window.i
>> ===================================================================
>> RCS file: /var/cvs/wxruby/wxruby2/swig/classes/Window.i,v
>> retrieving revision 1.13
>> diff -b -u -r1.13 Window.i
>> --- wxruby2/swig/classes/Window.i	18 Sep 2005 17:08:05 -0000	1.13
>> +++ wxruby2/swig/classes/Window.i	23 Apr 2006 17:45:00 -0000
>> @@ -11,6 +11,10 @@
>>  %ignore wxWindow::PopEventHandler;
>>  # %ignore wxWindow::SetCaret;
>>  
>> +# For Wx::Window#get_text_extent
>> +%apply int *OUTPUT { int*  x , int*  y , int*  descent, int*  externalLeading};
>> +%apply wxFont *INPUT { const wxFont*  font };
>> +
>>  %rename(SetDimensions) wxWindow::SetSize(int  x , int  y , int  width , int  height , int sizeFlags = wxSIZE_AUTO) ;
>>  
>>  %{
>>   
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> wxruby-users mailing list
>> wxruby-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wxruby-users
>>     
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>   


From alex at pressure.to  Tue Apr 25 05:11:48 2006
From: alex at pressure.to (Alex Fenton)
Date: Tue, 25 Apr 2006 10:11:48 +0100
Subject: [Wxruby-users] Wx::Window#get_text_extent patch
In-Reply-To: <444DA9DA.5000309@mindspring.com>
References: <444BBF3F.2040602@pressure.to> <444DA9DA.5000309@mindspring.com>
Message-ID: <444DE7D4.9080001@pressure.to>


> I meant to mention there are typemaps for that call in typemap.i.  
> Perhaps we should update that one instead?
>   
see attached


> Alex Fenton wrote:
>   
>> Here's a patch to fix Wx::Window#get_text_extent - it requires that 
>> the patches from teh last message are applied, to enable *INPUT etc 
>> typemaps.
>>
>> Roy - though the function works correctly when called from Ruby, it 
>> still causes a crash when called internally when clicking on a 
>> Wx::Grid cell. Saw your message on SWIG mailing list, hopefully 
>> someone there can help out.
>>
>> alex
>> ------------------------------------------------------------------------
>>
>> Index: wxruby2/swig/classes/Window.i
>> ===================================================================
>> RCS file: /var/cvs/wxruby/wxruby2/swig/classes/Window.i,v
>> retrieving revision 1.13
>> diff -b -u -r1.13 Window.i
>> --- wxruby2/swig/classes/Window.i	18 Sep 2005 17:08:05 -0000	1.13
>> +++ wxruby2/swig/classes/Window.i	23 Apr 2006 17:45:00 -0000
>> @@ -11,6 +11,10 @@
>>  %ignore wxWindow::PopEventHandler;
>>  # %ignore wxWindow::SetCaret;
>>  
>> +# For Wx::Window#get_text_extent
>> +%apply int *OUTPUT { int*  x , int*  y , int*  descent, int*  externalLeading};
>> +%apply wxFont *INPUT { const wxFont*  font };
>> +
>>  %rename(SetDimensions) wxWindow::SetSize(int  x , int  y , int  width , int  height , int sizeFlags = wxSIZE_AUTO) ;
>>  
>>  %{
>>   
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> wxruby-users mailing list
>> wxruby-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wxruby-users
>>     
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>   

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: typemap.i.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060425/2a96ed00/attachment.bat 

From robin at nibor.org  Tue Apr 25 18:00:29 2006
From: robin at nibor.org (Robin Stocker)
Date: Wed, 26 Apr 2006 00:00:29 +0200
Subject: [Wxruby-users] Summer of Code for wxRuby?
In-Reply-To: <1145927721.25718.21.camel@localhost.localdomain>
References: <444D4821.4000903@nibor.org>
	<1145927721.25718.21.camel@localhost.localdomain>
Message-ID: <444E9BFD.3000305@nibor.org>

Kevin Smith wrote:
> Hi,
> 
> I would be very willing to be a mentor for wxRuby work.

Cool :)

> There are so many things that wxRuby needs, but I'm not sure how well
> they would fit into a specific TODO list. 

Yes, it seems to be going to be a very "diverse" list.

> How comfortable are you with C++? Most of the current wxRuby problems
> are cases where we are generating bad C++ code for some reason, so it
> helps to be able to understand what's going wrong. You don't need to be
> a C++ expert, but should understand basic C++.

I've never done a whole project in C++, but I know the basics from 
reading Stroustrup's book and now we also have a C++ course in the 
university.

> Are you familiar with SWIG? Many of the "missing" wx methods are because
> none of us have been familiar enough with SWIG to add them. Roy is now
> stepping up in this area, which is great. I assume he would welcome
> additional help.

One of my personal projects uses SWIG to interface a C++ library with 
Ruby. It's called id3lib-ruby (http://id3lib-ruby.rubyforge.org/) and I 
just had the first release yesterday :). Of course it's not as big as 
wxRuby - the SWIG part is only about 150 lines of code. And I didn't 
have to use directors or other advanced SWIG features, but I wouldn't be 
completely lost with SWIG either.

> There is also the "rubyified" API that we would like to see. The current
> API is just a thin wrapper over the C++ API. A rubyish (and
> higher-level) wrapper would be much more pleasant to work with. I always
> use the example of how much nicer FXRuby is vs. plain FOX.
> 
> Another nice project would be to build a good unit test suite. I know
> Roy is working on this also. I made an attempt many months ago, but
> didn't get very far.
 >
> There's also building gems for wxruby, but hopefully that wouldn't take
> a whole summer.

So, maybe the list of tasks would look like this:

- create unit tests
- create a gem
- rubyfy API (maybe)
- improve samples and documentation
- add missing classes (?)

Does anyone know what the project's size is supposed to be? Is this list 
too much or too little?

> And, of course, we could always use better samples, and better user
> documentation.

Added to the list.

So, in the next days I'll have a look at how the application should look 
like and how detailed the task description has to be. If all goes well, 
I'll write my application (and hopefully be accepted).

> Kevin

   Robin

PS: Excuse my sometimes long sentences or the clumsy formulation, but 
I'm still an English learner :)

From robin at nibor.org  Tue Apr 25 18:17:01 2006
From: robin at nibor.org (Robin Stocker)
Date: Wed, 26 Apr 2006 00:17:01 +0200
Subject: [Wxruby-users] Summer of Code for wxRuby?
In-Reply-To: <444D90B6.1040107@mindspring.com>
References: <444D4821.4000903@nibor.org>	<1145927721.25718.21.camel@localhost.localdomain>
	<444D90B6.1040107@mindspring.com>
Message-ID: <444E9FDD.3050201@nibor.org>

Roy Sutton wrote:
> I originally suggested wxRuby for the Summer of Code on the Ruby mailing 
> list.  I think it would be great to get someone in here who can really 
> focus on the issues that the rest of us are mostly dabbling at.  Kevin 
> is right, though, that much of what we're knocking our heads against is 
> C++, not Ruby.  The exciting stuff will be the ruby-style interface, 
> however, the stability of wxRuby2 right now doesn't quite justify it.  
> That said, I'm glad to help out anyone who wants to throw in a shoulder 
> here.

I understand that the major part is C++ and SWIG, I just wanted to find 
a project that benefits the Ruby community. And as I like wxWidgets and 
have been following the wxRuby mailing list, I thought: Hey, why not try 
to help wxRuby :). I hope I can actually help so that there can be a 
release of wxRuby2 soon.

From alex at pressure.to  Tue Apr 25 19:02:02 2006
From: alex at pressure.to (Alex Fenton)
Date: Wed, 26 Apr 2006 00:02:02 +0100
Subject: [Wxruby-users] Summer of Code for wxRuby?
In-Reply-To: <444D4821.4000903@nibor.org>
References: <444D4821.4000903@nibor.org>
Message-ID: <444EAA6A.1080601@pressure.to>

Hi Robin

Robin Stocker wrote:
> I would be interested to work on wxRuby as a student. So, my question 
> is, are there tasks that need to be done and would be suitable for a 
> Summer of Code project? 
A lot of people are really looking forward to see the fruits of all the 
work on the SWIG version of wxruby, so any contribution to the current 
work of tracking down SWIG/C++/Ruby bugs would be welcome. From Kevin 
you've the offer of mentoring from a very experienced and astute 
developer, and there are other good people with a wide range of skills 
involved in wxruby.

For a SoC project you could also think about trying to add some 
substantial new feature to wxruby that helped it stand out as a GUI 
package for Ruby. There's a lot of different possible projects and maybe 
there's something particular that interests you.

- It could be porting something that's in WxWidgets, but not in WxRuby - 
such as printing support, HTML rendering, Wizards, Sash Layouts etc. 
There's a list of what's available in WxWidgets but not yet ported to 
ruby at
http://wxruby.rubyforge.org/wiki/wiki.pl?What_Classes_Are_Implemented_In_Wxruby
- You could port one of the user contributed WxWidgets components, such 
as those at http://wxcode.sourceforge.net/ or the WxAUI 
http://www.kirix.com/en/community/opensource/wxaui/about_wxaui.html- 
these include really cool GUI elements such as dockable toolbars etc
- Documentation (a user manual, or something that produces accurate 
Ruby-style documentation correctly from the WxWidgets docs - there's 
already made some good progress here: 
http://rubyforge.org/pipermail/wxruby-users/2005-February/001152.html )
- Using other ruby libraries in interesting ways - eg linking with 
ruby's unit test facilities, or i18n

Doing any of those sort of projects would probably turn up and help 
everyone fix a few bugs on the way too ;)

good luck
alex


From alex at pressure.to  Tue Apr 25 19:18:30 2006
From: alex at pressure.to (Alex Fenton)
Date: Wed, 26 Apr 2006 00:18:30 +0100
Subject: [Wxruby-users] XP-style widgets in wxruby
Message-ID: <444EAE46.8080204@pressure.to>

Just to share a tip - if you're using wxruby on Windows XP, you can have 
wxruby display widgets in the XP GUI style (rounded buttons and tabs, 
hover effects on button etc) - if you happen to like it.

Create an XML file called ruby.exe.manifest similar to the attached in 
the same directory as your ruby.exe (Something like c:/ruby/bin/). You 
might want to edit the version number - but it must always be four 
dot-separated digits, otherwise your ruby won't run at all.

Whenever you run wxruby programs after this, widgets should be shown 
using XP styles.

alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ruby.exe.manifest
Type: text/xml
Size: 646 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/wxruby-users/attachments/20060426/dcf4434c/attachment.xml 

From wxruby at qualitycode.com  Wed Apr 26 09:31:34 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Wed, 26 Apr 2006 09:31:34 -0400
Subject: [Wxruby-users] Summer of Code for wxRuby?
In-Reply-To: <444E9BFD.3000305@nibor.org>
References: <444D4821.4000903@nibor.org>
	<1145927721.25718.21.camel@localhost.localdomain>
	<444E9BFD.3000305@nibor.org>
Message-ID: <1146058294.8442.26.camel@localhost.localdomain>

On Wed, 2006-04-26 at 00:00 +0200, Robin Stocker wrote:
> Kevin Smith wrote:
> > Hi,
> > 
> > I would be very willing to be a mentor for wxRuby work.

I just looked at the google site, and the deadline to sign up as a
mentoring organization was the 24th (two days ago). So I (and "wxruby")
can't be mentoring organizations. Perhaps I could be a mentor through
RubyCentral or wxWidgets, since they both signed up as mentoring
organizations.


> > How comfortable are you with C++? Most of the current wxRuby problems
> > are cases where we are generating bad C++ code for some reason, so it
> > helps to be able to understand what's going wrong. You don't need to be
> > a C++ expert, but should understand basic C++.
> 
> I've never done a whole project in C++, but I know the basics from 
> reading Stroustrup's book and now we also have a C++ course in the 
> university.

That would probably be enough C++ to work on wxruby internals.

> So, maybe the list of tasks would look like this:
> 
> - create unit tests
> - create a gem
> - rubyfy API (maybe)
> - improve samples and documentation
> - add missing classes (?)
> 
> Does anyone know what the project's size is supposed to be? Is this list 
> too much or too little?

I can't find any guidelines. And a very brief search didn't reveal any
summaries from last year's SoC that would show what someone else did.
I'm sure they're out there, but they don't seem to be linked directly
from google's SoC 2005 page.

The project runs May 23 - August 21, so it's 3 months. The SoC materials
do not indicate whether they expect full-time work, part-time, or
something else. My guess is that they would prefer projects that have
clear milestones, rather than tasks like "work on X for a month".

Thinking about unit tests: It might take something like a week to get a
good simple test framework in place. (I don't think my early work in
that area qualifies, but Roy's recent work might). Then, if there are
100 wx classes averaging 20 methods each, and each method takes 12
minutes (5 per hour), it would take 400 hours, or 10 full-time weeks, to
create a complete test suite.

Based on those VERY rough numbers, unit tests alone could consume your
entire summer.

On the other hand, I suspect you could create a set of gems within a
week or two.

Creating a really good sample app would probably take several weeks, but
not the whole summer. 

> So, in the next days I'll have a look at how the application should look 
> like and how detailed the task description has to be. If all goes well, 
> I'll write my application (and hopefully be accepted).

Excellent. One of us should also contact the RubyCentral and/or
wxWidgets folks to see if they would accept me as a mentor for your
project.

> PS: Excuse my sometimes long sentences or the clumsy formulation, but 
> I'm still an English learner :)

I couldn't even tell that you were not a native speaker.

Kevin



From roys at mindspring.com  Thu Apr 27 00:56:03 2006
From: roys at mindspring.com (Roy Sutton)
Date: Thu, 27 Apr 2006 00:56:03 -0400
Subject: [Wxruby-users] Major Breakthrough?
Message-ID: <44504EE3.5040207@mindspring.com>

Attached are patches to make the textctrl.rb sample work fully.  Note 
the new %directorargout typemap I added to fix wxWindows calling into 
SWIG.  I don't know if this can fix all such problems or not.  Let me 
know what you think.

I also rubified the sample a little bit more.  Also, note that I fix the 
<< operator so the function can be called.  I hope I did this right.

Roy
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: textctrl.rb.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060427/f3b88937/attachment.bat 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TextCtrl.i.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060427/f3b88937/attachment-0001.bat 

From alex at pressure.to  Thu Apr 27 11:08:53 2006
From: alex at pressure.to (Alex Fenton)
Date: Thu, 27 Apr 2006 16:08:53 +0100
Subject: [Wxruby-users] Major Breakthrough?
In-Reply-To: <44504EE3.5040207@mindspring.com>
References: <44504EE3.5040207@mindspring.com>
Message-ID: <4450DE85.3020103@pressure.to>

Thanks Roy. Fixing the methods in TextCtrl was one of the top reasons I 
wanted to get the typemaps.i working. Nice also to have an example of 
how to discard a return value. Another method that should now be easy to 
port is TextCtrl#HitTest, but I can't try it b/c it's only implemented 
on MSW & GTK.

I have a few OS X bugs with these typemaps now:
* the first return value of position_to_xy is always false, even if a 
valid position is given. The correct x & y values are returned - so this 
below, adapted from your textctrl.rb report() method works correctly on OS X

    result, x, y = position_to_xy(get_insertion_point)
    if x.zero? and y.zero?
      report << "<invalid location>\n"
    else
      report << x.to_s << ", " << y.to_s << "\n"
    end

Perhaps it would be better to dump the boolean return value of 
position_to_xy altogether, return a two-element array, and just return 
Ruby nil if an invalid position is passed?

* the return value of get_last_position is always an opaque SWIG type 
SWIG::TYPE_p_wxTextPos:0x3a807c

It should be seen and converted as a long. I tried including 
wx/textctrl.h, which includes a typedef for wxTextPos. I tried adding a 
typemap

%typemap(directorout) wxTextPos {
  $1 = LONG2NUM((long)$1);
}

but neither seemed to help

cheers
alex


Roy Sutton wrote:
> Attached are patches to make the textctrl.rb sample work fully.  Note 
> the new %directorargout typemap I added to fix wxWindows calling into 
> SWIG.  I don't know if this can fix all such problems or not.  Let me 
> know what you think.
>
> I also rubified the sample a little bit more.  Also, note that I fix 
> the << operator so the function can be called.  I hope I did this right.
>
> Roy
> ------------------------------------------------------------------------
>
>
> C:\RubyDev>diff -b -u wxruby2_old/samples/text/textctrl.rb wxruby2/samples/text/textctrl.rb  
> --- wxruby2_old/samples/text/textctrl.rb	2005-11-28 19:07:04.000000000 -0500
> +++ wxruby2/samples/text/textctrl.rb	2006-04-26 23:46:39.539263000 -0400
> @@ -12,21 +12,22 @@
>      super(parent, -1, text, Wx::DEFAULT_POSITION, Wx::DEFAULT_SIZE, STYLE)
>    end
>  
> -  # more ruby-ish
> -  alias :<< :append_text
> -
>    # run through a few useful methods of textctrl and report the results
>    # as a string
> -  def report()
> +  def report
>      report = ''
> -    report << 'Insertion Point: ' << get_insertion_point.to_s() << "\n"
> +    report << 'Insertion Point: ' << get_insertion_point.to_s << "\n"
>      report << 'First Line Text: ' << get_line_text(0) << "\n"
> -    report << 'Final Position: ' << get_last_position().to_s() << "\n"
> -    report << 'String Selection: ' << get_string_selection().inspect << "\n"
> -    # not available
> -    report << 'Selection: ' << "Not Implemented\n"
> -    # available, but method signature is wrong (3 for 1) - needs SWIG hints
> -    report << 'Position to XY: ' << "Not Implemented\n"
> +    report << 'Final Position: ' << get_last_position.to_s << "\n"
> +    report << 'String Selection: ' << get_string_selection.inspect << "\n"
> +    report << 'Selection: ' << get_selection.join(' to ') << "\n"
> +    report << 'Position to XY: '
> +    result, x, y = position_to_xy(get_insertion_point);
> +    if result
> +      report << x.to_s << ", " << y.to_s << "\n"
> +    else
> +      report << "<invalid location>\n"
> +    end
>      return report
>    end
>  end
> @@ -45,7 +46,7 @@
>      sizer = Wx::BoxSizer.new(Wx::VERTICAL)
>  
>      @textctrl = InformativeTextCtrl.new(self, '')
> -    populate_textctrl()
> +    populate_textctrl
>      sizer.add(@textctrl, 2, Wx::GROW|Wx::ALL, 2)
>  
>      button = Wx::Button.new(self, -1, 'Get Info')
> @@ -58,7 +59,7 @@
>      self.set_sizer( sizer )
>    end
>  
> -  def populate_textctrl()
> +  def populate_textctrl
>      @textctrl << "This is some plain text\n"
>      @textctrl << "Text with green letters and yellow background\n"
>      @textctrl << "This is some more plain text"
> @@ -68,31 +69,31 @@
>      @textctrl.set_style(24, 69, attr)
>    end
>  
> -  def construct_menus()
> -    menu_bar = Wx::MenuBar.new()
> +  def construct_menus
> +    menu_bar = Wx::MenuBar.new
>  
> -    menu_file = Wx::Menu.new()
> +    menu_file = Wx::Menu.new
>      menu_file.append(Wx::ID_EXIT, "E&xit\tAlt-X", "Quit this program")
>      menu_bar.append(menu_file, "&File")
> -    evt_menu(Wx::ID_EXIT) { on_quit() }
> +    evt_menu(Wx::ID_EXIT) { on_quit }
>  
> -    menu_help = Wx::Menu.new()
> +    menu_help = Wx::Menu.new
>      menu_help.append(Wx::ID_ABOUT, "&About...\tF1", "Show about dialog")
> -    evt_menu(Wx::ID_ABOUT) { on_about() }
> +    evt_menu(Wx::ID_ABOUT) { on_about }
>      menu_bar.append(menu_help, "&Help")
>  
>      set_menu_bar(menu_bar)
>    end
>  
>    def on_click(e)
> -    @log.set_value( @textctrl.report() )
> +    @log.set_value( @textctrl.report )
>    end
>  
> -  def on_quit()
> +  def on_quit
>      close(TRUE)
>    end
>  
> -  def on_about()
> +  def on_about
>      msg =  sprintf("This is the About dialog of the textctrl sample.\n" \
>                      "Welcome to %s", Wx::VERSION_STRING)
>      message_box(msg, "About Minimal", Wx::OK|Wx::ICON_INFORMATION, self)
> @@ -100,7 +101,7 @@
>  end
>  
>  class RbApp < Wx::App
> -  def on_init()
> +  def on_init
>      frame = TextCtrlFrame.new("TextCtrl demonstration",
>                                Wx::Point.new(50, 50),
>                                Wx::Size.new(450, 340) )
> @@ -109,4 +110,4 @@
>    end
>  end
>  
> -RbApp.new().main_loop()
> +RbApp.new.main_loop
>   
> ------------------------------------------------------------------------
>
>
> C:\RubyDev>diff -b -u wxruby2_old/swig/classes/TextCtrl.i wxruby2/swig/classes/TextCtrl.i  
> --- wxruby2_old/swig/classes/TextCtrl.i	2005-08-20 19:47:08.000000000 -0400
> +++ wxruby2/swig/classes/TextCtrl.i	2006-04-27 00:29:05.710477400 -0400
> @@ -26,10 +26,20 @@
>  
>  %}
>  
> -%init %{
> -  extern VALUE mWxTextCtrl;
> -  rb_define_method(mWxTextCtrl, "<<", VALUEFUNC(op_append), 1);
> -%}
> +%apply long *OUTPUT { long* from , long* to };
> +%apply long *OUTPUT { long* x , long* y };
> +
> +%typemap(directorargout) ( long* from, long* to ) {
> +  if((TYPE(result) == T_ARRAY) && (RARRAY(result)->len >= 2))
> +  {
> +    *$1 = NUM2LONG(rb_ary_entry(result,0));
> +    *$2 = NUM2LONG(rb_ary_entry(result,1));
> +  }
> +  else
> +  {
> +    *$1 = 0; *$2 = 0;
> +  }
> +}
>  
>  %import "include/wxObject.h"
>  %import "include/wxEvtHandler.h"
> @@ -37,3 +47,7 @@
>  %import "include/wxControl.h"
>  
>  %include "include/wxTextCtrl.h"
> +
> +%init %{
> +  rb_define_method(cWxTextCtrl.klass, "<<", VALUEFUNC(op_append), 1);
> +%}
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users


From roys at mindspring.com  Thu Apr 27 11:39:30 2006
From: roys at mindspring.com (Roy Sutton)
Date: Thu, 27 Apr 2006 11:39:30 -0400
Subject: [Wxruby-users] Major Breakthrough?
In-Reply-To: <4450DE85.3020103@pressure.to>
References: <44504EE3.5040207@mindspring.com> <4450DE85.3020103@pressure.to>
Message-ID: <4450E5B2.1000103@mindspring.com>

Alex Fenton wrote:
> Thanks Roy. Fixing the methods in TextCtrl was one of the top reasons I 
> wanted to get the typemaps.i working. Nice also to have an example of 
> how to discard a return value. Another method that should now be easy to 
> port is TextCtrl#HitTest, but I can't try it b/c it's only implemented 
> on MSW & GTK.
>   
I'll look at HitTest. 
> I have a few OS X bugs with these typemaps now:
> * the first return value of position_to_xy is always false, even if a 
> valid position is given. The correct x & y values are returned - so this 
> below, adapted from your textctrl.rb report() method works correctly on OS X
>
>     result, x, y = position_to_xy(get_insertion_point)
>     if x.zero? and y.zero?
>       report << "<invalid location>\n"
>     else
>       report << x.to_s << ", " << y.to_s << "\n"
>     end
>   
Odd.  Works fine on Windows.  Wonder if it's a wx bug?
> Perhaps it would be better to dump the boolean return value of 
> position_to_xy altogether, return a two-element array, and just return 
> Ruby nil if an invalid position is passed?
>
> * the return value of get_last_position is always an opaque SWIG type 
> SWIG::TYPE_p_wxTextPos:0x3a807c
>
> It should be seen and converted as a long. I tried including 
> wx/textctrl.h, which includes a typedef for wxTextPos. I tried adding a 
> typemap
>   
Oops!  My bad.  I forgot to send the patch for typedefs.i

Just add 'typedef long wxTextPos;' to it.
> %typemap(directorout) wxTextPos {
>   $1 = LONG2NUM((long)$1);
> }
>
> but neither seemed to help
>
> cheers
> alex
>
>   

From roys at mindspring.com  Thu Apr 27 11:58:33 2006
From: roys at mindspring.com (Roy Sutton)
Date: Thu, 27 Apr 2006 11:58:33 -0400
Subject: [Wxruby-users] typedefs.i.patch
Message-ID: <4450EA29.1040400@mindspring.com>

Missing piece for the textctrl.rb sample

Roy
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: typedefs.i.patch
Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060427/1a38ca87/attachment.bat 

From alex at pressure.to  Thu Apr 27 13:59:54 2006
From: alex at pressure.to (Alex Fenton)
Date: Thu, 27 Apr 2006 18:59:54 +0100
Subject: [Wxruby-users] Major Breakthrough?
In-Reply-To: <4450E5B2.1000103@mindspring.com>
References: <44504EE3.5040207@mindspring.com> <4450DE85.3020103@pressure.to>
	<4450E5B2.1000103@mindspring.com>
Message-ID: <4451069A.7@pressure.to>

A quick question - on Windows, does the background colour of styled text 
in the the text control show up yellow?

Roy Sutton wrote:
>> * the first return value of position_to_xy is always false, even if a 
>> valid position is given. The correct x & y values are returned 
>>     
> Odd.  Works fine on Windows.  Wonder if it's a wx bug?
>   
Could well be a WxMac bug - perhaps someone else can confirm. If so we 
can work round it.
> Oops!  My bad.  I forgot to send the patch for typedefs.i
>   
perfect, thanks.

From roys at mindspring.com  Thu Apr 27 14:52:44 2006
From: roys at mindspring.com (Roy Sutton)
Date: Thu, 27 Apr 2006 14:52:44 -0400
Subject: [Wxruby-users] Major Breakthrough?
In-Reply-To: <4451069A.7@pressure.to>
References: <44504EE3.5040207@mindspring.com>
	<4450DE85.3020103@pressure.to>	<4450E5B2.1000103@mindspring.com>
	<4451069A.7@pressure.to>
Message-ID: <445112FC.5000302@mindspring.com>

Alex Fenton wrote:
> A quick question - on Windows, does the background colour of styled text 
> in the the text control show up yellow?
Yes, but...  The text is selected at first.  You have to un-select it to 
see the style.  Perhaps I should modify the sample to unselect?

From alex at pressure.to  Thu Apr 27 18:24:05 2006
From: alex at pressure.to (Alex Fenton)
Date: Thu, 27 Apr 2006 23:24:05 +0100
Subject: [Wxruby-users] Major Breakthrough?
In-Reply-To: <445112FC.5000302@mindspring.com>
References: <44504EE3.5040207@mindspring.com>	<4450DE85.3020103@pressure.to>	<4450E5B2.1000103@mindspring.com>	<4451069A.7@pressure.to>
	<445112FC.5000302@mindspring.com>
Message-ID: <44514485.4060604@pressure.to>

Roy Sutton wrote:
>> A quick question - on Windows, does the background colour of styled text 
>> in the the text control show up yellow?
>>     
> Yes, but...  The text is selected at first.  You have to un-select it to 
> see the style.  Perhaps I should modify the sample to unselect?
Thanks. Maybe a side effect of the set_style method - in previous wxruby 
on windows it does things like scrolling the viewpane.

It'd be good to test the set_selection method anyway, so maybe add a 
line like:
    @textctrl.set_selection(8, 23)
In the constructor method.

Also testing - TextCtrl#get_style isn't working - it's looking for two 
arguments:
*bool* *GetStyle*(*long */position/, *wxTextAttr& */style)/
but should take just one (position) and return a TextAttr or nil on 
failure I think.

alex



From robin at nibor.org  Thu Apr 27 18:30:37 2006
From: robin at nibor.org (Robin Stocker)
Date: Fri, 28 Apr 2006 00:30:37 +0200
Subject: [Wxruby-users] Summer of Code for wxRuby?
In-Reply-To: <1146058294.8442.26.camel@localhost.localdomain>
References: <444D4821.4000903@nibor.org>	<1145927721.25718.21.camel@localhost.localdomain>	<444E9BFD.3000305@nibor.org>
	<1146058294.8442.26.camel@localhost.localdomain>
Message-ID: <4451460D.5000404@nibor.org>

Kevin Smith wrote:
> I just looked at the google site, and the deadline to sign up as a
> mentoring organization was the 24th (two days ago). So I (and "wxruby")
> can't be mentoring organizations. Perhaps I could be a mentor through
> RubyCentral or wxWidgets, since they both signed up as mentoring
> organizations.

Yes, I think the idea is that there is a mentoring organisation for each 
language (or large project), under which small projects are gathered. 
So, I apply at RubyCentral to work for the wxRuby project and then you 
can register as a mentor for wxRuby.

> The project runs May 23 - August 21, so it's 3 months. The SoC materials
> do not indicate whether they expect full-time work, part-time, or
> something else. My guess is that they would prefer projects that have
> clear milestones, rather than tasks like "work on X for a month".

I won't be able to work on it full-time, because I have to study until 
the 7th of July (maybe holiday times are different in the USA than here 
in Europe). Therefore I hope that part-time is ok..

> Thinking about unit tests: It might take something like a week to get a
> good simple test framework in place. (I don't think my early work in
> that area qualifies, but Roy's recent work might). Then, if there are
> 100 wx classes averaging 20 methods each, and each method takes 12
> minutes (5 per hour), it would take 400 hours, or 10 full-time weeks, to
> create a complete test suite.
> 
> Based on those VERY rough numbers, unit tests alone could consume your
> entire summer.
> 
> On the other hand, I suspect you could create a set of gems within a
> week or two.
> 
> Creating a really good sample app would probably take several weeks, but
> not the whole summer. 

I have thought about the different possibilities, and now my plan looks 
like this:
- implement a number of classes that are missing in wxRuby2
- try to create unit tests for them

So, I won't be writing _only_ unit tests, and the unit tests I write are 
about classes I should know (because I "implemented" them).
And looking at "What Classes Are Implemented In Wxruby" in the Wiki, 
there should be plenty of classes to choose. The thing I don't know yet 
is the number of classes. What do you think would be realistic? 10, 20, 30?

> Excellent. One of us should also contact the RubyCentral and/or
> wxWidgets folks to see if they would accept me as a mentor for your
> project.

Let's wait with that until I actually have sent my application in. As 
you can see on the timeline, mentors have time until May 22 to sign up, 
so there's plenty of time.
(http://code.google.com/soc/mentorfaq.html#34)

> I couldn't even tell that you were not a native speaker.

Really? But I'm very unsure, for example, about (at?, of?) using 
prepositions or linking words or tenses or comma placement. And I needed 
about an hour to write this e-mail.. But thanks anyway for saying that :)

Regards,
   Robin

From robin at nibor.org  Thu Apr 27 18:45:12 2006
From: robin at nibor.org (Robin Stocker)
Date: Fri, 28 Apr 2006 00:45:12 +0200
Subject: [Wxruby-users] Summer of Code for wxRuby?
In-Reply-To: <444EAA6A.1080601@pressure.to>
References: <444D4821.4000903@nibor.org> <444EAA6A.1080601@pressure.to>
Message-ID: <44514978.2070708@nibor.org>

Alex Fenton wrote:
> A lot of people are really looking forward to see the fruits of all the 
> work on the SWIG version of wxruby, so any contribution to the current 
> work of tracking down SWIG/C++/Ruby bugs would be welcome. From Kevin 
> you've the offer of mentoring from a very experienced and astute 
> developer, and there are other good people with a wide range of skills 
> involved in wxruby.

Sounds good :)

> For a SoC project you could also think about trying to add some 
> substantial new feature to wxruby that helped it stand out as a GUI 
> package for Ruby. There's a lot of different possible projects and maybe 
> there's something particular that interests you.
> 
> - It could be porting something that's in WxWidgets, but not in WxRuby - 
> such as printing support, HTML rendering, Wizards, Sash Layouts etc. 
> There's a list of what's available in WxWidgets but not yet ported to 
> ruby at
> http://wxruby.rubyforge.org/wiki/wiki.pl?What_Classes_Are_Implemented_In_Wxruby
> - You could port one of the user contributed WxWidgets components, such 
> as those at http://wxcode.sourceforge.net/ or the WxAUI 
> http://www.kirix.com/en/community/opensource/wxaui/about_wxaui.html- 
> these include really cool GUI elements such as dockable toolbars etc
> - Documentation (a user manual, or something that produces accurate 
> Ruby-style documentation correctly from the WxWidgets docs - there's 
> already made some good progress here: 
> http://rubyforge.org/pipermail/wxruby-users/2005-February/001152.html )
> - Using other ruby libraries in interesting ways - eg linking with 
> ruby's unit test facilities, or i18n

Thank you for this very helpful list! I decided to do the first one, 
porting some missing classes and also try to create unit tests for them.

> Doing any of those sort of projects would probably turn up and help 
> everyone fix a few bugs on the way too ;)

Yes, I hope so :)

> good luck
> alex

Thanks,
   Robin

From roys at mindspring.com  Thu Apr 27 23:27:08 2006
From: roys at mindspring.com (Roy Sutton)
Date: Thu, 27 Apr 2006 23:27:08 -0400
Subject: [Wxruby-users] Summer of Code for wxRuby?
In-Reply-To: <44514978.2070708@nibor.org>
References: <444D4821.4000903@nibor.org> <444EAA6A.1080601@pressure.to>
	<44514978.2070708@nibor.org>
Message-ID: <44518B8C.7060108@mindspring.com>

I just updated the link below manually.  It may or may not be accurate. :)
>> - It could be porting something that's in WxWidgets, but not in WxRuby - 
>> such as printing support, HTML rendering, Wizards, Sash Layouts etc. 
>> There's a list of what's available in WxWidgets but not yet ported to 
>> ruby at
>> http://wxruby.rubyforge.org/wiki/wiki.pl?What_Classes_Are_Implemented_In_Wxruby
>>     
>

From wxruby at qualitycode.com  Sat Apr 29 15:44:26 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 15:44:26 -0400
Subject: [Wxruby-users] Patches for object tracking
In-Reply-To: <1145927418.25718.17.camel@localhost.localdomain>
References: <444BB920.9050502@mindspring.com>
	<1145927418.25718.17.camel@localhost.localdomain>
Message-ID: <1146339866.17322.3.camel@localhost.localdomain>

On Mon, 2006-04-24 at 21:10 -0400, Kevin Smith wrote:
> I'm reluctant to check these in, as they have made things distinctly
> worse for me. These are the first patches I have tried to apply tonight,
> and they make almost anything in bigdemo crash immediately. 

I found the easiest way to duplicate the problem was to run the
minimal.rb sample, do Help/About, and hit OK to close the box.

Then I discovered that the SWIG code was dereferencing some internal
value, and it was expecting a normal Ruby object, but the value actually
contained Qnil. I don't know why.

I updated the SWIG post-processors to allow for this case, and now
everything works quite smoothly. I was able to run several samples,
performing several operations in each, with no crashes. I did get one
segfault upon exiting bigdemo though, so it's not perfect yet.

So Roy's patch, and my additional patch, are both checked in. At least
theoretically, we have object tracking now.

Kevin



From wxruby at qualitycode.com  Sat Apr 29 15:50:31 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 15:50:31 -0400
Subject: [Wxruby-users] wxTextCtr.h.patch
In-Reply-To: <444BBBBA.2010008@mindspring.com>
References: <444BBBBA.2010008@mindspring.com>
Message-ID: <1146340231.17322.5.camel@localhost.localdomain>

My mistake. I just checked in this fix. Thanks.

Kevin


On Sun, 2006-04-23 at 13:39 -0400, Roy Sutton wrote:
> I think I had to do this to get the tarball to compile on Windows
> plain text document attachment (wxTextCtrl.h.patch)
> C:\RubyDev>diff -b -u wxruby2_old/swig/classes/include/wxTextCtrl.h wxruby2/swig/classes/include/wxTextCtrl.h  
> --- wxruby2_old/swig/classes/include/wxTextCtrl.h	2006-04-20 21:56:04.000000000 -0400
> +++ wxruby2/swig/classes/include/wxTextCtrl.h	2006-04-20 23:43:32.772160000 -0400
> @@ -166,7 +166,7 @@
>      
>  	//virtual void SetEditable(bool editable) = 0;
>  
> -    int overflow(int i);
> +	//    int overflow(int i);
>      wxTextCtrl& operator<<(const wxString& s);
>      wxTextCtrl& operator<<(int i);
>      wxTextCtrl& operator<<(long i);
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users


From roys at mindspring.com  Sat Apr 29 16:02:46 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sat, 29 Apr 2006 16:02:46 -0400
Subject: [Wxruby-users] Patches for object tracking
In-Reply-To: <1146339866.17322.3.camel@localhost.localdomain>
References: <444BB920.9050502@mindspring.com>	<1145927418.25718.17.camel@localhost.localdomain>
	<1146339866.17322.3.camel@localhost.localdomain>
Message-ID: <4453C666.1070909@mindspring.com>

Kevin,

Glad you tracked that down.  Actually, the minimal sample crashes for me 
on Windows (before applying your patch).  I believe it's because it 
explicitly does a GC.start in the help box.  This has to do with object 
tracking, which is not fully implemented yet.  I will try out your 
patches to see if they resolve any other problems I've seen.  I'm 
spinning my wheels at the moment trying to decide what to tackle.  I 
think the most important thing is the typemap problem with the 
externalLeading stuff.  Alex's patch didn't make it work right for me 
(though I may have applied it wrong?).  If we can't track it down we'll 
have to manually update that code.

On an unrelated note, how strongly are you for/against mixing in SWIG 
directives into our .h files?  I think it may be the only way to apply 
certain typemaps, since you can't apply typemaps by function name, only 
argument.

Roy

Kevin Smith wrote:
> On Mon, 2006-04-24 at 21:10 -0400, Kevin Smith wrote:
>   
>> I'm reluctant to check these in, as they have made things distinctly
>> worse for me. These are the first patches I have tried to apply tonight,
>> and they make almost anything in bigdemo crash immediately. 
>>     
>
> I found the easiest way to duplicate the problem was to run the
> minimal.rb sample, do Help/About, and hit OK to close the box.
>
> Then I discovered that the SWIG code was dereferencing some internal
> value, and it was expecting a normal Ruby object, but the value actually
> contained Qnil. I don't know why.
>
> I updated the SWIG post-processors to allow for this case, and now
> everything works quite smoothly. I was able to run several samples,
> performing several operations in each, with no crashes. I did get one
> segfault upon exiting bigdemo though, so it's not perfect yet.
>
> So Roy's patch, and my additional patch, are both checked in. At least
> theoretically, we have object tracking now.
>
> Kevin
>
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>
>   

From wxruby at qualitycode.com  Sat Apr 29 16:05:05 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 16:05:05 -0400
Subject: [Wxruby-users] ComboBox patch files
In-Reply-To: <444BB4A7.9030100@mindspring.com>
References: <444BB4A7.9030100@mindspring.com>
Message-ID: <1146341105.17322.9.camel@localhost.localdomain>

On Sun, 2006-04-23 at 13:08 -0400, Roy Sutton wrote:
> The following two files correct problems with the ComboBox 
> implementation.  You will also need my typemap.i.patch file 
> (forthcoming) in order for the void * typemap to work properly (I think).

I'm not sure which typemap.i patch you're referring to. When I applied
these patches, the combobox page of the controls sample bombed for me.
So I can't accept them as-is.

After selecting the "Really" item, about 30 mysterious debug statement
showed up on the console, and then the standard wx "oops" dialog
appeared offering to terminate the app.

Kevin



From wxruby at qualitycode.com  Sat Apr 29 16:15:26 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 16:15:26 -0400
Subject: [Wxruby-users] Patches for object tracking
In-Reply-To: <4453C666.1070909@mindspring.com>
References: <444BB920.9050502@mindspring.com>
	<1145927418.25718.17.camel@localhost.localdomain>
	<1146339866.17322.3.camel@localhost.localdomain>
	<4453C666.1070909@mindspring.com>
Message-ID: <1146341727.17322.16.camel@localhost.localdomain>

On Sat, 2006-04-29 at 16:02 -0400, Roy Sutton wrote:
> I'm spinning my wheels at the moment trying to decide what to tackle.  

One of my own pet peeves is all the compile warnings. Especially the new
"dh is not used". If there's a simple way to fix the code emission to
avoid them, that would be great. I don't want to tweak compiler command
lines to simply hide the warnings, though.

Of course, for me, bigdemo still has the splitter problem. I'll take a
look at that myself this afternoon.

Beyond that, I'm afraid I really haven't used wx enough recently to know
what is most pressing.

> On an unrelated note, how strongly are you for/against mixing in SWIG 
> directives into our .h files?  I think it may be the only way to apply 
> certain typemaps, since you can't apply typemaps by function name, only 
> argument.

I guess I would have to see an example to know how I feel about it.

Kevin



From roys at mindspring.com  Sat Apr 29 16:34:07 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sat, 29 Apr 2006 16:34:07 -0400
Subject: [Wxruby-users] Patches for object tracking
In-Reply-To: <1146341727.17322.16.camel@localhost.localdomain>
References: <444BB920.9050502@mindspring.com>	<1145927418.25718.17.camel@localhost.localdomain>	<1146339866.17322.3.camel@localhost.localdomain>	<4453C666.1070909@mindspring.com>
	<1146341727.17322.16.camel@localhost.localdomain>
Message-ID: <4453CDBF.5090608@mindspring.com>

Kevin Smith wrote:
> On Sat, 2006-04-29 at 16:02 -0400, Roy Sutton wrote:
>   
>> I'm spinning my wheels at the moment trying to decide what to tackle.  
>>     
>
> One of my own pet peeves is all the compile warnings. Especially the new
> "dh is not used". If there's a simple way to fix the code emission to
> avoid them, that would be great. I don't want to tweak compiler command
> lines to simply hide the warnings, though.
>   
I know exactly what you mean.  I insist on a clean compile on everything 
else.  I was just taking a look at the new, recurring SWIG warning 
(Warning(473): Returning a pointer...).
>> On an unrelated note, how strongly are you for/against mixing in SWIG 
>> directives into our .h files?  I think it may be the only way to apply 
>> certain typemaps, since you can't apply typemaps by function name, only 
>> argument.
>>     
>
> I guess I would have to see an example to know how I feel about it.
If I have to do it to wrap something I'll send in an example.  I haven't 
had to do it yet.

Roy

From wxruby at qualitycode.com  Sat Apr 29 16:40:07 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 16:40:07 -0400
Subject: [Wxruby-users] Patches for object tracking
In-Reply-To: <1146341727.17322.16.camel@localhost.localdomain>
References: <444BB920.9050502@mindspring.com>
	<1145927418.25718.17.camel@localhost.localdomain>
	<1146339866.17322.3.camel@localhost.localdomain>
	<4453C666.1070909@mindspring.com>
	<1146341727.17322.16.camel@localhost.localdomain>
Message-ID: <1146343207.17322.19.camel@localhost.localdomain>

On Sat, 2006-04-29 at 16:15 -0400, Kevin Smith wrote:
> Of course, for me, bigdemo still has the splitter problem. I'll take a
> look at that myself this afternoon.

Fixed. Turns out the default splitter location was so high that it was
underneath the notebook tabs. So I couldn't grab it with the mouse to
resize it. I changed the minimum split panel size from 20 to 100, and
that fixed it. I can now really use the bigdemo! Woo-hoo!

Kevin



From wxruby at qualitycode.com  Sat Apr 29 16:43:48 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 16:43:48 -0400
Subject: [Wxruby-users] addr2line errors on console (was: ComboBox patch
	files)
In-Reply-To: <1146341105.17322.9.camel@localhost.localdomain>
References: <444BB4A7.9030100@mindspring.com>
	<1146341105.17322.9.camel@localhost.localdomain>
Message-ID: <1146343428.17322.24.camel@localhost.localdomain>

On Sat, 2006-04-29 at 16:05 -0400, Kevin Smith wrote:
> After selecting the "Really" item, about 30 mysterious debug statement
> showed up on the console, and then the standard wx "oops" dialog
> appeared offering to terminate the app.

Ok. This is a bigger issue. Even after removing those patches, I have
seen this behavior a few times. Generally in bigdemo after running it
for a while. Suddenly I get this cascade of errors, and then the wx
crashed-app dialog. Now, the errors are usually:

addr2line: 'wxruby': No such file
addr2line: 'wxruby': No such file
addr2line: 'wxruby': No such file
addr2line: 'wxruby': No such file
addr2line: 'wxruby': No such file
addr2line: 'wxruby': No such file
addr2line: 'wxruby': No such file

I'm guessing they're coming from wx, but a quick yahoo search of the web
didn't reveal anything. If anyone has any ideas what's going on, I would
appreciate it. My best guess at this point is that our object management
is resulting in a bad wx pointer being sent to wx, and it is asserting
and then failing as a result.

Kevin

P.S. The ComboBox patch was still directly responsible for the controls
sample misbehaving, so I'm still not ready to commit it as-is.



From sdate at everestkc.net  Sat Apr 29 16:50:20 2006
From: sdate at everestkc.net (Shashank Date)
Date: Sat, 29 Apr 2006 15:50:20 -0500
Subject: [Wxruby-users] Patches for object tracking
In-Reply-To: <1146343207.17322.19.camel@localhost.localdomain>
References: <444BB920.9050502@mindspring.com>
	<1145927418.25718.17.camel@localhost.localdomain>
	<1146339866.17322.3.camel@localhost.localdomain>
	<4453C666.1070909@mindspring.com>
	<1146341727.17322.16.camel@localhost.localdomain>
	<1146343207.17322.19.camel@localhost.localdomain>
Message-ID: <4453D18C.7020106@everestkc.net>

Hi Kevin,

Kevin Smith wrote:

>On Sat, 2006-04-29 at 16:15 -0400, Kevin Smith wrote:
>  
>
> I can now really use the bigdemo! Woo-hoo!
>  
>

Cool! For spectators like me, who are eagerly waiting to dig their hands 
in writing GUI applications using wxruby2, how far are we from getting a 
preview release?

Million Thanks for all the hard work you guys are putting in :-)

-- Shashank



From roys at mindspring.com  Sat Apr 29 16:51:22 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sat, 29 Apr 2006 16:51:22 -0400
Subject: [Wxruby-users] Patches for object tracking
In-Reply-To: <1146343207.17322.19.camel@localhost.localdomain>
References: <444BB920.9050502@mindspring.com>	<1145927418.25718.17.camel@localhost.localdomain>	<1146339866.17322.3.camel@localhost.localdomain>	<4453C666.1070909@mindspring.com>	<1146341727.17322.16.camel@localhost.localdomain>
	<1146343207.17322.19.camel@localhost.localdomain>
Message-ID: <4453D1CA.40102@mindspring.com>

Kevin Smith wrote:
> On Sat, 2006-04-29 at 16:15 -0400, Kevin Smith wrote:
>   
>> Of course, for me, bigdemo still has the splitter problem. I'll take a
>> look at that myself this afternoon.
>>     
>
> Fixed. Turns out the default splitter location was so high that it was
> underneath the notebook tabs. So I couldn't grab it with the mouse to
> resize it. I changed the minimum split panel size from 20 to 100, and
> that fixed it. I can now really use the bigdemo! Woo-hoo!
Great!  This reminds me of another problem I see.  On Windows, all the 
drop-downs (combo box, listbox) don't drop down far enough to reveal 
their contents.  It appears that the size of the control is set such 
that it specifies the max height for the control when it's expanded.  Is 
this a bug in wxWindows?  Is this bug only visible on Windows or does it 
happen elsewhere, too?  I saw a bug in the wxWindows bug tracker related 
to problems with putting combos on resizable items, perhaps it's related.

Roy

From roys at mindspring.com  Sat Apr 29 17:08:30 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sat, 29 Apr 2006 17:08:30 -0400
Subject: [Wxruby-users] addr2line errors on console
In-Reply-To: <1146343428.17322.24.camel@localhost.localdomain>
References: <444BB4A7.9030100@mindspring.com>	<1146341105.17322.9.camel@localhost.localdomain>
	<1146343428.17322.24.camel@localhost.localdomain>
Message-ID: <4453D5CE.30607@mindspring.com>

Kevin Smith wrote:
> P.S. The ComboBox patch was still directly responsible for the controls
> sample misbehaving, so I'm still not ready to commit it as-is.
Hmm...  I haven't been using the controls sample.  I don't recall it 
working correctly for me.  However, a new problem has cropped up when I 
tried to run it.  With Alex's patch to include the typemaps.i file we 
now have a conflict between the two GetSize methods for Frames and the 
like.  Python renames the second to GetSizeTuple, Perl to GetSizeWH.  
How do you feel about get_size_array?  Or, we could just ignore the 2nd 
one.  I don't see much use to it if we've got the wxSize one.

From wxruby at qualitycode.com  Sat Apr 29 17:22:37 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 17:22:37 -0400
Subject: [Wxruby-users] Fixes for ListControl
In-Reply-To: <444BBAAD.9050603@mindspring.com>
References: <444BBAAD.9050603@mindspring.com>
Message-ID: <1146345757.17322.26.camel@localhost.localdomain>

On Sun, 2006-04-23 at 13:34 -0400, Roy Sutton wrote:
> These patches fix the ListCtrl_virtual demo.  Note I changed the loading 
> of the icon to the loading of a bitmap.  I remember discussing this 
> before.  For some reason the .xpm loader isn't initialized properly for 
> Wx::Icon.  However, the function will take a bitmap just fine so this 
> works.  This also adds directors for wxListItem and wxListEvent

Committed. Thanks!

Kevin



From wxruby at qualitycode.com  Sat Apr 29 17:26:16 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 17:26:16 -0400
Subject: [Wxruby-users] addr2line errors on console
In-Reply-To: <1146343428.17322.24.camel@localhost.localdomain>
References: <444BB4A7.9030100@mindspring.com>
	<1146341105.17322.9.camel@localhost.localdomain>
	<1146343428.17322.24.camel@localhost.localdomain>
Message-ID: <1146345976.17322.31.camel@localhost.localdomain>

On Sat, 2006-04-29 at 16:43 -0400, Kevin Smith wrote:
> Ok. This is a bigger issue. Even after removing those patches, I have
> seen this behavior a few times. Generally in bigdemo after running it
> for a while. Suddenly I get this cascade of errors, and then the wx
> crashed-app dialog. Now, the errors are usually:
> 
> addr2line: 'wxruby': No such file

I figured out that wx has a failing Assert, which was attempting to walk
the stack, but since our (faked) app name is 'wxruby', when the walker
invoked an external utility named addr2line, it couldn't find the
executable file, causing those errors.

I changed App to override OnAssert, and it now throws a Ruby fatal
exception, after printing out the basic information about the cause of
the assertion failure.

Which shows me that my patch earlier today to handle those internal Qnil
objects isn't good enough. Most of the asserts I'm seeing appear to be
related. We (I?) need to figure out why those internal values are not
being set correctly by the object tracking code. Or why they are being
cleared. Or why we are looking at the wrong object entirely. Or whatever
it is that's going on.

Kevin



From wxruby at qualitycode.com  Sat Apr 29 17:29:35 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 17:29:35 -0400
Subject: [Wxruby-users] get_size (was: Re:  addr2line errors on console)
In-Reply-To: <4453D5CE.30607@mindspring.com>
References: <444BB4A7.9030100@mindspring.com>
	<1146341105.17322.9.camel@localhost.localdomain>
	<1146343428.17322.24.camel@localhost.localdomain>
	<4453D5CE.30607@mindspring.com>
Message-ID: <1146346175.17322.35.camel@localhost.localdomain>

On Sat, 2006-04-29 at 17:08 -0400, Roy Sutton wrote:
> With Alex's patch to include the typemaps.i file we 
> now have a conflict between the two GetSize methods for Frames and the 
> like.  Python renames the second to GetSizeTuple, Perl to GetSizeWH.  
> How do you feel about get_size_array?  Or, we could just ignore the 2nd 
> one.  I don't see much use to it if we've got the wxSize one.

For now, and possibly forever, I'm fine only supporting the wxSize
get_size method.

Kevin



From wxruby at qualitycode.com  Sat Apr 29 17:36:49 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 17:36:49 -0400
Subject: [Wxruby-users] How close to preview release? (was: Patches for
	object tracking)
In-Reply-To: <4453D18C.7020106@everestkc.net>
References: <444BB920.9050502@mindspring.com>
	<1145927418.25718.17.camel@localhost.localdomain>
	<1146339866.17322.3.camel@localhost.localdomain>
	<4453C666.1070909@mindspring.com>
	<1146341727.17322.16.camel@localhost.localdomain>
	<1146343207.17322.19.camel@localhost.localdomain>
	<4453D18C.7020106@everestkc.net>
Message-ID: <1146346609.17322.43.camel@localhost.localdomain>

On Sat, 2006-04-29 at 15:50 -0500, Shashank Date wrote:
> Cool! For spectators like me, who are eagerly waiting to dig their hands 
> in writing GUI applications using wxruby2, how far are we from getting a 
> preview release?

It's a bit hard to tell. We are still working through several odd
problems that came up with the switch to SWIG 1.3.29 and wx 2.6.3.
Things are definitely better than they were a few days ago, so with luck
we might restabilize this weekend. If so, a preview release could happen
as early as next weekend.

On the other hand, with bad luck, we might be many weeks from something
stable and usable.

> Million Thanks for all the hard work you guys are putting in :-)

Thanks for the encouragement. And I'll second your thanks to Alex and
(especially) Roy, since they are really doing most of the work these
days. My role at the moment is mostly just applying patches, which is
fantastic!

Kevin



From wxruby at qualitycode.com  Sat Apr 29 17:39:33 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 17:39:33 -0400
Subject: [Wxruby-users] Patches for object tracking
In-Reply-To: <4453D1CA.40102@mindspring.com>
References: <444BB920.9050502@mindspring.com>
	<1145927418.25718.17.camel@localhost.localdomain>
	<1146339866.17322.3.camel@localhost.localdomain>
	<4453C666.1070909@mindspring.com>
	<1146341727.17322.16.camel@localhost.localdomain>
	<1146343207.17322.19.camel@localhost.localdomain>
	<4453D1CA.40102@mindspring.com>
Message-ID: <1146346773.17322.46.camel@localhost.localdomain>

On Sat, 2006-04-29 at 16:51 -0400, Roy Sutton wrote:
> On Windows, all the drop-downs (combo box, listbox) don't drop down 
> far enough to reveal their contents.  It appears that the size of the 
> control is set such that it specifies the max height for the control 
> when it's expanded.  

ComboBoxes look perfect to me (on Linux), in both the controls.rb and
bigdemo samples.

Kevin



From wxruby at qualitycode.com  Sat Apr 29 17:44:38 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 17:44:38 -0400
Subject: [Wxruby-users] MenuBar DISOWN (was: Patches for some object
	tracking)
In-Reply-To: <444BBB59.5090105@mindspring.com>
References: <444BBB59.5090105@mindspring.com>
Message-ID: <1146347078.17322.49.camel@localhost.localdomain>

On Sun, 2006-04-23 at 13:37 -0400, Roy Sutton wrote:
> The following two patches (theoretically) tell Ruby that it no longer 
> owns menu items after they have been attached to a frame.  We'll need 
> several more of these DISOWN typemaps as we get further into this.

I don't really understand what these are doing, but they have been
committed.

Kevin



From wxruby at qualitycode.com  Sat Apr 29 18:18:33 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 18:18:33 -0400
Subject: [Wxruby-users] *INPUT/*OUTPUT params patches
In-Reply-To: <444BBC44.5020303@pressure.to>
References: <444BBC44.5020303@pressure.to>
Message-ID: <1146349114.17322.51.camel@localhost.localdomain>

On Sun, 2006-04-23 at 18:41 +0100, Alex Fenton wrote:
> The attached patches enable the use of SWIG's *INPUT *OUTPUT and *INOUT 
> typemaps as described in the manual. It's done by including SWIG's own 
> 'typemaps.i' file so it'll allow us to benefit from future upgrades to that.

Cool. Checked in.

Roy--did you mention that this caused other problems? I haven't seen
them yet, but would like to know if there are some.

Kevin



From roys at mindspring.com  Sat Apr 29 18:22:14 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sat, 29 Apr 2006 18:22:14 -0400
Subject: [Wxruby-users] MenuBar DISOWN
In-Reply-To: <1146347078.17322.49.camel@localhost.localdomain>
References: <444BBB59.5090105@mindspring.com>
	<1146347078.17322.49.camel@localhost.localdomain>
Message-ID: <4453E716.3070708@mindspring.com>

Kevin Smith wrote:
> On Sun, 2006-04-23 at 13:37 -0400, Roy Sutton wrote:
>   
>> The following two patches (theoretically) tell Ruby that it no longer 
>> owns menu items after they have been attached to a frame.  We'll need 
>> several more of these DISOWN typemaps as we get further into this.
>>     
>
> I don't really understand what these are doing, but they have been
> committed.
It'll be important to understand what this does as we move forwards.  
DISOWN tells SWIG that the underlying object we just sent to C++ no 
longer belongs to us and we shouldn't free it (say, when the object goes 
out of scope).  Any function that takes an object that will no longer be 
freed by the calling program should be marked with DISOWN.  This is in 
contrast to items that wx uses but never frees or uses by making copies 
of when it gets it.


Roy

P.S.  That's my understanding anyway.  I could be completely wrong. :)

From wxruby at qualitycode.com  Sat Apr 29 20:22:27 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 20:22:27 -0400
Subject: [Wxruby-users] typedefs.i.patch
In-Reply-To: <4450EA29.1040400@mindspring.com>
References: <4450EA29.1040400@mindspring.com>
Message-ID: <1146356548.17322.53.camel@localhost.localdomain>

On Thu, 2006-04-27 at 11:58 -0400, Roy Sutton wrote:
> Missing piece for the textctrl.rb sample
> 
> Roy
> plain text document attachment (typedefs.i.patch)

Done.

Kevin



From wxruby at qualitycode.com  Sat Apr 29 20:23:00 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 20:23:00 -0400
Subject: [Wxruby-users] Wx::Window#get_text_extent patch
In-Reply-To: <444DE7D4.9080001@pressure.to>
References: <444BBF3F.2040602@pressure.to> <444DA9DA.5000309@mindspring.com>
	<444DE7D4.9080001@pressure.to>
Message-ID: <1146356580.17322.55.camel@localhost.localdomain>

On Tue, 2006-04-25 at 10:11 +0100, Alex Fenton wrote:
> > I meant to mention there are typemaps for that call in typemap.i.  
> > Perhaps we should update that one instead?
> >   
> see attached

Applied. Thanks.

Kevin



From wxruby at qualitycode.com  Sat Apr 29 20:25:31 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 20:25:31 -0400
Subject: [Wxruby-users] *INPUT/*OUTPUT params patches
In-Reply-To: <1146349114.17322.51.camel@localhost.localdomain>
References: <444BBC44.5020303@pressure.to>
	<1146349114.17322.51.camel@localhost.localdomain>
Message-ID: <1146356732.17322.59.camel@localhost.localdomain>

On Sat, 2006-04-29 at 18:18 -0400, Kevin Smith wrote:
> On Sun, 2006-04-23 at 18:41 +0100, Alex Fenton wrote:
> > The attached patches enable the use of SWIG's *INPUT *OUTPUT and *INOUT 
> > typemaps as described in the manual. It's done by including SWIG's own 
> > 'typemaps.i' file so it'll allow us to benefit from future upgrades to that.
> 
> Cool. Checked in.
> 
> Roy--did you mention that this caused other problems? I haven't seen
> them yet, but would like to know if there are some.

Ah. I found them for myself. SWIG was warning about several cases of
methods shadowing other variations, as in the two versions of GetText. I
%ignore'd all of those.

I also had to %ignore a couple methods that we probably want to keep:
GetTextExtent and GetMultiLineTextExtent.

Finally, there are still quite a few SWIG warnings for methods that are
shadowing themselves, due to some weird interaction between the typemaps
and optional variables. 

Hopefully one of you can take a look at these remaining problems and
submit some fixes.

Thanks,

Kevin



From wxruby at qualitycode.com  Sat Apr 29 20:44:10 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 20:44:10 -0400
Subject: [Wxruby-users] Patch for wxToolBar.rbw
In-Reply-To: <444C1E5D.3050901@mindspring.com>
References: <444C1E5D.3050901@mindspring.com>
Message-ID: <1146357850.17322.61.camel@localhost.localdomain>

On Sun, 2006-04-23 at 20:39 -0400, Roy Sutton wrote:
> This patch fixes the toolbar in bigdemo

Got it. Thanks.

Kevin



From roys at mindspring.com  Sat Apr 29 20:51:25 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sat, 29 Apr 2006 20:51:25 -0400
Subject: [Wxruby-users] *INPUT/*OUTPUT params patches
In-Reply-To: <1146356732.17322.59.camel@localhost.localdomain>
References: <444BBC44.5020303@pressure.to>	<1146349114.17322.51.camel@localhost.localdomain>
	<1146356732.17322.59.camel@localhost.localdomain>
Message-ID: <44540A0D.7030309@mindspring.com>

Kevin Smith wrote:
> Ah. I found them for myself. SWIG was warning about several cases of
> methods shadowing other variations, as in the two versions of GetText. I
> %ignore'd all of those.
>
> I also had to %ignore a couple methods that we probably want to keep:
> GetTextExtent and GetMultiLineTextExtent.
>
> Finally, there are still quite a few SWIG warnings for methods that are
> shadowing themselves, due to some weird interaction between the typemaps
> and optional variables. 
>
> Hopefully one of you can take a look at these remaining problems and
> submit some fixes.
>   
Kevin,

Are all submitted patches checked in?  If so, I'll grab the latest and 
compare with my directory.  I have several 'work in process' items.  I 
added the compactdefaultargs options as suggested by Daniel Savarese and 
saw only improvements from that.  I am recompiling right now as we speak 
with -fvirtual added to the SWIG options.  I don't suspect we'll have 
problems with that, in fact, I think it'll make some wrapping easier as 
we won't have to apply typemaps in multiple files.

Roy

From wxruby at qualitycode.com  Sat Apr 29 21:01:13 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 21:01:13 -0400
Subject: [Wxruby-users] StaticBoxSizer bug?
In-Reply-To: <444C4D5B.6060801@mindspring.com>
References: <200604240111.k3O1BgPK013682@gandalf.savarese.org>
	<444C4D5B.6060801@mindspring.com>
Message-ID: <1146358873.17322.69.camel@localhost.localdomain>

On Mon, 2006-04-24 at 00:00 -0400, Roy Sutton wrote:
> Daniel F. Savarese wrote:
> > After that, I realized the overridden virtual method was missing in
> > wxStaticBoxSizer.h.  I've attached a patch.
> >   
> The patch didn't apply for me.  I have created a new patch for the two 
> affected files.

The follow-up patches didn't look right to me, as they were missing the
"virtual" keyword in some cases. So I took a mix of Daniel's original
patch and your two patches, and hopefully ended up with something great.
A special thanks to Daniel, not only for the patch, but for submitting a
great problem report with sample code. Definitely makes my job easier!

> > Now that I've spent enough time getting familiar with the way the
> > code is generated, I'm left wondering if there's an alternative to
> > maintaining custom wxFoo.h headers.  Is there a way to generate them
> > from existing wxWidgets headers?  It seems error prone and a lot of
> > work to maintain a separate set of headers.  I'm probably just
> > revealing my general ignorance of SWIG.

Not at all. The biggest problem in trying to SWIG the wx headers
directly is that wx is a complex cross-platform app. They actually have
a set of shared headers, and then a whole large set of headers for each
platform. The only way I could see that it might work would be to swig
each platform's set of headers separately, but I'm afraid that would
minimize our ability to fix bugs in one place to benefit all platforms.

The best short-term answer would probably be to build a comprehensive
test suite.

In my perfect world, the creators of all the wx wrappers for all the
languages (python, ruby, lua, etc) would work together to create one
perfect set of wx .h files. I haven't actively contacted those other
maintainers to see if there is any interest. But if I create bindings
for Io someday, at least I'll have good swiggable wx .h files to start
from.

Kevin



From sdate at everestkc.net  Sat Apr 29 22:07:35 2006
From: sdate at everestkc.net (Shashank Date)
Date: Sat, 29 Apr 2006 21:07:35 -0500
Subject: [Wxruby-users] How close to preview release?
In-Reply-To: <1146346609.17322.43.camel@localhost.localdomain>
References: <444BB920.9050502@mindspring.com>
	<1145927418.25718.17.camel@localhost.localdomain>
	<1146339866.17322.3.camel@localhost.localdomain>
	<4453C666.1070909@mindspring.com>
	<1146341727.17322.16.camel@localhost.localdomain>
	<1146343207.17322.19.camel@localhost.localdomain>
	<4453D18C.7020106@everestkc.net>
	<1146346609.17322.43.camel@localhost.localdomain>
Message-ID: <44541BE7.6080006@everestkc.net>

Kevin Smith wrote:

>On the other hand, with bad luck, we might be many weeks from something
>stable and usable.
>  
>

Wish you the best of luck!

-- Shashank

From wxruby at qualitycode.com  Sat Apr 29 22:42:47 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 22:42:47 -0400
Subject: [Wxruby-users] -fvirtual and compactdefaultargs
	(was	StaticBoxSizer bug?)
In-Reply-To: <200604242112.k3OLCAT7032209@gandalf.savarese.org>
References: <200604242112.k3OLCAT7032209@gandalf.savarese.org>
Message-ID: <1146364967.17322.79.camel@localhost.localdomain>

On Mon, 2006-04-24 at 17:12 -0400, Daniel F. Savarese wrote:
> If the convention for wxruby2 patch submissions is to generate them 
> from a level above the source tree, I can do that in the future.  

It is. I am accustomed to using -p1 because some tool I used a while
back only accepted patches in that form.

> Is the mailing list the preferred patch submission medium?  

Yes, for now. As Roy mentioned, there is a darcs mirror, and I have
accepted some darcs patches in the past. I'm not that fond of darcs, but
it is the most stable distributed RCS tool out there. I still hope to
switch wxruby to bzr at some point, but that is probably at least six
months away.

> How do people feel about adding -fvirtual to swig_options in
> rake/rakewx.rb to eliminate redundant wrapper generation?  
(snip)
> Also, how about using %feature("compactdefaultargs") across the board 

Sounds good to me. I rebuilt everything, and quick testing seemed to
show that nothing had become worse (or better). It cut the src directory
by about 2 megs, the obj directory by about 4 megs, and the resulting
wxruby2.so library by about 2 megs.

Thanks!

Kevin



From wxruby at qualitycode.com  Sat Apr 29 22:47:27 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 22:47:27 -0400
Subject: [Wxruby-users] *INPUT/*OUTPUT params patches
In-Reply-To: <44540A0D.7030309@mindspring.com>
References: <444BBC44.5020303@pressure.to>
	<1146349114.17322.51.camel@localhost.localdomain>
	<1146356732.17322.59.camel@localhost.localdomain>
	<44540A0D.7030309@mindspring.com>
Message-ID: <1146365248.17322.84.camel@localhost.localdomain>

On Sat, 2006-04-29 at 20:51 -0400, Roy Sutton wrote:
> Are all submitted patches checked in?  

As of this moment, I think all the submitted patches have been checked
in except:
- The ComboBox/ControlWithItems stuff I didn't accept
- "XP-Style widgets in wxruby"
- "Major Breakthrough"

It's time for me to go to bed now, but I hope to do the rest (and
anything you send me overnight) tomorrow.

Thanks,

Kevin



From wxruby at qualitycode.com  Sat Apr 29 22:49:34 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sat, 29 Apr 2006 22:49:34 -0400
Subject: [Wxruby-users] ListItem patches
In-Reply-To: <4428840D.8030008@pressure.to>
References: <4428840D.8030008@pressure.to>
Message-ID: <1146365374.17322.87.camel@localhost.localdomain>

Alex,

I know I added ListItem earlier tonight, but not from these patches.

Can you let me know if some or all of this should still be applied, or
if it's now stale?

Thanks/sorry,

Kevin



On Tue, 2006-03-28 at 01:32 +0100, Alex Fenton wrote:
> Hi
> 
> Attached, patches to implement ListItem. This class, in wxruby 0.6.0, allows styling of individual items in a ListCtrl, via a particularly clunky API. In disambiguating the overloaded ListCtrl#set_item method it introduces one non backwards-compatible change. I've followed the WxPython convention as described in the Wx class ref, renaming set_item(index, col, string, imageid) to set_item_string.
> 
> One thing that doesn't work is the constants LIST_FORMAT_LEFT etc. I'm not sure if it's the same problem I'm seeing with some other groups of constants since upgrading to SWIG 1.3.29, but constants declarations like
> 
> enum wxListColumnFormat {
> ....
> enum wxSystemColour {
> ...
> 
> seem to be broken.
> 
> Lastly, would it be possible and desirable to move class-specific constants (like TE_xxx, SYS_xxx, LIST_xxx, NB_xxx etc) from RubyConstants.i to the relevant .i file in swig/classes? Nothing urgent, just a suggestion as RubyConstants.i is getting unwieldy.
> 
> alex
> plain text document attachment (RubyConstants.patch)
> Index: wxruby2/swig/RubyConstants.i
> ===================================================================
> RCS file: /var/cvs/wxruby/wxruby2/swig/RubyConstants.i,v
> retrieving revision 1.18
> diff -b -u -r1.18 RubyConstants.i
> --- wxruby2/swig/RubyConstants.i	29 Nov 2005 00:48:20 -0000	1.18
> +++ wxruby2/swig/RubyConstants.i	28 Mar 2006 00:20:15 -0000
> @@ -14,6 +14,7 @@
>  #include <wx/calctrl.h>
>  #include <wx/treebase.h>
>  #include <wx/imaglist.h>
> +#include <wx/listbase.h>
>  
>  //
>  // All of these exist on only one platform, so in those
> @@ -1480,6 +1481,92 @@
>  
>  // for compatibility only
>  #define wxLC_USER_TEXT       wxLC_VIRTUAL
> +#define wxLIST_MASK_STATE           0x0001
> +#define wxLIST_MASK_TEXT            0x0002
> +#define wxLIST_MASK_IMAGE           0x0004
> +#define wxLIST_MASK_DATA            0x0008
> +#define wxLIST_SET_ITEM             0x0010
> +#define wxLIST_MASK_WIDTH           0x0020
> +#define wxLIST_MASK_FORMAT          0x0040
> +
> +// State flags for indicating the state of an item
> +#define wxLIST_STATE_DONTCARE       0x0000
> +#define wxLIST_STATE_DROPHILITED    0x0001      // MSW only
> +#define wxLIST_STATE_FOCUSED        0x0002
> +#define wxLIST_STATE_SELECTED       0x0004
> +#define wxLIST_STATE_CUT            0x0008      // MSW only
> +#define wxLIST_STATE_DISABLED       0x0010      // OS2 only
> +#define wxLIST_STATE_FILTERED       0x0020      // OS2 only
> +#define wxLIST_STATE_INUSE          0x0040      // OS2 only
> +#define wxLIST_STATE_PICKED         0x0080      // OS2 only
> +#define wxLIST_STATE_SOURCE         0x0100      // OS2 only
> +
> +// Hit test flags, used in HitTest
> +#define wxLIST_HITTEST_ABOVE            0x0001  // Above the client area.
> +#define wxLIST_HITTEST_BELOW            0x0002  // Below the client area.
> +#define wxLIST_HITTEST_NOWHERE          0x0004  // In the client area but below the last item.
> +#define wxLIST_HITTEST_ONITEMICON       0x0020  // On the bitmap associated with an item.
> +#define wxLIST_HITTEST_ONITEMLABEL      0x0080  // On the label (string) associated with an item.
> +#define wxLIST_HITTEST_ONITEMRIGHT      0x0100  // In the area to the right of an item.
> +#define wxLIST_HITTEST_ONITEMSTATEICON  0x0200  // On the state icon for a tree view item that is in a user-defined state.
> +#define wxLIST_HITTEST_TOLEFT           0x0400  // To the left of the client area.
> +#define wxLIST_HITTEST_TORIGHT          0x0800  // To the right of the client area.
> +
> +#define wxLIST_HITTEST_ONITEM (wxLIST_HITTEST_ONITEMICON | wxLIST_HITTEST_ONITEMLABEL | wxLIST_HITTEST_ONITEMSTATEICON)
> +
> +// Flags for GetNextItem (MSW only except wxLIST_NEXT_ALL)
> +enum
> +{
> +    wxLIST_NEXT_ABOVE,          // Searches for an item above the specified item
> +    wxLIST_NEXT_ALL,            // Searches for subsequent item by index
> +    wxLIST_NEXT_BELOW,          // Searches for an item below the specified item
> +    wxLIST_NEXT_LEFT,           // Searches for an item to the left of the specified item
> +    wxLIST_NEXT_RIGHT           // Searches for an item to the right of the specified item
> +};
> +
> +// Alignment flags for Arrange (MSW only except wxLIST_ALIGN_LEFT)
> +enum
> +{
> +    wxLIST_ALIGN_DEFAULT,
> +    wxLIST_ALIGN_LEFT,
> +    wxLIST_ALIGN_TOP,
> +    wxLIST_ALIGN_SNAP_TO_GRID
> +};
> +
> +// Column format (MSW only except wxLIST_FORMAT_LEFT)
> +enum wxListColumnFormat
> +{
> +    wxLIST_FORMAT_LEFT,
> +    wxLIST_FORMAT_RIGHT,
> +    wxLIST_FORMAT_CENTRE,
> +    wxLIST_FORMAT_CENTER = wxLIST_FORMAT_CENTRE
> +};
> +
> +// Autosize values for SetColumnWidth
> +enum
> +{
> +    wxLIST_AUTOSIZE = -1,
> +    wxLIST_AUTOSIZE_USEHEADER = -2      // partly supported by generic version
> +};
> +
> +// Flag values for GetItemRect
> +enum
> +{
> +    wxLIST_RECT_BOUNDS,
> +    wxLIST_RECT_ICON,
> +    wxLIST_RECT_LABEL
> +};
> +
> +// Flag values for FindItem (MSW only)
> +enum
> +{
> +    wxLIST_FIND_UP,
> +    wxLIST_FIND_DOWN,
> +    wxLIST_FIND_LEFT,
> +    wxLIST_FIND_RIGHT
> +};
> +
> +
>  
>  //** ---------------------------------------------------------------------------- **
>  //   Start constants from wx/button.h
> plain text document attachment (ListCtrl.patch)
> Index: wxruby2/swig/classes/ListCtrl.i
> ===================================================================
> RCS file: /var/cvs/wxruby/wxruby2/swig/classes/ListCtrl.i,v
> retrieving revision 1.6
> diff -b -u -r1.6 ListCtrl.i
> --- wxruby2/swig/classes/ListCtrl.i	21 Aug 2005 01:55:44 -0000	1.6
> +++ wxruby2/swig/classes/ListCtrl.i	28 Mar 2006 00:18:27 -0000
> @@ -3,12 +3,15 @@
>  
>  %include "../common.i"
>  
> +%module(directors="1") wxListCtrl
> +
> +%rename(SetItemString) wxListCtrl::SetItem(long index, int col, const wxString& label, int imageId = -1);
> +
>  %{
>  #include <wx/wx.h>
>  #include <wx/listctrl.h>
>  %}
>  
> -%module(directors="1") wxListCtrl
>  
>  %ignore wxListCtrl::wxListCtrl();
>  //
> @@ -21,6 +24,7 @@
>  
> 
> 
> +
>  %import "include/wxObject.h"
>  %import "include/wxEvtHandler.h"
>  %import "include/wxWindow.h"
> plain text document attachment (ListItem.i)
> #   Copyright 2004-2005 by Kevin Smith
> #   released under the MIT-style wxruby2 license
> 
> %include "../common.i"
> 
> %{
> #include <wx/wx.h>
> #include <wx/listctrl.h>
> #include <wx/listbase.h>
> %}
> 
> %module(directors="1") wxListItem
> %ignore wxListItem::GetText;
> 
> 
> %import "include/wxObject.h"
> 
> 
> %include "include/wxListItem.h"
> 
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users


From roys at mindspring.com  Sat Apr 29 23:59:39 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sat, 29 Apr 2006 23:59:39 -0400
Subject: [Wxruby-users] StaticBoxSizer bug?
In-Reply-To: <1146358873.17322.69.camel@localhost.localdomain>
References: <200604240111.k3O1BgPK013682@gandalf.savarese.org>	<444C4D5B.6060801@mindspring.com>
	<1146358873.17322.69.camel@localhost.localdomain>
Message-ID: <4454362B.2050800@mindspring.com>

Kevin Smith wrote:
> The follow-up patches didn't look right to me, as they were missing the
> "virtual" keyword in some cases. So I took a mix of Daniel's original
> patch and your two patches, and hopefully ended up with something great.
I left off virtual on purpose because the actual wx header files don't 
have them.

Roy

From roys at mindspring.com  Sun Apr 30 01:17:34 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sun, 30 Apr 2006 01:17:34 -0400
Subject: [Wxruby-users] Error in controls.rb
Message-ID: <4454486E.3050503@mindspring.com>

Anyone else seeing this error when clicking on the radiobox page?

undefined method `' for #<MyRadioBox:0x2d6c0c0>

Roy

From wxruby at qualitycode.com  Sun Apr 30 01:25:11 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sun, 30 Apr 2006 01:25:11 -0400
Subject: [Wxruby-users] Error in controls.rb
In-Reply-To: <4454486E.3050503@mindspring.com>
References: <4454486E.3050503@mindspring.com>
Message-ID: <1146374712.8512.26.camel@localhost.localdomain>

On Sun, 2006-04-30 at 01:17 -0400, Roy Sutton wrote:
> Anyone else seeing this error when clicking on the radiobox page?
> 
> undefined method `' for #<MyRadioBox:0x2d6c0c0>

That sounds similar to the crashing problem I'm seeing all over the
place. Try commenting out the fixmodule.rb line that I just added today
(that adds ?: protection to a variable assignment). Re-swig (probably
just RadioBox), and you may get a segfault instead of what you're
seeing.

That would be great, from my perspective, because a) I wouldn't be the
only one seeing this problem, and b) it might give us a(nother) reliable
way to reproduce it.

Kevin



From roys at mindspring.com  Sun Apr 30 01:36:47 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sun, 30 Apr 2006 01:36:47 -0400
Subject: [Wxruby-users] Error in controls.rb
In-Reply-To: <1146374712.8512.26.camel@localhost.localdomain>
References: <4454486E.3050503@mindspring.com>
	<1146374712.8512.26.camel@localhost.localdomain>
Message-ID: <44544CEF.80504@mindspring.com>

Kevin Smith wrote:
> On Sun, 2006-04-30 at 01:17 -0400, Roy Sutton wrote:
>   
>> Anyone else seeing this error when clicking on the radiobox page?
>>
>> undefined method `' for #<MyRadioBox:0x2d6c0c0>
>>     
>
> That sounds similar to the crashing problem I'm seeing all over the
> place. Try commenting out the fixmodule.rb line that I just added today
> (that adds ?: protection to a variable assignment). Re-swig (probably
> just RadioBox), and you may get a segfault instead of what you're
> seeing.
>
> That would be great, from my perspective, because a) I wouldn't be the
> only one seeing this problem, and b) it might give us a(nother) reliable
> way to reproduce it.
>   
Well, I was seeing this problem with my build, too.  Since you hadn't 
mentioned you had it I thought maybe it was a Windows-specific problem.  
I went and finally discovered the wx samples directory and tried out the 
C++ version of the combo box demo.  It works fine there so I'm going to 
have to start tracking down why the Windows wxRuby wrapper is mussing it 
up.  I'm probably going to re-check my combo box and re-submit it.  
Combo boxes just crash under windows for me with the checked in code.

Roy

P.S.  I thought you were asleep? :)

From roys at mindspring.com  Sun Apr 30 02:15:59 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sun, 30 Apr 2006 02:15:59 -0400
Subject: [Wxruby-users] StaticBoxSizer bug?
In-Reply-To: <200604300607.k3U67XkY011181@gandalf.savarese.org>
References: <200604300607.k3U67XkY011181@gandalf.savarese.org>
Message-ID: <4454561F.6050608@mindspring.com>

Daniel F. Savarese wrote:
> Roy and Kevin, thanks for all of the answers and explanation.  I'm
> used to the way things work at Apache, so I wasn't sure what the
> development model was for wxruby2.  I'll try to pitch in with patches
> when and where I can, but it will probably come in a slow trickle.

Glad for any help we can get!  Pitch in when you can, we'll be grateful.

Roy

From sean.m.long at gmail.com  Sun Apr 30 02:41:13 2006
From: sean.m.long at gmail.com (Sean Long)
Date: Sat, 29 Apr 2006 23:41:13 -0700
Subject: [Wxruby-users] latest cvs head makes api more strongly typed
Message-ID: <c2cd0d1d0604292341r2255641dq88cc7d1741e482f7@mail.gmail.com>

In previous versions the following would work as you expect with a
dynamic language like Ruby.

Method signature of wxGrid::SetRowLabelSize
void SetRowLabelSize(int width)

ex.
gird = Wx::Grid.new(....)
grid.set_row_label_size(some_value*0.5)

which Ruby translates to
gird = Wx::Grid.new(....)
grid.set_row_label_size((some_value*0.5).to_i)


In the latest cvs head you get this error:
`set_row_label_size': in method 'SetRowLabelSize', argument 2 of type
'int' (TypeError)

Basically the implicit conversion is not longer done and now has to be
explicitly done in code, ie (...).to_i


I have been way to busy lately to keep up with all the great work
going on, but I do try a build here and there.

Roy, Alex and Kevin keep up the great work

Hopefully I will be able to contribute again soon

Sean


From wxruby at qualitycode.com  Sun Apr 30 10:33:41 2006
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sun, 30 Apr 2006 10:33:41 -0400
Subject: [Wxruby-users] StaticBoxSizer bug?
In-Reply-To: <200604300607.k3U67XkY011181@gandalf.savarese.org>
References: <200604300607.k3U67XkY011181@gandalf.savarese.org>
Message-ID: <1146407621.8424.7.camel@localhost.localdomain>

On Sun, 2006-04-30 at 02:07 -0400, Daniel F. Savarese wrote:
> This is one of those style issues that's hard to argue convincingly one
> way or another.  I recommend always redeclaring overridden virtual methods
> as virtual so it's obvious to the human reader they are virtual without
> having to navigate the trail of ancestor classes.  

I agree.

> Of course, the compiler doesn't care one way or another :)  

Actually, there may be cases where SWIG doesn't have access to the
parent class. In those cases, it is critical that virtual is
re-declared.

> Roy and Kevin, thanks for all of the answers and explanation.  I'm
> used to the way things work at Apache, so I wasn't sure what the
> development model was for wxruby2.  I'll try to pitch in with patches
> when and where I can, but it will probably come in a slow trickle.

Cool.

Kevin



From roys at mindspring.com  Sun Apr 30 16:11:00 2006
From: roys at mindspring.com (Roy Sutton)
Date: Sun, 30 Apr 2006 16:11:00 -0400
Subject: [Wxruby-users] Bigdemo problem
Message-ID: <445519D4.7040806@mindspring.com>

One of the recent changes causes Bigdemo's first dialog box (the tip of 
the day) to not be visible on the screen.  I seem to have this problem 
now on my branch, too.  You have to close the (hidden) window to get the 
demo to open.  I'll try tracking this down today.  Mighty perplexing.