From nobody at rubyforge.org  Fri Jun  1 12:21:14 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Fri,  1 Jun 2007 12:21:14 -0400 (EDT)
Subject: [Wxruby-development] [1044] trunk/wxruby2: Special memory
	management for Wx::Grid
Message-ID: <20070601162114.813175240A63@rubyforge.org>

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

From sean.m.long at gmail.com  Fri Jun  1 14:47:32 2007
From: sean.m.long at gmail.com (Sean Long)
Date: Fri, 1 Jun 2007 11:47:32 -0700
Subject: [Wxruby-development] Memory management
In-Reply-To: <c2cd0d1d0705230911ud9c5d65kc4487f4ae82ebfbd@mail.gmail.com>
References: <4651EB4A.9070401@pressure.to>
	<c2cd0d1d0705211200m19076651u2f5582399798798b@mail.gmail.com>
	<c2cd0d1d0705211320y48646045nb4b7985cef8b9b02@mail.gmail.com>
	<4652A8AB.5080203@pressure.to>
	<c2cd0d1d0705221012x5afb066bq199bbea1e4b78869@mail.gmail.com>
	<4653699E.8030509@pressure.to>
	<c2cd0d1d0705221524n25c21fa2q96b157aa00be114c@mail.gmail.com>
	<4653E30B.6010509@pressure.to>
	<c2cd0d1d0705230911ud9c5d65kc4487f4ae82ebfbd@mail.gmail.com>
Message-ID: <c2cd0d1d0706011147l150af333m75cba6def34704ca@mail.gmail.com>

Alex,

The last few commits fixed a few more problems with the samples. The
following still have memory related problems.

In AUI:
- Trying to resize the window crashes the app.
- Also getting: No event class defined for event type 10090

In treectrl:
- Trying to resize the window crashes the app, but only after on GC
mark phase has already happened

Excellent work BTW

Sean

On 5/23/07, Sean Long <sean.m.long at gmail.com> wrote:
> Thanks that will be helpful
>
> Sean
>
> On 5/22/07, Alex Fenton <alex at pressure.to> wrote:
> > Sean Long wrote:
> > > How are you debugging these problems so quickly, are you using a
> > > special ruby debugger or something I don't know about?
> > >
> > >
> > I'm using gdb. On OS X and Linux I run the sample like this (assuming
> > you're in the base wxruby2 directory)
> >
> > gdb --args ruby -Ilib samples/minimal/minimal.rb
> >
> > This'll bring up a gdb prompt. Type 'r' to run the sample. When it
> > crashes the sample will freeze, rather than exit, and the gdb prompt
> > will come back. I type 'where' to get a backtrace. It's pretty long but
> > usually the relevant frame is in the first fifteen or twenty frames.
> >
> > When the crashes arise in the wx API functions, it usually means a C++
> > object has got deleted too early. When the crashes come in rb_funcall in
> > a SWIG_Director, it usually means a ruby object has got deleted too early.
> >
> > a
> > _______________________________________________
> > Wxruby-development mailing list
> > Wxruby-development at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/wxruby-development
> >
>

From alex at pressure.to  Mon Jun  4 17:12:08 2007
From: alex at pressure.to (Alex Fenton)
Date: Mon, 04 Jun 2007 22:12:08 +0100
Subject: [Wxruby-development] Memory management
In-Reply-To: <c2cd0d1d0706011147l150af333m75cba6def34704ca@mail.gmail.com>
References: <4651EB4A.9070401@pressure.to>	<c2cd0d1d0705211200m19076651u2f5582399798798b@mail.gmail.com>	<c2cd0d1d0705211320y48646045nb4b7985cef8b9b02@mail.gmail.com>	<4652A8AB.5080203@pressure.to>	<c2cd0d1d0705221012x5afb066bq199bbea1e4b78869@mail.gmail.com>	<4653699E.8030509@pressure.to>	<c2cd0d1d0705221524n25c21fa2q96b157aa00be114c@mail.gmail.com>	<4653E30B.6010509@pressure.to>	<c2cd0d1d0705230911ud9c5d65kc4487f4ae82ebfbd@mail.gmail.com>
	<c2cd0d1d0706011147l150af333m75cba6def34704ca@mail.gmail.com>
Message-ID: <46648028.5050908@pressure.to>

Hi Sean

Thanks for the update. I think we're getting there...

Sean Long wrote:
> In AUI:
> - Trying to resize the window crashes the app.
> - Also getting: No event class defined for event type 10090
>   
Not sure what's going on here. Will look into it. I overhauled the event 
handling system to make it a bit easier to manage, but it will probably 
show up a few event classes that we've missed on the way.
> In treectrl:
> - Trying to resize the window crashes the app, but only after on GC
> mark phase has already happened
>
>   
Pretty sure this is down to a Wx::ImageList not being marked properly - 
hopefully will have patch for this shortly.

cheers
alex


From nobody at rubyforge.org  Tue Jun  5 16:05:23 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue,  5 Jun 2007 16:05:23 -0400 (EDT)
Subject: [Wxruby-development] [1045]
	trunk/wxruby2/swig/classes/include/wxImage.h: Add missing
	Size and Resize methods in Wx::Image
Message-ID: <20070605200523.74272A970003@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070605/1a2416d6/attachment.html 

From nobody at rubyforge.org  Tue Jun  5 16:06:13 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue,  5 Jun 2007 16:06:13 -0400 (EDT)
Subject: [Wxruby-development] [1046] trunk/wxruby2/swig/classes/TreeCtrl.i:
	Prevent crashes in TreeCtrl from premature deletion of
	associated ImageList
Message-ID: <20070605200613.76970A970003@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070605/6b1b10f0/attachment-0001.html 

From nobody at rubyforge.org  Tue Jun  5 16:06:45 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue,  5 Jun 2007 16:06:45 -0400 (EDT)
Subject: [Wxruby-development] [1047] trunk/wxruby2/swig/classes/ListCtrl.i:
	Prevent crashes in ListCtrl from premature deletion of
	associated ImageList
Message-ID: <20070605200645.D5B53A970003@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070605/326d40a2/attachment.html 

From nobody at rubyforge.org  Tue Jun  5 16:07:23 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue,  5 Jun 2007 16:07:23 -0400 (EDT)
Subject: [Wxruby-development] [1048]
	trunk/wxruby2/samples/bigdemo/wxListCtrl_virtual.rbw: Fix
	broken path to Bitmap file for item image
Message-ID: <20070605200723.D40FC5240A4C@rubyforge.org>

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

