From mario at ruby-im.net  Sun Jul  1 08:38:09 2007
From: mario at ruby-im.net (Mario Steele)
Date: Sun, 01 Jul 2007 07:38:09 -0500
Subject: [Wxruby-development] Splitting wxRuby2.so into multiple
	libraries
In-Reply-To: <4684CB52.8000205@pressure.to>
References: <op.tukl86mq53rrhy@compaq.gateway.2wire.net>
	<4684CB52.8000205@pressure.to>
Message-ID: <op.tusddvck53rrhy@compaq.gateway.2wire.net>

On Fri, 29 Jun 2007 04:05:22 -0500, Alex Fenton <alex at pressure.to> wrote:

> Hi Mario
>
> Mario Steele wrote:
>> I figured I'd split this off into a seperate discussion, to get an idea  
>> of
>> what to look at with this.  Ofcourse, with every first step, there needs
>> to be some kind of outline set forth to split up wxRuby2 into multiple
>> libraries,
> Thanks for this - they're useful notes and I agree with most of what
> you've set out.

No problem, figure the first step with anything, is to start out with a  
plan.

>>  Also, as a side note, I think the splitting up of wxRuby2
>> into multiple files, to make it modular, will also encourage wrapping of
>> 3rd party controls that have been created for wxWidgets as well.
> That's a good point - I hadn't thought of this. One of wxWidget's
> strengths is the third party controls available.

Very much so.  GTK and Qt have the problem that they are pretty much set  
with the widgets they get with the library, unless you extend them  
yourself in your Ruby code, but wxWidgets has libraries for extended  
controls out there, that you can link to.  But right now, it's just not  
possible with wxRuby2.

>> The way that
>> it was split across the board, was there was a central file, to store  
>> the
>> main stuff needed for wxWidgets to work, you know, Memory Management,  
>> main
>> base classes to initialize the Application, so on and so forth.
> This corresponds to swig/wx.i + swig/App.i + swig/RubyConstants.i in  
> wxRuby

That's good to hear, atleast now we got most of the core work out of the  
way. LOL

>>  Then each
>> separate control would get it's own file for usage, and then a wrapper
>> type file that basically included all of these files, for thoes that  
>> just
>> want it to go, with one include/require.
>>
> I'd go for this, or we could bundle groups of related classes into
> compiled groups. The model for the loader wrapper file is lib/wx.rb
>
> One ruby feature that might be potentially very useful is 'autoload'.
> With this users could still only have to require 'wx', but other classes
> would be transparently loaded on demand when they were referenced by  
> code.

This would be a very useful tool, and would allow for some good hits, but  
at the same time, we need to be careful, incase that part isn't included  
for some reason, maybe a Wx::MessageDialog may be used in case of failure  
to find an associated library, instead of a simple crash, and burn case  
scenerio.  This is thinking way to far ahead, but it's a start none the  
less.

>>    This will have the main static link of wxWidgets to it, so that the  
>> API
>> can be exposed to other loaded modules, which can be dynamically loaded  
>> by
>> user request.  Also, in this file, it will contain the main definitions
>> for memory management between Ruby and wxWidgets, as well as the core
>> classes, such as Wx::App, Wx::Events, Wx::Timer, so on and so forth,
>> basically all the classes that do not have a graphical representation.
>>
>>
> (and also defining the autoloads for other classes, setting out where
> they are found).
>

Agreed again.

>>    A part to keep this from seperating into to many seperate files,  
>> Such as
>> one for Wx::Menu, Wx::ToolBar, so on and so forth, it would proabbly be
>> best, to include these classes in Wx::Frame, so as to keep things
>> centralized, and yet still have the modularity.  Seems a bit backwards,
>> but this way, central controls will still remain with the class that  
>> they
>> are used primarly for, and ensure no "Split into infinity" occurs.
>>
> Agreed. If you've compiled your own wxRuby, it's interesting to look at
> the obj/ directory sorted by size. The biggest is Grid.o, which along
> with the various Grid* events would make a large separate chunk.
> Similarly TextCtrl, TreeCtrl, ListCtrl, HtmlWindow and AuiNotebook,
> which are all heavyweights on that list and have a number of associated
> classes.
>
> The current rework of EvtHandler and the mapping of wx Events to ruby
> objects is one piece of the puzzle that will make it possible to load
> new event-firing classes once an App has started.
>

On windows here, only ever used the Binary distro's of wxRuby2.  But I  
wouldn't doubt the size of Object files created, mainly cause of the fact  
that when you compile the source code into object files, it's not stripped  
of the redundancy factor.  It statically links everything together, so  
that way, if it's missed in another file, it's still readily available.   
This is part of the reason why compile processes take so long.  The last  
part of the linking procedure, is on the final output of the DLL/SO, where  
it strips all recurring object code, if it's found in another file that's  
being linked into the dll/so first.  So yeah, tends to be alot of  
unnesscary bloat.  But at the same time, SWIG tends to add to the bloat  
to, as well as Ruby's includes, so there's some things that just cannot be  
avoided.

>> Now, the fun part of this all, is how to get the splitting of the files
>> setup, so that it can work together, and not cause redundancy in the  
>> core
>> of wxWidgets be within each seperate library that provides the
>> functionality for said control, and repeating what does not need to be
>> done.  This, I don't have an answer for, cause of two things.  One, I
>> don't know how far down you can break the wxWidgets library to just
>> provide access to these controls, and allow the "Shared Memory Space" of
>> the program, to allow other DLL/SO files to be able to access it.
>>
> Hehe - this is the fun part for me too. I don't know very much at all
> about linkers and linking. I really knew nothing but './configure; make;
> make install' about C++ and compiling before I got involved in wxRuby.

As you can tell from my previous statement, I have a working knowledge of  
C++ and compiling, beyond the quick build commands for './configure; make;  
make install'.  But at the same time, there's some things that elude me.   
In all experince, once a library is loaded into the Program's Memory  
space, all DLL/SO/Machine Code has access to the routines stored within  
that library.  Which is why Dynamic Link is such a popular thing.  All is  
really needed, is a handle to the library in question, in order to access  
it's functions, and ofcourse, handles to the functions within the library  
itself.  Which is why the dynamic link library protocol was created in the  
first place, so you didn't need to have a big executable, with everything  
inside of it, and you can have universal feel on different machines.

>> Secondly, I don't know how SWIG interface works, never worked with it,  
>> and
>> I hardly know C/C++ as it is, just enough to get by, and even then it's
>> troublesome at most.
> There's no doubt that SWIG is pretty complex, and learning a little C++
> has driven me to frustration at times. On the other hand, I'm hoping
> that recent changes have made the build process a bit more standard and
> straightforward.

Attempting to learn C/C++ is like learning to bash your head into a brick  
wall repeatedly and willingly.  You know it's going to hurt, you know it's  
going to be hard, but there's no way around it, so you go straight for  
it.  Part of the reason why I like the higher level langauges (AKA  
Interpreted langauges), cause they take alot of the complexity out of the  
programming.

>> One solution that I could think of, is to have
>> wxWidgets as it's own library, then Dynamically link to it, instead of
>> statically linking it into the wxRuby2 SO File.
>>
> I'm not necessarily against this, but I'm very keen that we keep wxRuby
> as a single-step install. Having to install the base GUI library first
> seems to be a source of confusion for new users of Qt and GTK, and not
> having to a perceived strength of wxRuby.
>
> Perhaps we could distribute a wxWidgets monolithic dll/bundle/so with
> the gems that is dynamically linked to?

I can understand that point of view as well, as it is the reason why I  
came back to wxWidgets when you guys started getting wxRuby2 out there.   
Ruby-Gnome2 is a very mature project, and there's alot of great support  
there, but at the same time, it requires the user to install this major  
runtime distrobution, and that tends to leave a bleak taste even in my  
mouth.  Don't like having to have my users download another 8 meg  
installer file, that's going to install a bunch of dll's and po files,  
just to run my 2 meg program.

But, at the same time, wxWidgets isn't as monolithic as GTK, or Qt.   
Thankfully, this is cause wxWidgets uses native libraries to the Operating  
System to make everything go.  And I like that about wxWidgets.  Last time  
I checked, the only two Operating Systems that seem to have more then one  
dll/so library to install, is wxMac and wxGTK.  But even then, I don't  
think it's that many files, nor is it that big.  Could be wrong though.  I  
think if we do go this route, then we could definatly set it up where  
there's a single gem file for wxRuby2, that the users already have  
wxWidgets installed, and then one for the, how shall I put it, "Dummy in  
training" install, for thoes who don't know anything better.