From nobody at rubyforge.org  Tue Jun  5 16:08:06 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue,  5 Jun 2007 16:08:06 -0400 (EDT)
Subject: [Wxruby-development] [1049] trunk/wxruby2/lib/wx/classes/bitmap.rb:
	Raise an exception if an invalid file path is passed to Bitmap ctor
Message-ID: <20070605200806.BC0295240A4C@rubyforge.org>

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

From nobody at rubyforge.org  Tue Jun  5 16:13:43 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue,  5 Jun 2007 16:13:43 -0400 (EDT)
Subject: [Wxruby-development] [1050] trunk/wxruby2/doc/textile: Delete doc
	references to remove assign_image_list methods in Tree/ListCtrl
Message-ID: <20070605201343.EA2DAA970003@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070605/4db9b863/attachment.html 

From nobody at rubyforge.org  Tue Jun  5 18:22:14 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue,  5 Jun 2007 18:22:14 -0400 (EDT)
Subject: [Wxruby-development] [1051] trunk/wxruby2/samples/aui/aui.rb:
	Changed assign_image_list to set_image_list.
Message-ID: <20070605222214.58EC05240A4F@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070605/2e81614c/attachment-0001.html 

From sean.m.long at gmail.com  Tue Jun  5 18:26:08 2007
From: sean.m.long at gmail.com (Sean Long)
Date: Tue, 5 Jun 2007 15:26:08 -0700
Subject: [Wxruby-development] Memory management
In-Reply-To: <46648028.5050908@pressure.to>
References: <4651EB4A.9070401@pressure.to>
	<c2cd0d1d0705211320y48646045nb4b7985cef8b9b02@mail.gmail.com>
	<4652A8AB.5080203@pressure.to>
	<c2cd0d1d0705221012x5afb066bq199bbea1e4b78869@mail.gmail.com>
	<4653699E.8030509@pressure.to>
	<c2cd0d1d0705221524n25c21fa2q96b157aa00be114c@mail.gmail.com>
	<4653E30B.6010509@pressure.to>
	<c2cd0d1d0705230911ud9c5d65kc4487f4ae82ebfbd@mail.gmail.com>
	<c2cd0d1d0706011147l150af333m75cba6def34704ca@mail.gmail.com>
	<46648028.5050908@pressure.to>
Message-ID: <c2cd0d1d0706051526q6c5a9de4h4a933d14aeac5819@mail.gmail.com>

As of commit 1051 the AUI and Treectrl sample are now working. The
problem must have been the treectrl code in each sample.

Sean

On 6/4/07, Alex Fenton <alex at pressure.to> wrote:
> Hi Sean
>
> Thanks for the update. I think we're getting there...
>
> Sean Long wrote:
> > In AUI:
> > - Trying to resize the window crashes the app.
> > - Also getting: No event class defined for event type 10090
> >
> Not sure what's going on here. Will look into it. I overhauled the event
> handling system to make it a bit easier to manage, but it will probably
> show up a few event classes that we've missed on the way.
> > In treectrl:
> > - Trying to resize the window crashes the app, but only after on GC
> > mark phase has already happened
> >
> >
> Pretty sure this is down to a Wx::ImageList not being marked properly -
> hopefully will have patch for this shortly.
>
> cheers
> alex
>
> _______________________________________________
> Wxruby-development mailing list
> Wxruby-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-development
>

From nobody at rubyforge.org  Tue Jun  5 18:27:55 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue,  5 Jun 2007 18:27:55 -0400 (EDT)
Subject: [Wxruby-development] [1052] trunk/wxruby2: Remove unwanted
	Notebook#assign_image_list method, update docs
Message-ID: <20070605222755.1EAAF5240A58@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070605/1e755a43/attachment.html 

From nobody at rubyforge.org  Tue Jun  5 18:29:55 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue,  5 Jun 2007 18:29:55 -0400 (EDT)
Subject: [Wxruby-development] [1053] trunk/wxruby2/samples: Change
	references to assign_image_list methods to set_image_list in samples
Message-ID: <20070605222955.2B0925240A58@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070605/82a6c8db/attachment.html 

From nobody at rubyforge.org  Wed Jun  6 17:02:18 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed,  6 Jun 2007 17:02:18 -0400 (EDT)
Subject: [Wxruby-development] [1054] trunk/wxruby2: Add missing EraseEvent
	and mapping for EVT_ERASE_BACKGROUND, fix unknown
Message-ID: <20070606210218.B89DA5240B14@rubyforge.org>

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

From noreply at rubyforge.org  Fri Jun  8 11:48:32 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  8 Jun 2007 11:48:32 -0400 (EDT)
Subject: [Wxruby-development] [ wxruby-Bugs-11446 ] Wx::TextCtrl behaves
	wrong when scrolling
Message-ID: <20070608154832.619B05240AA6@rubyforge.org>

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

Category: Incorrect behavior
Group: current
Status: Open
Resolution: None
Priority: 3
Submitted By: Mario Steele (eumario)
Assigned to: Kevin Smith (qualitycode)
Summary: Wx::TextCtrl behaves wrong when scrolling

Initial Comment:
On wxGTK, the behavior of Wx::TextCtrl works as expected, it scrolls smoothly on the text through the buffer.  Recently, just checking code on Windows, and found that the Wx::TextCtrl does not scroll smoothly as expected.  Instead of scrolling through the buffer, as text is appended with AutoScroll enabled, it flashes the text incoming past the bounds of the control, to the top, you can scroll up, and have the text reset, but once more text is added, it'll flash it, and put the new text at the top as before.  This has only been observed on wxMSW Version of v0.0.40

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

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

From mario at ruby-im.net  Tue Jun 19 02:22:53 2007
From: mario at ruby-im.net (Mario Steele)
Date: Tue, 19 Jun 2007 01:22:53 -0500
Subject: [Wxruby-development] Wx::ToolBar#insert_tool
Message-ID: <a4439dea0706182322m3c35a187ia1c4a8366a5afc6d@mail.gmail.com>

Hey guys,

Wx::ToolBar#insert_tool, is either not referenced right, or needs to be
updated.

1.)  Wx::ToolBar#insert_tool(size_t
pos, ToolBarToolBase tool) comes up with a No overloading function
type error, AKA 404 Not Found
2.) Wx::ToolBar#insert_tool(size_t pos, Integer toolId, Bitmap bitmap1,
Bitmap bitmap2 = NullBitmap, Boolean isToggle = false, Object clientData =
nil, String shortHelpString = "", String longHelpString = "")  Should have a
reference also in the parameters to String label just after Integer toolId,
to conform with Wx::ToolBar#add_tool().

Just thought I'd give you guys a heads up on some of the stuff I found.
 More to come when I find it.