>> With this, I'm just laying out a basic idea of how to split these into
>> seperate parts, and see what people think.  If it's a good idea, if  
>> it's a
>> bad idea, what opinions you have, maybe you have a better way.
> As above, I broadly support all that you've suggested. In terms of
> timing, given that we're not 100% sure about the specifics of the
> linking bit in particular, I'm inclined to set this as an objective for
> wxRuby 2.2. I.e. aim to finish what we have now and release as a stable
> 2.0, and then break into pieces for the next minor release in a way
> that's compatible (eg using autoload).

I'm inclined to agree with you here.  The biggest obsticle for this, is  
ensuring that we don't have the full wxWidgets core library compiled into  
each seperate library that we split these off into.  The only thing that I  
can think of as of right now, is to break from the Static Linking, and go  
to the Dynamic Linking, which would allow us to keep the so/dll files  
small for the extensions in Ruby, while allowing a single DLL/SO file for  
the core wxWidgets to be used on the system.  While I'd love to have this  
for 2.0, I think 2.2 would be a more likely target for this objective.   
With 2.1 being the beta to break these down, and getting Sockets into the  
library.


I do know one thing though, it seems to me, that with a project like  
Ruby-Gnome2, they seem to seperate the files based apon what library they  
are working with, and they go the dynamic link route on it.  So I'm  
thinking we are proabbly going to need the same idea, only, instead of it  
being multiple dynamic link libraries that we are linking to, it's the  
same one.

Anyways, glad to hear you agree with what my thinking is on the subject.   
Anyone else is welcome to join in on this, cause there may be something me  
or Alex is missing on it.  Who knows.

L8ers,
Mario Steele

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From nobody at rubyforge.org  Wed Jul  4 12:11:23 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed,  4 Jul 2007 12:11:23 -0400 (EDT)
Subject: [Wxruby-development] [1098] trunk/wxruby2: Test return value from
	XmlResource#load and raise an exception on failure
Message-ID: <20070704161123.72EF35240B79@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070704/0ad3a29c/attachment-0001.html 

From nobody at rubyforge.org  Wed Jul  4 13:43:19 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed,  4 Jul 2007 13:43:19 -0400 (EDT)
Subject: [Wxruby-development] [1099]
	trunk/wxruby2/swig/classes/XmlResource.i: Permit Dialogs and
	Frames with no parents to be created via XRC; add comments
Message-ID: <20070704174320.35D3B5240B90@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070704/d69e5437/attachment.html 

From nobody at rubyforge.org  Wed Jul  4 13:44:03 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed,  4 Jul 2007 13:44:03 -0400 (EDT)
Subject: [Wxruby-development] [1100]
	trunk/wxruby2/swig/classes/include/parents.rb: Add parent
	mapping for recently added ChildFocusEvent
Message-ID: <20070704174403.AE0825240B90@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070704/2ffdf037/attachment.html 

From nobody at rubyforge.org  Wed Jul  4 14:52:37 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed,  4 Jul 2007 14:52:37 -0400 (EDT)
Subject: [Wxruby-development] [1101]
	trunk/wxruby2/doc/textile/spinctrl.txtl: Doc patch to
	SpinCtrl from wxWidgets 2.8
Message-ID: <20070704185237.8B4A45240BAD@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070704/aeeac551/attachment.html 

From nobody at rubyforge.org  Wed Jul  4 14:53:18 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed,  4 Jul 2007 14:53:18 -0400 (EDT)
Subject: [Wxruby-development] [1102]
	trunk/wxruby2/doc/textile/spinbutton.txtl: Doc patch to
	SpinButton from wxWidgets 2.8
Message-ID: <20070704185318.340605240BB5@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070704/d7230fab/attachment.html 

From nobody at rubyforge.org  Wed Jul  4 15:00:47 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed,  4 Jul 2007 15:00:47 -0400 (EDT)
Subject: [Wxruby-development] [1103] trunk/wxruby2: Added 2.8 methods to
	StaticBitmap & document them; cleanup header file
Message-ID: <20070704190047.8DEB25240BA3@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070704/daacfe02/attachment-0001.html 

From nobody at rubyforge.org  Wed Jul  4 15:08:07 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed,  4 Jul 2007 15:08:07 -0400 (EDT)
Subject: [Wxruby-development] [1104] trunk/wxruby2: Added 2.8 methods to
	TextCtrl & document them; tidy up header file
Message-ID: <20070704190807.EC6805240BAD@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070704/3d3aef33/attachment.html 

From nobody at rubyforge.org  Wed Jul  4 15:11:04 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed,  4 Jul 2007 15:11:04 -0400 (EDT)
Subject: [Wxruby-development] [1105] trunk/wxruby2/doc/textile/button.txtl:
	2.8 documentation update reflecting where set_default_item now lies
Message-ID: <20070704191104.BCFE95240BAD@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070704/fc927c5f/attachment.html 

From nobody at rubyforge.org  Wed Jul  4 15:27:16 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed,  4 Jul 2007 15:27:16 -0400 (EDT)
Subject: [Wxruby-development] [1106] trunk/wxruby2/swig/RubyConstants.i: Add
	the MOD_XXX constants as used in wxKeyEvent
Message-ID: <20070704192716.7B7FF5240BB5@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070704/91a4cce8/attachment.html 

From nobody at rubyforge.org  Wed Jul  4 15:32:50 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed,  4 Jul 2007 15:32:50 -0400 (EDT)
Subject: [Wxruby-development] [1107] trunk/wxruby2: Add the 2.8
	get_modifiers method to KeyEvent; remove some deprecated
Message-ID: <20070704193251.17E995240BA3@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070704/0bdb9564/attachment-0001.html 

From nobody at rubyforge.org  Wed Jul  4 18:50:44 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed,  4 Jul 2007 18:50:44 -0400 (EDT)
Subject: [Wxruby-development] [1108] trunk/wxruby2/swig: Revised mem mgmt
	for Sizers to address more GC crashes in Sizers demo
Message-ID: <20070704225044.28C5F5240C6C@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070704/144cc5c0/attachment.html 

From noreply at rubyforge.org  Thu Jul  5 09:21:53 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  5 Jul 2007 09:21:53 -0400 (EDT)
Subject: [Wxruby-development] [ wxruby-Bugs-12015 ] incorrect behaviour on
	threads
Message-ID: <20070705132153.D269F5240B03@rubyforge.org>

Bugs item #12015, was opened at 2007-07-05 13:21
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=218&aid=12015&group_id=35

Category: Incorrect behavior
Group: current
Status: Open
Resolution: None
Priority: 3
Submitted By: Reinier Voost (rvoost)
Assigned to: Kevin Smith (qualitycode)
Summary: incorrect behaviour on threads

Initial Comment:
I have created an application with WXRuby which looks great. 
Though my application also uses threads.
The issue I have now, is that my threads only work when I am showing activity on the screen (like clicking, or even just moving my mouse over the panel).
Though when I am not active, the threads are also not active.

After some investigation I found out (or I guess) that the method main_loop is a thread on its own dominating all others.
I tried to prioritize my threads higher then the thread of main_loop but without any positive result.

I can enforce my thread to execute (as it is set to sleep immediately) by using the .run command, though for some unclear thing it only runs once and is put on sleep again.
So to conclude:
the main_loop is dominating all other threads in such a case that no other threads are running unless there is activity on the panel of the application. Doing this, it kills the functionality of using threads.

I will add my code so you can see for yourself what I mean. The mentioned codepart is at the on_init of class MyApp < App


 

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=218&aid=12015&group_id=35

From nobody at rubyforge.org  Thu Jul  5 14:45:10 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Thu,  5 Jul 2007 14:45:10 -0400 (EDT)
Subject: [Wxruby-development] [1109] trunk/wxruby2/swig: Move marking of
	MenuBar from direct %markfunc to via mark_wxFrame, so
Message-ID: <20070705184510.9139952409B4@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070705/26f30a71/attachment-0001.html 

From noreply at rubyforge.org  Thu Jul 12 13:26:54 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 12 Jul 2007 13:26:54 -0400 (EDT)
Subject: [Wxruby-development] [ wxruby-Bugs-12233 ] segfault on exit with
	StatusBar