Mario Steele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070619/46f0cc9c/attachment.html 

From noreply at rubyforge.org  Wed Jun 20 06:53:46 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 20 Jun 2007 06:53:46 -0400 (EDT)
Subject: [Wxruby-development] [ wxruby-Bugs-11708 ]
	Wx::TreeCtrl#on_compare_items can not work
Message-ID: <20070620105346.8DA2A52409B4@rubyforge.org>

Bugs item #11708, was opened at 2007-06-20 06:53
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=218&aid=11708&group_id=35

Category: Incorrect behavior
Group: v0.4
Status: Open
Resolution: None
Priority: 3
Submitted By: Nobody (None)
Assigned to: Kevin Smith (qualitycode)
Summary: Wx::TreeCtrl#on_compare_items can not work

Initial Comment:
require "wx"


class MyTreeCtrl < Wx::TreeCtrl
    def initialize(parent)
       super parent, -1, Wx::DEFAULT_POSITION, Wx::DEFAULT_SIZE,  Wx::TR_DEFAULT_STYLE  | Wx::TR_EDIT_LABELS
    end
    
    def on_compare_items(item1, item2)
       raise   #no raise
    end
end


class MyFrame < Wx::Frame
  def initialize(title)
    super(nil, -1, title)
    @tree=MyTreeCtrl.new(self)
    @root = @tree.add_root("The Root Item")
    0.upto(15) do |x|
           child= @tree.append_item(@root, "Item " + x.to_s())
           @tree.sort_children(child)
    end
    @tree.sort_children(@root )
  end
end

class MyApp < Wx::App
  def on_init
    $frame = MyFrame.new("Minimal wxRuby App")
	  $frame.show
    return true
  end
  
  def on_fatal_exception
    puts("on_fatal_exception")
  end
  
  def on_exit
    puts("on_exit")
    return super
  end
end

a = MyApp.new
a.main_loop()
GC.start


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

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

From noreply at rubyforge.org  Thu Jun 21 11:37:37 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 21 Jun 2007 11:37:37 -0400 (EDT)
Subject: [Wxruby-development] [ wxruby-Bugs-11747 ] Segfault if unexpected
	type is returned by some director methods
Message-ID: <20070621153738.0B1075240B09@rubyforge.org>

Bugs item #11747, was opened at 2007-06-21 15:37
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=218&aid=11747&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: Segfault if unexpected type is returned by some director methods

Initial Comment:
Several possibly overridden ruby methods are called from C++ using directors - TreeCtrl#on_compare_items, App#filter_event - and are expectd to return an integer.

However, on OS X 10.3, if a non-Fixnum type is returned from ruby (eg nil) then it segfaults. This should be handled gracefully by raising a ruby TypeError exception.

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

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

From alex at pressure.to  Fri Jun 22 14:15:42 2007
From: alex at pressure.to (Alex Fenton)
Date: Fri, 22 Jun 2007 19:15:42 +0100
Subject: [Wxruby-development] Wx::ToolBar#insert_tool
In-Reply-To: <a4439dea0706182322m3c35a187ia1c4a8366a5afc6d@mail.gmail.com>
References: <a4439dea0706182322m3c35a187ia1c4a8366a5afc6d@mail.gmail.com>
Message-ID: <467C11CE.9080301@pressure.to>

Hi Mario

As elsewhere, apologies for the delay in replying (on holiday, off line).

Mario Steele wrote:
> 1.)  Wx::ToolBar#insert_tool(size_t 
> pos, ToolBarToolBase tool) comes up with a No overloading function type error, AKA 404 Not Found 
>
This has been commented out in the SWIG source headers. I guess this is 
because we don't support the ToolBarToolBase class.

I'm inclined to keep it this way and remove it from the documentation, 
rather than add a ToolBarTool class. With SWIG's per-class overhead, 
porting all the C++ struct-like classes like this one is a source of 
bloat, IMO.

> 2.) Wx::ToolBar#insert_tool(size_t pos, Integer toolId, Bitmap 
> bitmap1, Bitmap bitmap2 = NullBitmap, Boolean isToggle = false, Object 
> clientData = nil, String shortHelpString = "", String longHelpString = 
> "")  Should have a reference also in the parameters to String label 
> just after Integer toolId, to conform with Wx::ToolBar#add_tool().
>
Good spot. Looking at the 2.8.4 docs at

http://www.wxwidgets.org/manuals/2.8.4/wx_wxtoolbar.html#wxtoolbarinserttool

this appears to be documented wrongly in wxWidgets, but the actual wx 
headers are correct and include the label param. We've inherited that 
error, and I'll correct it.

> Just thought I'd give you guys a heads up on some of the stuff I 
> found.  More to come when I find it.
It's much appreciated - please keep sending them in.

cheers
alex

From nobody at rubyforge.org  Fri Jun 22 14:59:20 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Fri, 22 Jun 2007 14:59:20 -0400 (EDT)
Subject: [Wxruby-development] [1055] trunk/wxruby2/swig/classes/ToolBar.i:
	Chnage methods returning ToolBarToolBase to return position
	of new tool; 
Message-ID: <20070622185920.7DC7F5240BC2@rubyforge.org>

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

From nobody at rubyforge.org  Fri Jun 22 15:00:22 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Fri, 22 Jun 2007 15:00:22 -0400 (EDT)
Subject: [Wxruby-development] [1056]
	trunk/wxruby2/swig/classes/include/wxToolBar.h: Add missing
	param to InsertTool long version; uncomment some methods now
Message-ID: <20070622190022.36B435240B87@rubyforge.org>

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

From nobody at rubyforge.org  Fri Jun 22 15:05:45 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Fri, 22 Jun 2007 15:05:45 -0400 (EDT)
Subject: [Wxruby-development] [1057]
	trunk/wxruby2/swig/classes/include/wxToolBar.h: Add new
	methods from the 2.8 API
Message-ID: <20070622190545.7ABE95240B33@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070622/406ba80f/attachment-0001.html 

From nobody at rubyforge.org  Fri Jun 22 15:26:16 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Fri, 22 Jun 2007 15:26:16 -0400 (EDT)
Subject: [Wxruby-development] [1058] trunk/wxruby2/swig: Move TB_ constants
	into ToolBar and add the new 2.8 ones.
Message-ID: <20070622192616.A56F05240C14@rubyforge.org>

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

From nobody at rubyforge.org  Fri Jun 22 15:39:32 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Fri, 22 Jun 2007 15:39:32 -0400 (EDT)
Subject: [Wxruby-development] [1059] trunk/wxruby2/doc/textile/toolbar.txtl:
	Update ToolBar documentation to reflect recent changes in API