Message-ID: <20070712172655.0CB025240AE3@rubyforge.org>

Bugs item #12233, was opened at 2007-07-12 17:26
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=218&aid=12233&group_id=35

Category: None
Group: None
Status: Open
Resolution: None
Priority: 2
Submitted By: Alex Fenton (brokentoy)
Assigned to: Nobody (None)
Summary: segfault on exit with StatusBar

Initial Comment:
(on behalf of Alex Ciarlillo)

In 0.40, the following code causes a segfault when the App exits:

class MyFrame < Wx::Frame
  def initialize(*args)
    super(*args)
       ### cut a bunch of commented out code that appears fine ###
       @statbar = StatusBar.new(self, -1)
       ### cut a bunch more code ###
    end
end

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=218&aid=12233&group_id=35

From nobody at rubyforge.org  Thu Jul 12 16:12:50 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Thu, 12 Jul 2007 16:12:50 -0400 (EDT)
Subject: [Wxruby-development] [1110] trunk/wxruby2/swig/classes/App.i:
	Remove director method from App#filter_event to fix meth
	routing error on Linux
Message-ID: <20070712201250.A17025240A3B@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070712/b7116ec2/attachment.html 

From nobody at rubyforge.org  Thu Jul 12 16:21:33 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Thu, 12 Jul 2007 16:21:33 -0400 (EDT)
Subject: [Wxruby-development] [1111]
	trunk/wxruby2/samples/bigdemo/wxFontDialog.rbw: Add TELETYPE
	constant and avoid crashes with unknown constants
Message-ID: <20070712202133.8F3955240BD9@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070712/40dbf87e/attachment.html 

From nobody at rubyforge.org  Thu Jul 12 18:23:20 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Thu, 12 Jul 2007 18:23:20 -0400 (EDT)
Subject: [Wxruby-development] [1112]
	trunk/wxruby2/swig/classes/include/wxTextCtrl.h: Remove
	unsupported form of TextCtrl#hit_test that's not documented anyway
Message-ID: <20070712222320.E94035240C6D@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070712/5fe381c3/attachment.html 

From wxruby at qualitycode.com  Sun Jul 15 14:52:30 2007
From: wxruby at qualitycode.com (Kevin Smith)
Date: Sun, 15 Jul 2007 14:52:30 -0400
Subject: [Wxruby-development] I will be unsubscribing
Message-ID: <469A6CEE.8080303@qualitycode.com>

Greetings all,

As you have noticed, I have been largely absent from the wxruby team for 
quite a while now. Fortunately, others have taken charge and continued 
to move wxruby forward. It's still a great project, but I just can't 
participate right now.

I will be unsubscribing from both the dev and users mailing lists in a 
couple days. Because I will be packing for a long trip overseas for the 
next few days, I don't know how much list email I will be able to read 
before I unsubscribe.

Perhaps we should consider changing the project credits to reflect that 
although I founded the project, others are now running it. As I won't be 
actively reading the list, that discussion might be best off-list.

For that, or if you need to contact me for other reasons, try wxruby2 at 
the same @qualitycode.com domain.

Best wishes,

Kevin

From sean.m.long at gmail.com  Mon Jul 16 01:41:26 2007
From: sean.m.long at gmail.com (Sean Long)
Date: Sun, 15 Jul 2007 22:41:26 -0700
Subject: [Wxruby-development] I will be unsubscribing
In-Reply-To: <469A6CEE.8080303@qualitycode.com>
References: <469A6CEE.8080303@qualitycode.com>
Message-ID: <c2cd0d1d0707152241r15247537w77382fc9fdeb4dc8@mail.gmail.com>

Kevin,

It is sad to see you bow out. Thank you for helping Alex, Roy and I
get into the project. You are the one that bought wxruby.org, correct?
Are you going to still maintain that domain and forward it to the
rubyforge page?

Good luck in your travels

Sean

On 7/15/07, Kevin Smith <wxruby at qualitycode.com> wrote:
> Greetings all,
>
> As you have noticed, I have been largely absent from the wxruby team for
> quite a while now. Fortunately, others have taken charge and continued
> to move wxruby forward. It's still a great project, but I just can't
> participate right now.
>
> I will be unsubscribing from both the dev and users mailing lists in a
> couple days. Because I will be packing for a long trip overseas for the
> next few days, I don't know how much list email I will be able to read
> before I unsubscribe.
>
> Perhaps we should consider changing the project credits to reflect that
> although I founded the project, others are now running it. As I won't be
> actively reading the list, that discussion might be best off-list.
>
> For that, or if you need to contact me for other reasons, try wxruby2 at
> the same @qualitycode.com domain.
>
> Best wishes,
>
> Kevin
> _______________________________________________
> Wxruby-development mailing list
> Wxruby-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-development
>

From alex at pressure.to  Mon Jul 16 10:35:18 2007
From: alex at pressure.to (Alex Fenton)
Date: Mon, 16 Jul 2007 15:35:18 +0100
Subject: [Wxruby-development] I will be unsubscribing
In-Reply-To: <469A6CEE.8080303@qualitycode.com>
References: <469A6CEE.8080303@qualitycode.com>
Message-ID: <469B8226.6010901@pressure.to>

Hi Kevin

Kevin Smith wrote:
> As you have noticed, I have been largely absent from the wxruby team for 
> quite a while now. Fortunately, others have taken charge and continued 
> to move wxruby forward. It's still a great project, but I just can't 
> participate right now.

In the last 12 months I've come to appreciate what a sterling job you 
did laying out the foundations of wxRuby2 out of nothing, and solving 
the tough problems, with a toolset that was much cruder than it is now. 
But you're not only a top-notch engineer and architect, but you've also 
been a great project leader, keeping things going.

Though I'm sorry you're moving on, thank you on behalf of everyone 
involved in wxRuby for all the work you've put in, and I wish you safe 
and happy journeys and every success with your future projects.

Alex



From mario at ruby-im.net  Mon Jul 16 11:35:57 2007
From: mario at ruby-im.net (Mario Steele)
Date: Mon, 16 Jul 2007 10:35:57 -0500
Subject: [Wxruby-development] I will be unsubscribing
In-Reply-To: <469A6CEE.8080303@qualitycode.com>
References: <469A6CEE.8080303@qualitycode.com>
Message-ID: <a4439dea0707160835o762f98balec8b61c28fe373cc@mail.gmail.com>

Hello Kevin,

Let me also be someone who congrats you on the work you have done to
establish wxWidgets in Ruby for thoes who don't want a heavy, bog down
interface, or slow response time, due to every graphical interface being
drawn by the toolkit.  You have truely gained my appreciation, and allowed
me to move away from Ruby-Gnome2, and FXRuby as my interface libraries, and
allows me the joy once again to use wxWidgets with a programming language I
love.  I look forward to seeing you maybe come back later on down the road.

Farewell, and god send Kevin, Enjoy your vacation

Mario Steele


On 7/15/07, Kevin Smith <wxruby at qualitycode.com> wrote:
>
> Greetings all,
>
> As you have noticed, I have been largely absent from the wxruby team for
> quite a while now. Fortunately, others have taken charge and continued
> to move wxruby forward. It's still a great project, but I just can't
> participate right now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070716/42a903a2/attachment-0001.html 

From nobody at rubyforge.org  Mon Jul 16 16:41:03 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Mon, 16 Jul 2007 16:41:03 -0400 (EDT)
Subject: [Wxruby-development] [1113] trunk/wxruby2/samples/caret/caret.rb:
	Ensure the canvas has focus so KeyEvents are directed to it,
	fixing bug 10663
Message-ID: <20070716204103.C742D5240E82@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070716/b2cecfe2/attachment.html 

From roys at mindspring.com  Mon Jul 16 23:19:05 2007
From: roys at mindspring.com (Roy Sutton)
Date: Mon, 16 Jul 2007 23:19:05 -0400
Subject: [Wxruby-development] I will be unsubscribing
In-Reply-To: <469A6CEE.8080303@qualitycode.com>
References: <469A6CEE.8080303@qualitycode.com>
Message-ID: <469C3529.9050507@mindspring.com>

Kevin,

Even though I'm just a ghost around here myself these days I wanted to 
thank you for the hard work, too.  I'm hoping I won't have to follow the 
same path myself but I don't see a break in my schedule for a bit.  Add 
to that the fact I'm not using wxRuby in any projects and I don't see 
when I'll be able to jump back in.  Hopefully soon, we'll see!

Roy

Kevin Smith wrote:
> Greetings all,
>
> As you have noticed, I have been largely absent from the wxruby team for 
> quite a while now. Fortunately, others have taken charge and continued 
> to move wxruby forward. It's still a great project, but I just can't 
> participate right now.
>
> I will be unsubscribing from both the dev and users mailing lists in a 
> couple days. Because I will be packing for a long trip overseas for the 
> next few days, I don't know how much list email I will be able to read 
> before I unsubscribe.
>
> Perhaps we should consider changing the project credits to reflect that 
> although I founded the project, others are now running it. As I won't be 
> actively reading the list, that discussion might be best off-list.
>
> For that, or if you need to contact me for other reasons, try wxruby2 at 
> the same @qualitycode.com domain.
>
> Best wishes,
>
> Kevin
> _______________________________________________
> Wxruby-development mailing list
> Wxruby-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-development
>
>
>
>   

From nobody at rubyforge.org  Tue Jul 17 13:11:19 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue, 17 Jul 2007 13:11:19 -0400 (EDT)
Subject: [Wxruby-development] [1114] trunk/wxruby2/swig/classes/include:
	Added missing methods from the 2.6 to 2.8 upgrade.
Message-ID: <20070717171119.E27775240C3B@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070717/2ce189ae/attachment.html 

From nobody at rubyforge.org  Tue Jul 17 17:01:27 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue, 17 Jul 2007 17:01:27 -0400 (EDT)
Subject: [Wxruby-development] [1115]
	trunk/wxruby2/samples/minimal/minimal.rb: Don't call destroy
	explicitly as it causes assert failures
Message-ID: <20070717210127.7AD2C5240B00@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070717/90404898/attachment.html 

From nobody at rubyforge.org  Tue Jul 17 17:34:01 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue, 17 Jul 2007 17:34:01 -0400 (EDT)
Subject: [Wxruby-development] [1116]
	trunk/wxruby2/samples/bigdemo/wxStaticBitmap.rbw: Fix
	hardcoded image paths, tidy up indenting
Message-ID: <20070717213403.4F3A15240B8F@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070717/20a6e52d/attachment.html 

From nobody at rubyforge.org  Wed Jul 18 04:16:07 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed, 18 Jul 2007 04:16:07 -0400 (EDT)
Subject: [Wxruby-development] [1117] trunk/wxruby2/swig/classes/App.i: No
	director for GetTopWindow,
	remove Unlink in OnExit to avoid exception
Message-ID: <20070718081607.C05885240DAF@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070718/cd7d7ac8/attachment-0001.html 

From noreply at rubyforge.org  Wed Jul 18 04:24:42 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 18 Jul 2007 04:24:42 -0400 (EDT)
Subject: [Wxruby-development] [ wxruby-Bugs-12360 ]
	TreeCtrl#on_compare_items not working on MSW
Message-ID: <20070718082442.6EBD35240DB1@rubyforge.org>

Bugs item #12360, was opened at 2007-07-18 08:24
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=218&aid=12360&group_id=35

Category: Incorrect behavior
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Alex Fenton (brokentoy)
Assigned to: Alex Fenton (brokentoy)
Summary: TreeCtrl#on_compare_items not working on MSW

Initial Comment:
If a TreeCtrl defines a custom on_compare_items method, this is not called when the tree is sorted on MSW. This works correctly on OS X and Linux.

The following note in the wxWidgets headers may indicate the source of the problem:

    // NB: due to an ugly wxMSW hack you _must_ use DECLARE_DYNAMIC_CLASS()
    //     if you want your overloaded OnCompareItems() to be called.
    //     OTOH, if you don't want it you may omit the next line - this will
    //     make default (alphabetical) sorting much faster under wxMSW.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=218&aid=12360&group_id=35

From nobody at rubyforge.org  Wed Jul 18 04:34:47 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed, 18 Jul 2007 04:34:47 -0400 (EDT)
Subject: [Wxruby-development] [1118] trunk/wxruby2/swig: Move
	Wx::message_box function from wx.i to Functions.i, where it belongs
Message-ID: <20070718083448.1294D5240A79@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070718/0b9cb591/attachment.html 

From nobody at rubyforge.org  Wed Jul 18 04:40:11 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed, 18 Jul 2007 04:40:11 -0400 (EDT)
Subject: [Wxruby-development] [1119] trunk/wxruby2/swig/Functions.i: Avoid
	erroneous 'parent must not be nil' errors when using global
Message-ID: <20070718084011.584B95240AC6@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070718/5c296ac6/attachment.html 

From wxruby at qualitycode.com  Thu Jul 19 08:59:29 2007
From: wxruby at qualitycode.com (Kevin Smith)
Date: Thu, 19 Jul 2007 08:59:29 -0400
Subject: [Wxruby-development] I will be unsubscribing
In-Reply-To: <c2cd0d1d0707152241r15247537w77382fc9fdeb4dc8@mail.gmail.com>
References: <469A6CEE.8080303@qualitycode.com>
	<c2cd0d1d0707152241r15247537w77382fc9fdeb4dc8@mail.gmail.com>
Message-ID: <469F6031.60101@qualitycode.com>

Thanks to everyone for the kind words. I'm proud of my work on wxruby, 
and am especially happy that the project is thriving without me.

It is interesting to me that all these years later, the reasons I first 
got involved with wxruby are still valid. It is the only cross-platform, 
native-widget, liberal-licensed GUI toolkit.

Way back when, I inherited the original-original code from Park Heesob, 
and without his working prototype, my job would have been much more 
difficult. He asked that his name be removed from the project when he 
handed me control, but I can't let him go entirely uncredited.

Many thanks also to the many folks who have participated in the project 
over the years. Most of their names are captured in the email archives. 
You don't have to be a core coder to make a big contribution.

Probably my best decision as a lead was to jump to SWIG after SWIG added 
the features we needed (notably "directors"). It was not an easy 
decision, but with hindsight it was clearly the right one.

I will continue to hold and renew the wxruby.org/com domains for now. At 
some point I would be happy to pass them on to someone else if it makes 
sense to do so. I am happy to contribute $16/year to the project.

I am unsubscribing to the lists now, so if you need to reach me, please 
use my wxruby2 address.

Cheers,

Kevin


Sean Long wrote:
> Kevin,
> 
> It is sad to see you bow out. Thank you for helping Alex, Roy and I
> get into the project. You are the one that bought wxruby.org, correct?
> Are you going to still maintain that domain and forward it to the
> rubyforge page?
> 
> Good luck in your travels
> 
> Sean
> 
> On 7/15/07, Kevin Smith <wxruby at qualitycode.com> wrote:
>> Greetings all,
>>
>> As you have noticed, I have been largely absent from the wxruby team for
>> quite a while now. Fortunately, others have taken charge and continued
>> to move wxruby forward. It's still a great project, but I just can't
>> participate right now.
>>
>> I will be unsubscribing from both the dev and users mailing lists in a
>> couple days. Because I will be packing for a long trip overseas for the
>> next few days, I don't know how much list email I will be able to read
>> before I unsubscribe.
>>
>> Perhaps we should consider changing the project credits to reflect that
>> although I founded the project, others are now running it. As I won't be
>> actively reading the list, that discussion might be best off-list.
>>
>> For that, or if you need to contact me for other reasons, try wxruby2 at
>> the same @qualitycode.com domain.
>>
>> Best wishes,
>>
>> Kevin
>> _______________________________________________
>> Wxruby-development mailing list
>> Wxruby-development at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wxruby-development
>>
> _______________________________________________
> Wxruby-development mailing list
> Wxruby-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-development


From nobody at rubyforge.org  Thu Jul 19 18:28:56 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Thu, 19 Jul 2007 18:28:56 -0400 (EDT)
Subject: [Wxruby-development] [1120]
	trunk/wxruby2/lib/wx/classes/previewframe.rb: GC protection
	for Preview associated with PreviewFrame, fixing crashes
Message-ID: <20070719222856.C9B205240CB5@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070719/e3e44c9f/attachment.html 

From nobody at rubyforge.org  Thu Jul 19 18:30:56 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Thu, 19 Jul 2007 18:30:56 -0400 (EDT)
Subject: [Wxruby-development] [1121]
	trunk/wxruby2/swig/classes/PreviewFrame.i: Avoid double-free
	error on PrintPreview once attached to a PreviewFrame