Message-ID: <20070622193932.3BB985240BD3@rubyforge.org>

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

From mario at ruby-im.net  Sat Jun 23 02:31:22 2007
From: mario at ruby-im.net (Mario Steele)
Date: Sat, 23 Jun 2007 01:31:22 -0500
Subject: [Wxruby-development] Wx::ToolBar#insert_tool
In-Reply-To: <467C11CE.9080301@pressure.to>
References: <a4439dea0706182322m3c35a187ia1c4a8366a5afc6d@mail.gmail.com>
	<467C11CE.9080301@pressure.to>
Message-ID: <a4439dea0706222331q921fc6cne0d63e0aab4892a4@mail.gmail.com>

On 6/22/07, Alex Fenton <alex at pressure.to> wrote:
>
> Hi Mario
>
> As elsewhere, apologies for the delay in replying (on holiday, off line).


Not a problem Alex, I understand the need to be away from the
computer, and on a vaca.

Mario Steele wrote:
> > 1.)  Wx::ToolBar#insert_tool(size_t
> > pos, ToolBarToolBase tool) comes up with a No overloading function type
> error, AKA 404 Not Found
> >
> This has been commented out in the SWIG source headers. I guess this is
> because we don't support the ToolBarToolBase class.
>
> I'm inclined to keep it this way and remove it from the documentation,
> rather than add a ToolBarTool class. With SWIG's per-class overhead,
> porting all the C++ struct-like classes like this one is a source of
> bloat, IMO.
>

I can understand that, the only reason why I was looking into this, is cause
I'm working on a MUD/MUCK/MUSH/MUX/MOO (Refered to
here<http://en.wikipedia.com/wiki/MUCK>)
and I was creating my own Help Viewer, similar to Microsoft's Old HelpView32
system.  Part of the problem I was running into, was the fact that the Hide
button on the toolbar, needed to change text to Show, once the user hidden
the Sidebar that shows the search for topics, and Contents pages.  But, I
was getting fustrated with it, to the point that I finally just decided to
clean out the Toolbar, and re-create it, based upon the toggle of the page.
 Which seemed to work quite well.

> 2.) Wx::ToolBar#insert_tool(size_t pos, Integer toolId, Bitmap
> > bitmap1, Bitmap bitmap2 = NullBitmap, Boolean isToggle = false, Object
> > clientData = nil, String shortHelpString = "", String longHelpString =
> > "")  Should have a reference also in the parameters to String label
> > just after Integer toolId, to conform with Wx::ToolBar#add_tool().
> >
> Good spot. Looking at the 2.8.4 docs at
>
>
> http://www.wxwidgets.org/manuals/2.8.4/wx_wxtoolbar.html#wxtoolbarinserttool
>
> this appears to be documented wrongly in wxWidgets, but the actual wx
> headers are correct and include the label param. We've inherited that
> error, and I'll correct it.


Yeah, seeing that now in wxWidgets' documentation, I won't hold you to
the problem on that.  Oviously not your fault. LOL

> Just thought I'd give you guys a heads up on some of the stuff I
> > found.  More to come when I find it.
> It's much appreciated - please keep sending them in.


While we're on that subject, I was working on an XRC Dialog I created for
Editing worlds in my client, and I had it setup with a TreeCtrl, and several
edit text fields.  For some reason, when I added the entry to the TreeCtrl,
with an Image List assigned, it would not display the images I had in the
list, no matter which method I went with.  I looked through all of the
demos, and they work fine in the Demos, but mine just wouldn't work with it.
 I tried directly creating the Bitmap, with
Wx::Bitmap.new("./path/to/image.png")
PNG or GIF being the format, and tried going the round about way, with Wx::
Image.new("./path/to/image.png") and then doing Wx::Bitmap.new(theImage).
 Neither seemed to work.  Finally broke down, and decided to create a
ListCtrl in Icon Mode to set it up with, and make it more like a Windows
explorer type interface, with right click
editing properties on it for a Popup Menu.  Anything to add to what is up
with that?

And finally, another part of the problem, seem to also incure some kind of
segfault that I could not trace back to the source through GDB, that dealt
with the fact that when switching between items in the TreeCtrl, it would
set the value of an Item to the associated fields I had on the window.  It
also seemed to crash at random places, but always after so many times
switching between the items in the TreeCtrl.  I checked the debug, and it
always seemed to crash somewhere where Ruby was trying to get the text, and
set the value of it.  But the text was in a custom Structure I created for
the class.  Didn't make much sense, since I know, that it was available with
the information in the struct listing.

Anyways, thought I'd let ya know of thoes other two errors that I picked up,
before working around them.

Talk with ya later Alex,

Mario Steele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070623/b6d3662e/attachment-0001.html 

From nobody at rubyforge.org  Sat Jun 23 08:42:21 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sat, 23 Jun 2007 08:42:21 -0400 (EDT)
Subject: [Wxruby-development] [1060] trunk/wxruby2/swig/fixevents.rb:
	Include some previously missing events, rehash and simplify
Message-ID: <20070623124221.D7F205240A88@rubyforge.org>

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

From nobody at rubyforge.org  Sat Jun 23 12:32:21 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sat, 23 Jun 2007 12:32:21 -0400 (EDT)
Subject: [Wxruby-development] [1061]
	trunk/wxruby2/swig/classes/EvtHandler.i: Remove a lot of no
	longer needed includes from EvtHandler.i
Message-ID: <20070623163222.0F4FC5240AAF@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070623/15a6419d/attachment.html 

From nobody at rubyforge.org  Sat Jun 23 12:33:17 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sat, 23 Jun 2007 12:33:17 -0400 (EDT)
Subject: [Wxruby-development] [1062] trunk/wxruby2/swig/classes: Remove
	directors from some common classes where they are unnecessary
Message-ID: <20070623163318.313745240AAF@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070623/9ad90867/attachment.html 

From nobody at rubyforge.org  Sat Jun 23 14:00:13 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sat, 23 Jun 2007 14:00:13 -0400 (EDT)
Subject: [Wxruby-development] [1063]
	trunk/wxruby2/swig/classes/EvtHandler.i: Add a public
	'connect' method for handling arbitary user-defined events
Message-ID: <20070623180013.4BCBD5240AB9@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070623/143176c3/attachment.html 

From nobody at rubyforge.org  Sat Jun 23 14:00:42 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Sat, 23 Jun 2007 14:00:42 -0400 (EDT)
Subject: [Wxruby-development] [1064] trunk/wxruby2/swig/Events.i: Removed
	unused func, updated comments
Message-ID: <20070623180042.B724B5240AB9@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070623/58dd7b7e/attachment-0001.html 