Message-ID: <20070719223056.23FF75240CFA@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070719/8a226008/attachment.html 

From nobody at rubyforge.org  Thu Jul 19 18:31:26 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Thu, 19 Jul 2007 18:31:26 -0400 (EDT)
Subject: [Wxruby-development] [1122]
	trunk/wxruby2/swig/classes/PrintPreview.i: Mark the PrintOuts
	associated with a Preview to prevent premature
Message-ID: <20070719223126.C7D775240CB5@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070719/840357d0/attachment-0001.html 

From nobody at rubyforge.org  Fri Jul 20 04:58:52 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Fri, 20 Jul 2007 04:58:52 -0400 (EDT)
Subject: [Wxruby-development] [1123] trunk/wxruby2/swig/wx.i: Check sizers
	being marked have a ruby rep and are not internal Wx-only, 
Message-ID: <20070720085852.6DC1E5240951@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070720/69fec823/attachment.html 

From nobody at rubyforge.org  Fri Jul 20 14:15:16 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Fri, 20 Jul 2007 14:15:16 -0400 (EDT)
Subject: [Wxruby-development] [1124]
	trunk/wxruby2/samples/bigdemo/wxGauge.rbw: Use Wx::Timer
	instead of evt_idle to drive Gauge sample, to avoid 100%
Message-ID: <20070720181517.F00D5524101B@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070720/25c3bcd2/attachment.html 

From nobody at rubyforge.org  Fri Jul 20 14:41:11 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Fri, 20 Jul 2007 14:41:11 -0400 (EDT)
Subject: [Wxruby-development] [1125]
	trunk/wxruby2/swig/shared/control_with_items.i: Avoid MSW
	crashes when unexpected object is returned by SWIG tracking
Message-ID: <20070720184111.2DFCB52410EE@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070720/becc5de3/attachment.html 

From nobody at rubyforge.org  Fri Jul 20 17:21:08 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Fri, 20 Jul 2007 17:21:08 -0400 (EDT)
Subject: [Wxruby-development] [1126] trunk/wxruby2/rake/rakemswin.rb: Remove
	deprecated cl.exe option to get rid of MSW compile warning
Message-ID: <20070720212108.CE99E52410B1@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070720/21cb2d21/attachment.html 

From nobody at rubyforge.org  Sat Jul 21 07:08:38 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sat, 21 Jul 2007 07:08:38 -0400 (EDT)
Subject: [Wxruby-development] [1127] trunk/wxruby2: Move shared C++ GC
	functions into separate file included into wx.i
Message-ID: <20070721110838.DC69AA970003@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070721/ff951a9f/attachment-0001.html 

From nobody at rubyforge.org  Sat Jul 21 07:57:52 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sat, 21 Jul 2007 07:57:52 -0400 (EDT)
Subject: [Wxruby-development] [1128] trunk/wxruby2/swig/common.i: Make
	GC_IsWindowDeleted function globally available
Message-ID: <20070721115752.2C91B5240A7B@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070721/38df0e4c/attachment.html 

From nobody at rubyforge.org  Sat Jul 21 08:21:01 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sat, 21 Jul 2007 08:21:01 -0400 (EDT)
Subject: [Wxruby-development] [1129] trunk/wxruby2/swig/classes/Window.i:
	Add DISOWN typemap for ToolTip so it isn't double-deleted
Message-ID: <20070721122102.00CA25240A7B@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070721/ab43d567/attachment.html 

From nobody at rubyforge.org  Sat Jul 21 08:21:34 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sat, 21 Jul 2007 08:21:34 -0400 (EDT)
Subject: [Wxruby-development] [1130] trunk/wxruby2/swig/classes/Caret.i:
	Make Caret managed as object, so it is cleaned up properly when not
Message-ID: <20070721122134.284CD5240A7B@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070721/435a10d3/attachment.html 

From nobody at rubyforge.org  Sat Jul 21 08:28:57 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sat, 21 Jul 2007 08:28:57 -0400 (EDT)
Subject: [Wxruby-development] [1131]
	trunk/wxruby2/swig/classes/TaskBarIcon.i: TaskBarIcon should
	never be destroyed by Ruby, else will segfault-on-exit
Message-ID: <20070721122857.E4CD65240A7B@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070721/c7a9762a/attachment.html 

From nobody at rubyforge.org  Sat Jul 21 09:36:22 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sat, 21 Jul 2007 09:36:22 -0400 (EDT)
Subject: [Wxruby-development] [1132]
	trunk/wxruby2/doc/textile/windowdestroyevent.txtl: Updated
	and corrected doc on WindowDestroyEvent, noting that e.skip must
Message-ID: <20070721133622.612A75240A95@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070721/55699e59/attachment.html 

From nobody at rubyforge.org  Sat Jul 21 11:50:04 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sat, 21 Jul 2007 11:50:04 -0400 (EDT)
Subject: [Wxruby-development] [1133]
	trunk/wxruby2/swig/shared/control_with_items.i: Move mark
	func for ControlWithItems into shared file so changes affect
Message-ID: <20070721155004.BC7C95240AFA@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070721/183ee720/attachment-0001.html 

From nobody at rubyforge.org  Sat Jul 21 11:51:00 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sat, 21 Jul 2007 11:51:00 -0400 (EDT)
Subject: [Wxruby-development] [1134] trunk/wxruby2/swig/mark_free_impl.i:
	When window is deleted,
	unhook ruby obj from DATA_PTR to avoid MSW crashes
Message-ID: <20070721155100.D4EF35240B26@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070721/75cd6906/attachment.html 

From nobody at rubyforge.org  Sat Jul 21 11:52:16 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sat, 21 Jul 2007 11:52:16 -0400 (EDT)
Subject: [Wxruby-development] [1135] trunk/wxruby2/swig/mark_free_impl.i:
	Convert from DOS to Unix newlines
Message-ID: <20070721155216.50D395240B26@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070721/7160516b/attachment.html 

From nobody at rubyforge.org  Sat Jul 21 12:42:13 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sat, 21 Jul 2007 12:42:13 -0400 (EDT)
Subject: [Wxruby-development] [1136] trunk/wxruby2/swig/classes/App.i: Note
	when the Wx::App is exiting and avoid doing GC if in process of
Message-ID: <20070721164213.B8D1EA97000B@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070721/85621559/attachment.html 

From nobody at rubyforge.org  Sat Jul 21 12:47:32 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sat, 21 Jul 2007 12:47:32 -0400 (EDT)
Subject: [Wxruby-development] [1137] trunk/wxruby2/swig/classes/TreeCtrl.i:
	Call correct shared function to check whether TreeCtrl is
	deleted in markfunc
Message-ID: <20070721164732.6EA09A970005@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070721/756ab8d0/attachment-0001.html 

From nobody at rubyforge.org  Sat Jul 21 12:49:41 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sat, 21 Jul 2007 12:49:41 -0400 (EDT)
Subject: [Wxruby-development] [1138] trunk/wxruby2/samples/html/html.rb:
	Place HTMLWindow in a panel so gets correct bg color on MSW
Message-ID: <20070721164941.3B83EA97000C@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070721/fcf9c99e/attachment.html 

From nobody at rubyforge.org  Sat Jul 21 12:51:02 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sat, 21 Jul 2007 12:51:02 -0400 (EDT)
Subject: [Wxruby-development] [1139] trunk/wxruby2/samples/text/textctrl.rb:
	Place TextCtrl sample in a panel so gets correct bg color on MSW
Message-ID: <20070721165102.812BAA97000B@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070721/cde4b443/attachment.html 

From alex at pressure.to  Sat Jul 21 14:01:30 2007
From: alex at pressure.to (Alex Fenton)
Date: Sat, 21 Jul 2007 19:01:30 +0100
Subject: [Wxruby-development] svn commit emails
Message-ID: <46A249FA.8010200@pressure.to>

Hi

A lot of the volume on this list is the SVN commit emails, but there are 
also people who are subscribed who aren't currently committers but are 
interested in internals.

I'm thinking of creating a separate wxruby-commit email list to reduce 
this list's volume. I'm happy to post updates on development to this 
list in between releases for those interested in tracking progress.

Any thoughts - let me know if you definitely don't want this to happen.

alex

From alex at pressure.to  Sat Jul 21 14:08:01 2007
From: alex at pressure.to (Alex Fenton)
Date: Sat, 21 Jul 2007 19:08:01 +0100
Subject: [Wxruby-development] upcoming 1.9.0 release
Message-ID: <46A24B81.4040704@pressure.to>

I think (cautiously) that recent commits have at last fixed the memory 
management for most/all the currently ported classes. I get 
ObjectPreviouslyDeleted exceptions on exit occasionally in bigdemo, but 
that's about it. If I never see a C debugger again it will be too soon.

Bugs on the tracker are either minor OS X-specific quirks, which I can't 
tackle at the moment, and a couple of method-specific bugs which I am 
currently stumped on how to fix with SWIG.

On that basis I'm planning to offer a 1.9.0 (beta) release in the next 
week or two. So I'd be very grateful for any time you can put in on 
testing the samples or your own code with SVN head, especially looking 
fo any segfaults.

Thanks
alex

From mario at ruby-im.net  Sun Jul 22 00:10:32 2007
From: mario at ruby-im.net (Mario Steele)
Date: Sat, 21 Jul 2007 23:10:32 -0500
Subject: [Wxruby-development] svn commit emails
In-Reply-To: <46A249FA.8010200@pressure.to>
References: <46A249FA.8010200@pressure.to>
Message-ID: <op.tvulvuo953rrhy@compaq.gateway.2wire.net>

Hey Alex,

I think this would be a good idea.  I personally am subscribed to the  
Development list, so I can see what's going on behind the scenes, but the  
patches I'm not so worried about, as along as some general notes of what  
commits are being added are sent out on this list.  That would be great.

Thanks,

Mario


On Sat, 21 Jul 2007 13:01:30 -0500, Alex Fenton <alex at pressure.to> wrote:

> Hi
>
> A lot of the volume on this list is the SVN commit emails, but there are
> also people who are subscribed who aren't currently committers but are
> interested in internals.
>
> I'm thinking of creating a separate wxruby-commit email list to reduce
> this list's volume. I'm happy to post updates on development to this
> list in between releases for those interested in tracking progress.
>
> Any thoughts - let me know if you definitely don't want this to happen.
>
> alex
> _______________________________________________
> Wxruby-development mailing list
> Wxruby-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-development



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From nobody at rubyforge.org  Sun Jul 22 19:08:52 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sun, 22 Jul 2007 19:08:52 -0400 (EDT)
Subject: [Wxruby-development] [1140] trunk/wxruby2/swig/mark_free_impl.i:
	Remove instance variable marking of deleted Wx Windows
	because it's redundant
Message-ID: <20070722230852.F3253A97000D@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070722/cb5060b2/attachment.html 

From nobody at rubyforge.org  Sun Jul 22 19:15:07 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sun, 22 Jul 2007 19:15:07 -0400 (EDT)
Subject: [Wxruby-development] [1141] trunk/wxruby2/swig/mark_free_impl.i:
	ControlWithItems call default Window mark routine to preserve
	ToolTips etc
Message-ID: <20070722231507.6AE9DA970003@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070722/64cd9f66/attachment.html 

From nobody at rubyforge.org  Mon Jul 23 13:23:16 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Mon, 23 Jul 2007 13:23:16 -0400 (EDT)
Subject: [wxruby-development] [1142] trunk/wxruby2/README: Updated README
	with latest version info and Kevin credit
Message-ID: <20070723172317.008635240C30@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070723/fd468e6a/attachment-0001.html 

From alex at pressure.to  Mon Jul 23 13:35:24 2007
From: alex at pressure.to (Alex Fenton)
Date: Mon, 23 Jul 2007 18:35:24 +0100
Subject: [wxruby-development] [Wxruby-development] svn commit emails
In-Reply-To: <46A249FA.8010200@pressure.to>
References: <46A249FA.8010200@pressure.to>
Message-ID: <46A4E6DC.4020005@pressure.to>

Alex Fenton wrote:
> I'm thinking of creating a separate wxruby-commit email list to reduce 
> this list's volume. 

It's done; the lists are sundered. If you would like to continue to 
receive SVN commit notifications, please subscribe here:

http://rubyforge.org/mailman/listinfo/wxruby-svn-commit

cheers
alex

From sean.m.long at gmail.com  Mon Jul 23 16:19:26 2007
From: sean.m.long at gmail.com (Sean Long)
Date: Mon, 23 Jul 2007 13:19:26 -0700
Subject: [wxruby-development] Memory problem with GridCell*Editor
Message-ID: <c2cd0d1d0707231319k3434e1e8s8eda44a0db78a0b9@mail.gmail.com>

Alex,

I was getting the following crashes when editing cells in a grid:

./init.rb:1072:in `main_loop': undefined method `begin_edit' for
"_p_wxEvent":String (NoMethodError)
        from ./init.rb:1072

but only after the first App GC mark phase.

So I changed all the GridCell*Editor.i files from GC_MANAGE to
GC_MANAGE_AS_EVENT. Which stopped the crashing. My question Alex is do
you think this is the correct GC_* to use in this situation? I wanted
to run this by you before I do a commit, since I have not messed
around with memory management since the big overhaul.

thanks

Sean

From alex at pressure.to  Mon Jul 23 17:27:39 2007
From: alex at pressure.to (Alex Fenton)
Date: Mon, 23 Jul 2007 22:27:39 +0100
Subject: [wxruby-development] Memory problem with GridCell*Editor
In-Reply-To: <c2cd0d1d0707231319k3434e1e8s8eda44a0db78a0b9@mail.gmail.com>
References: <c2cd0d1d0707231319k3434e1e8s8eda44a0db78a0b9@mail.gmail.com>
Message-ID: <46A51D4B.6040502@pressure.to>

Hey Sean

Sean Long wrote:
> I was getting the following crashes when editing cells in a grid:
>
> ./init.rb:1072:in `main_loop': undefined method `begin_edit' for
> "_p_wxEvent":String (NoMethodError)
>         from ./init.rb:1072
>
> but only after the first App GC mark phase.
>   
Thanks - hmm -  looks like GC is getting called while an event is 
halfway through processing, then the event is getting re-wrapped inside 
a class that doesn't know how to do the mapping correctly.

Unfortunately I can't seem to reproduce this on Linux - is it on the 
grid.rb sample or in bigdemo?

If you could get a backtrace when the exception is raised that would be 
great. Try doing

gdb --args ruby -Ilib path/to/sample

then, in gdb, set a breakpoint when the exception is about to be raised

b rb_exc_raise

then ignore the first, false alarm (a load error) using

c

then when the real exception is raised, do

whe

> So I changed all the GridCell*Editor.i files from GC_MANAGE to
> GC_MANAGE_AS_EVENT. Which stopped the crashing. My question Alex is do
> you think this is the correct GC_* to use in this situation? 
The GC_MANAGE_AS_XXX declarations should align with the wx class 
hierarchy - they're intended to match the lifecycle of different kind of 
wx objects - so really only classes derived from wxEvent should be 
GC_MANAGE_AS_EVENT. I think the grid editor classes should be 
GC_MANAGE_AS_OBJECT but obviously something's going wrong.

Does it help if you make the GridCell*Editor classes GC_NEVER? If so, we 
could use this and just mark them FIXME. It'll probably create a memory 
leak, but only a small one.

cheers
alex


From sean.m.long at gmail.com  Mon Jul 23 18:17:30 2007
From: sean.m.long at gmail.com (Sean Long)
Date: Mon, 23 Jul 2007 15:17:30 -0700
Subject: [wxruby-development] Memory problem with GridCell*Editor
In-Reply-To: <46A51D4B.6040502@pressure.to>
References: <c2cd0d1d0707231319k3434e1e8s8eda44a0db78a0b9@mail.gmail.com>
	<46A51D4B.6040502@pressure.to>
Message-ID: <c2cd0d1d0707231517g5a56dfcdnfbeaf4a3a859a56@mail.gmail.com>

> Unfortunately I can't seem to reproduce this on Linux - is it on the
> grid.rb sample or in bigdemo?

Neither it is one of my own apps, which runs fine on 0.0.40.

> If you could get a backtrace when the exception is raised that would be
> great. Try doing
>
> gdb --args ruby -Ilib path/to/sample
>
> then, in gdb, set a breakpoint when the exception is about to be raised
>
> b rb_exc_raise
>
> then ignore the first, false alarm (a load error) using
>
> c
>
> then when the real exception is raised, do
>
> whe