From alex at pressure.to  Sat Jun 23 16:58:21 2007
From: alex at pressure.to (Alex Fenton)
Date: Sat, 23 Jun 2007 21:58:21 +0100
Subject: [Wxruby-development] Wx::ToolBar#insert_tool
In-Reply-To: <a4439dea0706222331q921fc6cne0d63e0aab4892a4@mail.gmail.com>
References: <a4439dea0706182322m3c35a187ia1c4a8366a5afc6d@mail.gmail.com>	<467C11CE.9080301@pressure.to>
	<a4439dea0706222331q921fc6cne0d63e0aab4892a4@mail.gmail.com>
Message-ID: <467D896D.7080506@pressure.to>

Hey Mario

Mario Steele wrote:
> I was creating my own Help Viewer, similar to Microsoft's Old 
> HelpView32 system. 
Out of interest, did you take a look at Wx::HtmlHelpViewer?
> Part of the problem I was running into, was the fact that the Hide 
> button on the toolbar, needed to change text to Show, once the user 
> hidden the Sidebar that shows the search for topics, and Contents 
> pages.  But, I was getting fustrated with it, to the point that I 
> finally just decided to clean out the Toolbar, and re-create it, based 
> upon the toggle of the page.  Which seemed to work quite well.
I gave the Toolbar class a pretty thorough working over, plus updated it 
to support the 2.8 API (inc clear_tools ;)). I decided to make the 
methods that in Wx return a ToolBarTool return the position that the 
Tool's been added in. Hopefully should be reasonably convenient to use.

> While we're on that subject, I was working on an XRC Dialog I created 
> for Editing worlds in my client, and I had it setup with a TreeCtrl, 
> and several edit text fields.  For some reason, when I added the entry 
> to the TreeCtrl, with an Image List assigned, it would not display the 
> images I had in the list, no matter which method I went with. 
...
>  Anything to add to what is up with that?
Couple of suggestions:

1) Make really sure that the path to the image is correct. If it's not, 
creating a Bitmap or Image fail silently in recent versions; in C++ 
you're supposed to check that the image returns true to is_ok/ok before 
using it. In current SVN, if an image is created from a bad path it'll 
raise an exception.

2) I used to have hassle with PNGs of bigger bit depths with the old 
wxruby 0.6.0 to the point that I gave up and used XPMs. But I haven't 
had so many problems with this in wxruby2.

>
> And finally, another part of the problem, seem to also incure some 
> kind of segfault that I could not trace back to the source through 
> GDB, that dealt with the fact that when switching between items in the 
> TreeCtrl, it would set the value of an Item to the associated fields I 
> had on the window.  It also seemed to crash at random places, but 
> always after so many times switching between the items in the 
> TreeCtrl.  I checked the debug, and it always seemed to crash 
> somewhere where Ruby was trying to get the text, and set the value of 
> it.  But the text was in a custom Structure I created for the class. 
>  Didn't make much sense, since I know, that it was available with the 
> information in the struct listing. 
Remind me what OS you're working on?

If it's happening a bit randomly, it might be a GC issue - something is 
getting hoovered up by Ruby when it shouldn't be. Feel free to post a 
stack trace.

cheers
alex

From mario at ruby-im.net  Sun Jun 24 04:15:30 2007
From: mario at ruby-im.net (Mario Steele)
Date: Sun, 24 Jun 2007 03:15:30 -0500
Subject: [Wxruby-development] Wx::ToolBar#insert_tool
In-Reply-To: <467D896D.7080506@pressure.to>
References: <a4439dea0706182322m3c35a187ia1c4a8366a5afc6d@mail.gmail.com>
	<467C11CE.9080301@pressure.to>
	<a4439dea0706222331q921fc6cne0d63e0aab4892a4@mail.gmail.com>
	<467D896D.7080506@pressure.to>
Message-ID: <op.tue2j4c753rrhy@compaq.gateway.2wire.net>

On Sat, 23 Jun 2007 15:58:21 -0500, Alex Fenton <alex at pressure.to> wrote:

> Hey Mario
>
> Out of interest, did you take a look at Wx::HtmlHelpViewer?

I have, but didn't know if I wanted to deal with the specs behind it.  I  
think this is more trial and error, to see what else can be bunched up  
when designing these things.  Ya know, find the bugs that I can find. :P


> I gave the Toolbar class a pretty thorough working over, plus updated it
> to support the 2.8 API (inc clear_tools ;)). I decided to make the
> methods that in Wx return a ToolBarTool return the position that the
> Tool's been added in. Hopefully should be reasonably convenient to use.

That's good to hear, seeing as I've been looking over things ensuring that  
anything that is findable, I can find, and let ya know about.  But so far,  
the solutions that I have come up with, haven't generated any other  
problems, as of yet.

>> While we're on that subject, I was working on an XRC Dialog I created
>> for Editing worlds in my client, and I had it setup with a TreeCtrl,
>> and several edit text fields.  For some reason, when I added the entry
>> to the TreeCtrl, with an Image List assigned, it would not display the
>> images I had in the list, no matter which method I went with.
> ...
>>  Anything to add to what is up with that?
> Couple of suggestions:
>
> 1) Make really sure that the path to the image is correct. If it's not,
> creating a Bitmap or Image fail silently in recent versions; in C++
> you're supposed to check that the image returns true to is_ok/ok before
> using it. In current SVN, if an image is created from a bad path it'll
> raise an exception.
>
> 2) I used to have hassle with PNGs of bigger bit depths with the old
> wxruby 0.6.0 to the point that I gave up and used XPMs. But I haven't
> had so many problems with this in wxruby2.

Reviewing these two suggestions, I've looked at the way I was doing it in  
both my TreeCtrl, and ListCtrl versions of the dialog I was using to "Edit  
Worlds", and from my understanding, I'm using the same exact method in  
both.  While the ListCtrl will display the Images with no problems, the  
TreeCtrl does not.  No matter which method I go with, it simply refuses to  
display the image in the TreeCtrl.  Though I haven't tried XPM, cause I  
don't have a Image to XPM converter laying around since I did the  
re-format on my computer.

I've settled for now, to work with a ListCtrl, as it seems to be working  
just as good, if not better, for my purposes.  And it makes things alot  
easier to navigate for some reason.  Oh well, as they say, Ce la Vie.

> Remind me what OS you're working on?
>
> If it's happening a bit randomly, it might be a GC issue - something is
> getting hoovered up by Ruby when it shouldn't be. Feel free to post a
> stack trace.