I get:
No stack.

> Does it help if you make the GridCell*Editor classes GC_NEVER? If so, we
> could use this and just mark them FIXME. It'll probably create a memory
> leak, but only a small one.

GC_NEVER still causes a crash. The only GC_* that works is the
GC_MANAGE_AS_EVENT.

Any ideas?

Sean

From alex at pressure.to  Mon Jul 23 20:34:33 2007
From: alex at pressure.to (Alex Fenton)
Date: Tue, 24 Jul 2007 01:34:33 +0100
Subject: [wxruby-development] Memory problem with GridCell*Editor
In-Reply-To: <c2cd0d1d0707231517g5a56dfcdnfbeaf4a3a859a56@mail.gmail.com>
References: <c2cd0d1d0707231319k3434e1e8s8eda44a0db78a0b9@mail.gmail.com>	<46A51D4B.6040502@pressure.to>
	<c2cd0d1d0707231517g5a56dfcdnfbeaf4a3a859a56@mail.gmail.com>
Message-ID: <46A54919.9010505@pressure.to>

Sean Long wrote:
>
> Neither it is one of my own apps, which runs fine on 0.0.40.
>   

Okay - does either of those exhibit the problem? Or is it easily 
reproducible in some small amount of code?
>
> GC_NEVER still causes a crash. The only GC_* that works is the
> GC_MANAGE_AS_EVENT.

The distinctive feature of manage_as_event is disabling of directors of 
object tracking. Does GC_MANAGE_AS_OBJECT plus either

%feature("nodirector") wxGridCellXXXEditor;

or

%trackobjects("0") # not sure how this should be switched off

work?

alex

From alex at pressure.to  Tue Jul 24 03:12:45 2007
From: alex at pressure.to (Alex Fenton)
Date: Tue, 24 Jul 2007 08:12:45 +0100
Subject: [wxruby-development] Memory problem with GridCell*Editor
In-Reply-To: <c2cd0d1d0707231319k3434e1e8s8eda44a0db78a0b9@mail.gmail.com>
References: <c2cd0d1d0707231319k3434e1e8s8eda44a0db78a0b9@mail.gmail.com>
Message-ID: <46A5A66D.2030200@pressure.to>

Sean Long wrote:
> I was getting the following crashes when editing cells in a grid:
>
> ./init.rb:1072:in `main_loop': undefined method `begin_edit' for
> "_p_wxEvent":String (NoMethodError)
>         from ./init.rb:1072
>
> but only after the first App GC mark phase.
>   
One more question - are you setting a custom GridCellEditor for your 
grid, and if so, what method are you using to assign it to the cells?

Does it then help if you store the Editor as a ruby instance variable of 
the Wx::Grid?

Thanks
alex


From sean.m.long at gmail.com  Wed Jul 25 02:29:32 2007
From: sean.m.long at gmail.com (Sean Long)
Date: Tue, 24 Jul 2007 23:29:32 -0700
Subject: [wxruby-development] Memory problem with GridCell*Editor
In-Reply-To: <46A54919.9010505@pressure.to>
References: <c2cd0d1d0707231319k3434e1e8s8eda44a0db78a0b9@mail.gmail.com>
	<46A51D4B.6040502@pressure.to>
	<c2cd0d1d0707231517g5a56dfcdnfbeaf4a3a859a56@mail.gmail.com>
	<46A54919.9010505@pressure.to>
Message-ID: <c2cd0d1d0707242329g767a8d8at2c12dd72a87ef7a3@mail.gmail.com>

> The distinctive feature of manage_as_event is disabling of directors of
> object tracking. Does GC_MANAGE_AS_OBJECT plus either
>
> %feature("nodirector") wxGridCellXXXEditor;


Doing the above works with no crashing.

Any idea on why it works?

(sorry for the delayed response, my web connection was having problems
most of the day)

Sean

From sean.m.long at gmail.com  Wed Jul 25 02:37:32 2007
From: sean.m.long at gmail.com (Sean Long)
Date: Tue, 24 Jul 2007 23:37:32 -0700
Subject: [wxruby-development] Memory problem with GridCell*Editor
In-Reply-To: <46A5A66D.2030200@pressure.to>
References: <c2cd0d1d0707231319k3434e1e8s8eda44a0db78a0b9@mail.gmail.com>
	<46A5A66D.2030200@pressure.to>
Message-ID: <c2cd0d1d0707242337l69a34f07tdb555fdd5f62d0e2@mail.gmail.com>

> One more question - are you setting a custom GridCellEditor for your
> grid, and if so, what method are you using to assign it to the cells?

I am setting the editor for an entire column. ex.

@grid = Wx::Grid.new(panel,id_to_assign_grid,Wx::DEFAULT_POSITION,Wx::DEFAULT_SIZE,Wx::WANTS_CHARS|Wx::ALWAYS_SHOW_SB)
@grid.create_grid(4,3)

float_cell_attr =
Wx::GridCellAttr.new(Wx::BLACK,Wx::WHITE,Wx::NORMAL_FONT,Wx::ALIGN_CENTRE,Wx::ALIGN_CENTRE)
			
float_cell_attr.set_editor(Wx::GridCellFloatEditor.new(2,1))
@grid.set_col_attr(1,float_cell_attr)

> Does it then help if you store the Editor as a ruby instance variable of
> the Wx::Grid?

Have not tried this yet.


Sean

From alex at pressure.to  Wed Jul 25 05:13:11 2007
From: alex at pressure.to (Alex Fenton)
Date: Wed, 25 Jul 2007 10:13:11 +0100
Subject: [wxruby-development] Memory problem with GridCell*Editor
In-Reply-To: <c2cd0d1d0707242329g767a8d8at2c12dd72a87ef7a3@mail.gmail.com>
References: <c2cd0d1d0707231319k3434e1e8s8eda44a0db78a0b9@mail.gmail.com>	<46A51D4B.6040502@pressure.to>	<c2cd0d1d0707231517g5a56dfcdnfbeaf4a3a859a56@mail.gmail.com>	<46A54919.9010505@pressure.to>
	<c2cd0d1d0707242329g767a8d8at2c12dd72a87ef7a3@mail.gmail.com>
Message-ID: <46A71427.6050103@pressure.to>

Sean Long wrote:
>> %feature("nodirector") wxGridCellXXXEditor;
>>     
>
>
> Doing the above works with no crashing.
>   
Thanks - from this and your other email I've a pretty good guess at 
what's going on. I can reproduce it and have got some ideas to fix it to 
try out later.

A bit of background:

Classes with directors are more sensitive to getting GC'd prematurely, 
and are one of the biggest headaches in wxRuby. This is because in 
SWIG's design  the *same* ruby object is permanently bound to the C++ 
object - so that calls to C++ virtual methods from inside the wxWidget 
API can be delegated to ruby subclass methods.

Because of this, director classes (GridCell*Editor and 
GridCell*Renderer), which don't inherit from Wx::Window but are 
attached/owned by windows and have a finite lifespan need special GC 
treatment by the owner. Otherwise, when GC runs, it finds that the ruby 
GridCell*Editor object is no longer referenced anywhere in ruby, sweeps 
the object, and then subsequently when a C++ virtual method call is made 
(eg 'begin_edit'), it tries to call it on a deleted ruby obj, which 
either crashes or gives strange results like the ones you were seeing. 
The same sort of problem applies to Menus, Sizers, ClientData, ToolTips etc.

One way to fix this is to make the Editor (and Renderer) classes not 
directors. But this would meant that it would not be possible to write 
your own Editor or Renderer classes in Ruby because the relevant 
internal methods (mostly in the base class GridCellEditor) couldn't be 
over-ridden. That's maybe something only pretty advanced users will want 
to do, but still nice to have.

The better way to fix it would be to improve the way Grid is marked in 
the GC phase so it marks all associated editors. The way I currently 
implemented this (in lib/wx/classes/grid.rb) missed the fact that an 
editor could be attached via attr and set_col_attr, as well as directly 
by set_cell_editor.

cheers
alex