I'm thinking it's an GC issue, but seems to be cropping up in the most  
in-oppurtune places, that I cannot simply figure out why.  But what I have  
traced it down to, is that it only occurs when you do an  
EditCtrl#set_value() execution.  Don't have a stack trace, since I've  
switched to working with a different format, and I'm using both Windows  
and Linux to work on my project.  For linux, I'm using PCLinuxOS, which is  
an Mandrivia derivitive.

Right now, I'm comming to terms with learning how ListCtrl works, and  
found it to be alot easier to work with, so I am there fore going to keep  
with this method for now, as it seems to be the best method to work with  
for me at this time.  And it also seems to give me the path for least  
resistance.  If I can, I'll see about setting up a seperate sample of the  
dialog I was working with, and see if I can get the same error.  If I can,  
I'll forward it to ya, so you can test it out for yourself.

> cheers
> alex
> _______________________________________________
> Wxruby-development mailing list
> Wxruby-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-development

BTW, any news on the Socket wrapping?  I found that I had to do a work  
around myself to prevent the freezing of my app, by using a Timer to  
periodically check for data that is incoming to my client.  It's a  
temporary solution, but one that I'd rather not have to do with this  
Client, as it can have Multiple Connections going at the same time.  It's  
a lot easier to get an event that tells me when data is available, then to  
pro-activly check for the data.  Guess it's the lazy programmer in me. LOL

Cheers,
Mario


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

From nobody at rubyforge.org  Mon Jun 25 13:32:40 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Mon, 25 Jun 2007 13:32:40 -0400 (EDT)
Subject: [Wxruby-development] [1065]
	trunk/wxruby2/samples/bigdemo/wxTreeCtrl.rbw: Fix an icon
	file path issue
Message-ID: <20070625173241.5FD965240A4A@rubyforge.org>

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

From nobody at rubyforge.org  Mon Jun 25 13:42:15 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Mon, 25 Jun 2007 13:42:15 -0400 (EDT)
Subject: [Wxruby-development] [1066] trunk/wxruby2/swig: Move EVT constants
	in swig/classes/Event.i; add a few missing ones
Message-ID: <20070625174216.52EE85240A4A@rubyforge.org>

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

From nobody at rubyforge.org  Mon Jun 25 13:45:50 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Mon, 25 Jun 2007 13:45:50 -0400 (EDT)
Subject: [Wxruby-development] [1067] trunk/wxruby2: Set up event handlers in
	Ruby rather than by post-processing SWIG output
Message-ID: <20070625174550.F17115240A1D@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070625/6c3eaf52/attachment-0001.html 

From nobody at rubyforge.org  Mon Jun 25 14:37:07 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Mon, 25 Jun 2007 14:37:07 -0400 (EDT)
Subject: [Wxruby-development] [1068] trunk/wxruby2/lib/wx.rb: Ensure
	evthandler.rb is loaded before other classes which might modify
Message-ID: <20070625183707.DC0E75240A56@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070625/07abdaa2/attachment.html 

From nobody at rubyforge.org  Mon Jun 25 18:49:21 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Mon, 25 Jun 2007 18:49:21 -0400 (EDT)
Subject: [Wxruby-development] [1069] trunk/wxruby2/swig/typemap.i: Fix big
	memory leak in methods taking wxString as a parameter
Message-ID: <20070625224921.801825240A5A@rubyforge.org>

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

From nobody at rubyforge.org  Mon Jun 25 19:01:34 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Mon, 25 Jun 2007 19:01:34 -0400 (EDT)
Subject: [Wxruby-development] [1070] trunk/wxruby2/swig/fixdeleting.rb:
	Remove old, now unused, fixdeleting script
Message-ID: <20070625230135.737065240A67@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070625/007ad6cc/attachment.html 

From nobody at rubyforge.org  Mon Jun 25 19:56:34 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Mon, 25 Jun 2007 19:56:34 -0400 (EDT)
Subject: [Wxruby-development] [1071]
	trunk/wxruby2/swig/classes/include/wxCalendarEvent.h: Added
	missing SetWeekDay method
Message-ID: <20070625235634.E32425240A64@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070625/11d5bc22/attachment.html 

From nobody at rubyforge.org  Mon Jun 25 19:57:35 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Mon, 25 Jun 2007 19:57:35 -0400 (EDT)
Subject: [Wxruby-development] [1072] trunk/wxruby2/swig/shared/datetime.i:
	Add typemap for DateTime::WeekDay; plug mem leak with wxDateTime arg
Message-ID: <20070625235735.5DDA95240A64@rubyforge.org>

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

From nobody at rubyforge.org  Mon Jun 25 19:58:40 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Mon, 25 Jun 2007 19:58:40 -0400 (EDT)
Subject: [Wxruby-development] [1073]
	trunk/wxruby2/doc/textile/calendarevent.txtl: Explain that
	get/set_week_day work with Integers
Message-ID: <20070625235840.C61965240A64@rubyforge.org>

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

From nobody at rubyforge.org  Mon Jun 25 20:08:32 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Mon, 25 Jun 2007 20:08:32 -0400 (EDT)
Subject: [Wxruby-development] [1074] trunk/wxruby2/swig/classes: Add
	IconizeEvent and cleanup header file
Message-ID: <20070626000832.AC7215240A67@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070625/565c69d6/attachment.html 

From nobody at rubyforge.org  Mon Jun 25 20:09:34 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Mon, 25 Jun 2007 20:09:34 -0400 (EDT)
Subject: [Wxruby-development] [1075]
	trunk/wxruby2/lib/wx/classes/evthandler.rb: Send IconizeEvent
	to EvtHandlers
Message-ID: <20070626000934.6EDE05240AA4@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070625/4c072c04/attachment.html 

From nobody at rubyforge.org  Mon Jun 25 20:10:07 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Mon, 25 Jun 2007 20:10:07 -0400 (EDT)
Subject: [Wxruby-development] [1076]
	trunk/wxruby2/samples/etc/activation.rb: Added sample of
	IconizeEvent to activation sample
Message-ID: <20070626001007.195F65240A67@rubyforge.org>

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

From nobody at rubyforge.org  Tue Jun 26 04:03:53 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue, 26 Jun 2007 04:03:53 -0400 (EDT)
Subject: [Wxruby-development] [1077]
	trunk/wxruby2/swig/classes/StaticBoxSizer.i: Avoid
	crash-on-exit with StatBoxSizer by removing some unnec
	director methods
Message-ID: <20070626080353.6EFAF5240BE6@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070626/4cb533c1/attachment.html 

From nobody at rubyforge.org  Tue Jun 26 04:55:44 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue, 26 Jun 2007 04:55:44 -0400 (EDT)
Subject: [Wxruby-development] [1078] trunk/wxruby2: Map evt_spinctrl to
	SpinEvent instead of CommandEvent; add example to bigdemo
Message-ID: <20070626085544.DD440524097B@rubyforge.org>

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

From nobody at rubyforge.org  Tue Jun 26 05:00:58 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue, 26 Jun 2007 05:00:58 -0400 (EDT)
Subject: [Wxruby-development] [1079]
	trunk/wxruby2/swig/classes/StaticBoxSizer.i: Fix a misnamed
	function accidentally added in SVN:1077
Message-ID: <20070626090058.2EBD25240967@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070626/520151d4/attachment.html 

From nobody at rubyforge.org  Tue Jun 26 13:54:51 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue, 26 Jun 2007 13:54:51 -0400 (EDT)
Subject: [Wxruby-development] [1080] trunk/wxruby2/swig: Moved typemaps
	specific to SystemSetting out of general typemap file
Message-ID: <20070626175452.091285240AE0@rubyforge.org>

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

From nobody at rubyforge.org  Tue Jun 26 14:35:28 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue, 26 Jun 2007 14:35:28 -0400 (EDT)
Subject: [Wxruby-development] [1081] trunk/wxruby2: Added HyperlinkCtrl from
	the 2.8 API plus event mappings
Message-ID: <20070626183528.DAD625240B02@rubyforge.org>

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

From nobody at rubyforge.org  Tue Jun 26 14:38:40 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue, 26 Jun 2007 14:38:40 -0400 (EDT)
Subject: [Wxruby-development] [1082]
	trunk/wxruby2/doc/textile/hyperlinkctrl.txtl: Added
	HyperlinkCtrl and HyperlinkEvent documentation
Message-ID: <20070626183840.D24F35240B02@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070626/4a941f86/attachment-0001.html 

From nobody at rubyforge.org  Tue Jun 26 14:38:50 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue, 26 Jun 2007 14:38:50 -0400 (EDT)
Subject: [Wxruby-development] [1083]
	trunk/wxruby2/doc/textile/hyperlinkevent.txtl: Added
	HyperlinkCtrl and HyperlinkEvent documentation
Message-ID: <20070626183850.18BA55240B04@rubyforge.org>

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

From nobody at rubyforge.org  Tue Jun 26 14:41:20 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue, 26 Jun 2007 14:41:20 -0400 (EDT)
Subject: [Wxruby-development] [1084]
	trunk/wxruby2/swig/classes/SystemSettings.i: Fix missing
	punctuation in SystemSettings typemaps
Message-ID: <20070626184120.9A6D55240B04@rubyforge.org>

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

From nobody at rubyforge.org  Tue Jun 26 14:50:03 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue, 26 Jun 2007 14:50:03 -0400 (EDT)
Subject: [Wxruby-development] [1085] trunk/wxruby2/swig: Add checks and ruby
	exceptions for two common Wx::Window mistakes leading to
Message-ID: <20070626185003.475D45240B04@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070626/980e1b12/attachment.html 

From alex at pressure.to  Tue Jun 26 15:01:32 2007
From: alex at pressure.to (Alex Fenton)
Date: Tue, 26 Jun 2007 20:01:32 +0100
Subject: [Wxruby-development] Wx::ToolBar#insert_tool
In-Reply-To: <op.tue2j4c753rrhy@compaq.gateway.2wire.net>
References: <a4439dea0706182322m3c35a187ia1c4a8366a5afc6d@mail.gmail.com>	<467C11CE.9080301@pressure.to>	<a4439dea0706222331q921fc6cne0d63e0aab4892a4@mail.gmail.com>	<467D896D.7080506@pressure.to>
	<op.tue2j4c753rrhy@compaq.gateway.2wire.net>
Message-ID: <4681628C.8040708@pressure.to>

Mario Steele wrote:
>> Out of interest, did you take a look at Wx::HtmlHelpViewer?
>>     
>
> I have, but didn't know if I wanted to deal with the specs behind it.  
Yeah, the format's not explained that well, took me a bit of trial and 
error to figure it out. But it works nicely with that done.
> I  
> think this is more trial and error, to see what else can be bunched up  
> when designing these things.  Ya know, find the bugs that I can find. :P
>
>   
That's good for us ;)

> Reviewing these two suggestions, I've looked at the way I was doing it in  
> both my TreeCtrl, and ListCtrl versions of the dialog I was using to "Edit  
> Worlds", and from my understanding, I'm using the same exact method in  
> both.  While the ListCtrl will display the Images with no problems, the  
> TreeCtrl does not.  No matter which method I go with, it simply refuses to  
> display the image in the TreeCtrl.  
Very weird...
> Right now, I'm comming to terms with learning how ListCtrl works, and  
> found it to be alot easier to work with, so I am there fore going to keep  
> with this method for now, as it seems to be the best method to work with  
> for me at this time.  And it also seems to give me the path for least  
> resistance.  If I can, I'll see about setting up a seperate sample of the  
> dialog I was working with, and see if I can get the same error.  If I can,  
> I'll forward it to ya, so you can test it out for yourself.
Great, please do.
> BTW, any news on the Socket wrapping?  I found that I had to do a work  
> around myself to prevent the freezing of my app, by using a Timer to  
> periodically check for data that is incoming to my client.  
No news so far. I buy the rationale for it, but there's a fair number of 
Socket classes to do and it's just not very far up my priority list at 
the moment.

At the moment I'm keen to ship a beta quality release with largely the 
classes we have at the moment. I'd also like to figure out some way to 
break up the functionality into different libraries like you suggested, 
as the core lib is getting a bit overweight with SWIG bloat.

cheers
alex


From nobody at rubyforge.org  Tue Jun 26 17:11:17 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue, 26 Jun 2007 17:11:17 -0400 (EDT)
Subject: [Wxruby-development] [1086]
	trunk/wxruby2/lib/wx/classes/evthandler.rb: Restore
	evt_mouse_events convenience handler, fixing bug in printing sample
Message-ID: <20070626211117.C7C025240B75@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070626/09b51001/attachment.html 

From nobody at rubyforge.org  Tue Jun 26 18:55:56 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Tue, 26 Jun 2007 18:55:56 -0400 (EDT)
Subject: [Wxruby-development] [1087]
	trunk/wxruby2/swig/classes/StaticBoxSizer.i: Fix a dopey typo
	introduced recently
Message-ID: <20070626225556.84DE55240B94@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070626/6f5c9fd8/attachment-0001.html 