From alex at pressure.to  Wed Jul 25 15:44:04 2007
From: alex at pressure.to (Alex Fenton)
Date: Wed, 25 Jul 2007 20:44:04 +0100
Subject: [wxruby-development] Memory problem with GridCell*Editor
In-Reply-To: <46A71427.6050103@pressure.to>
References: <c2cd0d1d0707231319k3434e1e8s8eda44a0db78a0b9@mail.gmail.com>	<46A51D4B.6040502@pressure.to>	<c2cd0d1d0707231517g5a56dfcdnfbeaf4a3a859a56@mail.gmail.com>	<46A54919.9010505@pressure.to>	<c2cd0d1d0707242329g767a8d8at2c12dd72a87ef7a3@mail.gmail.com>
	<46A71427.6050103@pressure.to>
Message-ID: <46A7A804.20307@pressure.to>

Hi Sean

Alex Fenton wrote:
> Sean Long wrote:
>   
>>> %feature("nodirector") wxGridCellXXXEditor;
>>>     
>>>       
>> Doing the above works with no crashing.
>>     

I've checked in some code that should help the original issue. 
Unfortunately 1) it's a bit complicated and 2) the performance sucks on 
larger grids. 20x20 is fine, but 200x200 is not - it seizes up when GC runs.

The choice as far as I can see for now is to either

- remove directors from GridCellEditor and GridCellRenderer; this means 
users can't write their own custom ruby DC code to paint directly on a 
cell when it's being edited or re-drawn. The standard Wx variants (eg 
Wx::GridCellFloatEditor) would still work

or

- warn users that they can't create more than modest-sized grids.

What do you (or others) think?

cheers
alex

From sean.m.long at gmail.com  Wed Jul 25 19:16:14 2007
From: sean.m.long at gmail.com (Sean Long)
Date: Wed, 25 Jul 2007 16:16:14 -0700
Subject: [wxruby-development] Memory problem with GridCell*Editor
In-Reply-To: <46A7A804.20307@pressure.to>
References: <c2cd0d1d0707231319k3434e1e8s8eda44a0db78a0b9@mail.gmail.com>
	<46A51D4B.6040502@pressure.to>
	<c2cd0d1d0707231517g5a56dfcdnfbeaf4a3a859a56@mail.gmail.com>
	<46A54919.9010505@pressure.to>
	<c2cd0d1d0707242329g767a8d8at2c12dd72a87ef7a3@mail.gmail.com>
	<46A71427.6050103@pressure.to> <46A7A804.20307@pressure.to>
Message-ID: <c2cd0d1d0707251616t7888357ck98e5cc8880907e3a@mail.gmail.com>

> The choice as far as I can see for now is to either
>
> - remove directors from GridCellEditor and GridCellRenderer; this means
> users can't write their own custom ruby DC code to paint directly on a
> cell when it's being edited or re-drawn. The standard Wx variants (eg
> Wx::GridCellFloatEditor) would still work
>
> or
>
> - warn users that they can't create more than modest-sized grids.
>
> What do you (or others) think?

I think limiting the grid size would be a bad idea, in one of my
programs I use a grid with 10 columns and over 100 rows. I can not
remember ever having a need to create my own drawing code for cell
editors and cell renderers.

So I guess I am for removing directors for now until some other
solution presents itself that does not compromise the size of the
grids.

Sean

From alex at pressure.to  Wed Jul 25 19:28:23 2007
From: alex at pressure.to (Alex Fenton)
Date: Thu, 26 Jul 2007 00:28:23 +0100
Subject: [wxruby-development] Memory problem with GridCell*Editor
In-Reply-To: <c2cd0d1d0707251616t7888357ck98e5cc8880907e3a@mail.gmail.com>
References: <c2cd0d1d0707231319k3434e1e8s8eda44a0db78a0b9@mail.gmail.com>	<46A51D4B.6040502@pressure.to>	<c2cd0d1d0707231517g5a56dfcdnfbeaf4a3a859a56@mail.gmail.com>	<46A54919.9010505@pressure.to>	<c2cd0d1d0707242329g767a8d8at2c12dd72a87ef7a3@mail.gmail.com>	<46A71427.6050103@pressure.to>
	<46A7A804.20307@pressure.to>
	<c2cd0d1d0707251616t7888357ck98e5cc8880907e3a@mail.gmail.com>
Message-ID: <46A7DC97.2060900@pressure.to>

Sean Long wrote:
> I think limiting the grid size would be a bad idea, in one of my
> programs I use a grid with 10 columns and over 100 rows. I can not
> remember ever having a need to create my own drawing code for cell
> editors and cell renderers.
>
> So I guess I am for removing directors for now until some other
> solution presents itself that does not compromise the size of the
> grids.

OK, I'm of the same view, though it's not ideal.

It could probably be fixed by writing a whole C++ subclass of wxGrid 
(wxRubyGrid) that does more efficient tracking of the diretor classes, 
and then wrapping it as Wx::Grid as is done in wxApp and WxArtProvider. 
But it's a hefty task and I don't think it's important enough right now.

If nothing more comes up I'll plan to tag over the weekend.

cheers
alex

From alex at pressure.to  Thu Jul 26 05:11:59 2007
From: alex at pressure.to (Alex Fenton)
Date: Thu, 26 Jul 2007 10:11:59 +0100
Subject: [wxruby-development] Memory problem with GridCell*Editor
In-Reply-To: <c2cd0d1d0707251616t7888357ck98e5cc8880907e3a@mail.gmail.com>
References: <c2cd0d1d0707231319k3434e1e8s8eda44a0db78a0b9@mail.gmail.com>	<46A51D4B.6040502@pressure.to>	<c2cd0d1d0707231517g5a56dfcdnfbeaf4a3a859a56@mail.gmail.com>	<46A54919.9010505@pressure.to>	<c2cd0d1d0707242329g767a8d8at2c12dd72a87ef7a3@mail.gmail.com>	<46A71427.6050103@pressure.to>
	<46A7A804.20307@pressure.to>
	<c2cd0d1d0707251616t7888357ck98e5cc8880907e3a@mail.gmail.com>
Message-ID: <46A8655F.7080208@pressure.to>

Sean Long wrote:
> I think limiting the grid size would be a bad idea, in one of my
> programs I use a grid with 10 columns and over 100 rows. I can not
> remember ever having a need to create my own drawing code for cell
> editors and cell renderers.

Removing Directors produced other undesirable behaviour and at the same 
time I thought of a better Ruby algo for handling cell editors. Good 
Ruby is still much faster than bad C++ and it seems to be OK with 
2000x2000 Grids.

I tried a few scenarios calling App#gc_stress in on_init and it seems to 
be stable, but let me know if there are still probs

alex

From noreply at rubyforge.org  Thu Jul 26 05:26:16 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 26 Jul 2007 05:26:16 -0400 (EDT)
Subject: [wxruby-development] [ wxruby-Feature Requests-12594 ] re-enable
	wxScintilla
Message-ID: <20070726092616.B24FE5240A26@rubyforge.org>

Feature Requests item #12594, was opened at 2007-07-26 09:26
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=221&aid=12594&group_id=35

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Alex Fenton (brokentoy)
Assigned to: Nobody (None)
Summary: re-enable wxScintilla

Initial Comment:
There is SWIG code to port Wx::Scintilla in swig/classes/optional and in the rakefiles. As of WxWidgets 2.8, there is also an up-to-date wx version of Scintilla available in the core library.

It would be nice to re-enable Wx::Scintilla in the core builds; this would involve compiling WxWidgets with this option (it's in ext/stc), moving the Scintilla.i file into swig/classes, and checking the right flags are being given in the rakefiles.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=221&aid=12594&group_id=35

From noreply at rubyforge.org  Thu Jul 26 20:29:40 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 26 Jul 2007 20:29:40 -0400 (EDT)
Subject: [wxruby-development] [ wxruby-Bugs-12610 ] Possible crash with
	EvtHandler.add_pending_evemt and custom event class
Message-ID: <20070727002941.2FB785240C59@rubyforge.org>

Bugs item #12610, was opened at 2007-07-27 00:29
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=218&aid=12610&group_id=35

Category: Incorrect behavior
Group: None
Status: Open
Resolution: None
Priority: 2
Submitted By: Alex Fenton (brokentoy)
Assigned to: Alex Fenton (brokentoy)
Summary: Possible crash with EvtHandler.add_pending_evemt and custom event class

Initial Comment:
If a custom event sets associated client_data using set_client_data, and then the event is queued using EvtHandler#add_pending_event the client_data may be prematurely deleted if GC runs before the event is actually processed.

Temporary workaround is to send the event for immediate processing via process_event.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=218&aid=12610&group_id=35