From mario at ruby-im.net  Wed Jun 27 04:08:55 2007
From: mario at ruby-im.net (Mario Steele)
Date: Wed, 27 Jun 2007 03:08:55 -0500
Subject: [Wxruby-development] Splitting wxRuby2.so into multiple libraries
Message-ID: <op.tukl86mq53rrhy@compaq.gateway.2wire.net>

Hey Alex and fellow developers,

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, to ensure coherance amongst the developers, and future  
development, so people will know, this goes to this, this goes to that,  
etc, etc, etc.  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.  So this  
could be a good thing in the long run to.

Anyways, here is my suggestion for this, as I've helped another developer  
out with wrapping wxWidgets in another language, I saw how he designed the  
split up, and think this would be an ideal layout for this.  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.  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.

So my proposal is this:

Core File:
   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.   
Giving the developer a single file to work with for the base usability of  
wxRuby.

GUI Files:
   This part, involves setting up a single include, that would link to in  
some way (Dynamically, or Staticlly) to the Core file, to gain access to  
the wxWidgets API, to create each control / class defintion.  Such as it  
may be, Wx::Window, Wx::Frame, Wx::TextCtrl, Wx::TreeCtrl, Wx::Scintilla,  
Wx::Socket, so on and so forth.  This way, if someone wants to be mean and  
lean, they can just include the core file, then if they are only creating  
a simple text editor for an example, they would just need Wx::Frame, and  
Wx::TextCtrl or Wx::Scintilla, to create the controls that is needed.

   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.



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.   
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.  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.  Which seems a bit  
redundant, but it's just one way I would think of going about it, and may  
provide some speed improvements as well, considering that the DLL/SO that  
wxWidgets runs on, would not be directly impacted by the speed of Ruby  
itself.  Though that may be negligable in the long run as it is.

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.  All great,  
cause anything to bring this together would only benifit wxRuby in the  
long run, and open for expansion later on down the road.  Maybe looking at  
how 3rd Party wxWidget libraries are made up, may offer some insight into  
this delima?

I leave with that, and hope to discuss this further with you guys.

Mario Steele

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

From nobody at rubyforge.org  Wed Jun 27 14:17:42 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed, 27 Jun 2007 14:17:42 -0400 (EDT)
Subject: [Wxruby-development] [1088] trunk/wxruby2/swig/Functions.i: Added a
	return statement where needed to fix compile on Win32
Message-ID: <20070627181742.8516A5240AF1@rubyforge.org>

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

From nobody at rubyforge.org  Wed Jun 27 14:18:12 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed, 27 Jun 2007 14:18:12 -0400 (EDT)
Subject: [Wxruby-development] [1089] trunk/wxruby2/swig/classes/TreeCtrl.i:
	Hide missing method call in TreeCtrl on Win32
Message-ID: <20070627181812.56BDE5240AF1@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070627/01bdcd95/attachment.html 

From nobody at rubyforge.org  Wed Jun 27 19:10:03 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed, 27 Jun 2007 19:10:03 -0400 (EDT)
Subject: [Wxruby-development] [1090] trunk/wxruby2/swig/wx.i: Fix a rare
	crasher if GC runs mid-way thru window creation via an
	evt_window_create handler
Message-ID: <20070627231003.DD0B85240AC5@rubyforge.org>

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

From nobody at rubyforge.org  Wed Jun 27 20:09:11 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed, 27 Jun 2007 20:09:11 -0400 (EDT)
Subject: [Wxruby-development] [1091]
	trunk/wxruby2/lib/wx/classes/evthandler.rb: Add interim event
	type mappings for a few obscure oddities
Message-ID: <20070628000911.809615240B12@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070627/6fec7888/attachment.html 

From nobody at rubyforge.org  Wed Jun 27 20:28:09 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Wed, 27 Jun 2007 20:28:09 -0400 (EDT)
Subject: [Wxruby-development] [1092] trunk/wxruby2/swig/classes/App.i: Pass
	correctly typed Events into filter_event, if defined (bug 10797); 
Message-ID: <20070628002810.4ADFB5240B0E@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070627/5e14b966/attachment-0001.html 

From nobody at rubyforge.org  Thu Jun 28 04:03:37 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Thu, 28 Jun 2007 04:03:37 -0400 (EDT)
Subject: [Wxruby-development] [1093] trunk/wxruby2: Added ChildFocusEvent
	class, mapping and documentation
Message-ID: <20070628080337.59BA05240B3C@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070628/89d198ca/attachment.html 

From nobody at rubyforge.org  Thu Jun 28 04:35:06 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Thu, 28 Jun 2007 04:35:06 -0400 (EDT)
Subject: [Wxruby-development] [1094] trunk/wxruby2: Added SetCursorEvent and
	mapping
Message-ID: <20070628083506.4D39D5240A61@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070628/6210e73c/attachment.html 

From nobody at rubyforge.org  Thu Jun 28 14:42:03 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Thu, 28 Jun 2007 14:42:03 -0400 (EDT)
Subject: [Wxruby-development] [1095] trunk/wxruby2: Remove useless methods
	from Wx::Object and add wx_class method for info; document
Message-ID: <20070628184203.A4FF95240A8B@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070628/24f23f2e/attachment.html 

From nobody at rubyforge.org  Thu Jun 28 14:46:41 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Thu, 28 Jun 2007 14:46:41 -0400 (EDT)
Subject: [Wxruby-development] [1096]
	trunk/wxruby2/lib/wx/classes/evthandler.rb: Add mapping for
	another obscure and undocumented event type
Message-ID: <20070628184642.DD6795240B4B@rubyforge.org>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070628/94bcbe12/attachment-0001.html 

From nobody at rubyforge.org  Thu Jun 28 19:53:48 2007
From: nobody at rubyforge.org (nobody at rubyforge.org)
Date: Thu, 28 Jun 2007 19:53:48 -0400 (EDT)
Subject: [Wxruby-development] [1097] trunk/wxruby2/swig/classes/ClassInfo.i:
	Remove wxClassInfo class because it doesn't seem at all
	useful in Ruby
Message-ID: <20070628235348.BE30D5240B61@rubyforge.org>

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

From alex at pressure.to  Fri Jun 29 05:05:22 2007
From: alex at pressure.to (Alex Fenton)
Date: Fri, 29 Jun 2007 10:05:22 +0100
Subject: [Wxruby-development] Splitting wxRuby2.so into multiple
	libraries
In-Reply-To: <op.tukl86mq53rrhy@compaq.gateway.2wire.net>
References: <op.tukl86mq53rrhy@compaq.gateway.2wire.net>
Message-ID: <4684CB52.8000205@pressure.to>

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.

>  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.

> 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

>  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 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).

>    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.

> 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.

> 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.

> 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?
> 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).

cheers
alex