wxruby users - Aug 2006 - wxruby2 alpha release goals

Hi

We''re all keen to get a release out, for lots of reasons: getting more 
people testing, showing people the progress we''ve made, etc.  So I 
suggest that we now look to release an alpha version very soon, based 
pretty much on the current state of CVS plus pending check-ins.

Sure, it has some bugs, some missing features and segfaults occasionally 
- but my experience on OS X suggests it''s not horribly worse than
0.6.0,
and is lots better in other ways (i18n, additional classes and methods, 
GTK2 + OS X support). Particularly, I think it''s not the end of the 
world if we don''t support all 0.6.0 classes in a first release, and if 
memory mgmt is not completely sorted.

Looking over blogs, newsgroups, mailing lists etc, the main things that 
people don''t seem to like about wxRuby are:
1) Instability, 2) the docs, or lack of, and 3) the API being very C++ish.

So I humbly propose the following goals for an alpha release, and am 
prepared to work on getting these done. But please do disagree with the 
goals..

A) Fix the samples
B) Fix any big-time, regular crashers
C) Add some documentation, if possible
D) Add some easy, cheap ruby-ification to the API
E) Binary gems

A) Quite a few of the samples have got a little bit-rotted. We''ll make 
sure each one runs at least and looks correct, even if not every method 
works.

B) Nail crasher bugs that affect lots of code. But I think it''s fine, 
for things like ItemData, to tell people not to use it, rather than 
trying to fix the difficult memory management problems in full.

C) Zach''s work from early 2005 on the docs seemed really promising. He 
seemed to have developed a way of reading SWIG output and headers to 
make RDoc-ish output. Does anyone have this somewhere? It would be great 
to supply some rudimentary RDoc with a package.

D) I think we can do some things to make the API a bit more Rubyish 
without having to hack the interface files. Eg. a few lines that alias 
set_attr, get_attr and is_attr to more ruby-ish attr=(), attr() and 
attr?(). We can put in better plumbing later ;)

E) This is one where we can use help. Suggest we release as source 
tarball and gems. I''m happy to bundle binaries into platform gems.
OS X: Alex. Sean are you able to check on Mactel?
Win32: Roy? Curt? anyone?
Linux: Kevin? anyone?

Hope this sounds like a reasonable way forward - but please disagree. 
And shout if your manager has just offered you two months off your 
normal job to workk on wxruby ;)

cheers
alex

> So I suggest that we now look to release an alpha version very soon, based
> pretty much on the current state of CVS plus pending check-ins.
Sounds good to me, I am using that code base for a custom in house
program that is used nearly every day.
> Sure, it has some bugs, some missing features and segfaults occasionally
The most annoying bug I have is that pre built dialogs are starting
out with a negative x value for the dialog location and are not being
shown on screen when show() is called. An example of this is in the
caret sample when Wx::message_box() is called for the about box as
well as when Wx::get_number_from_user() is called. This problem exists
on Mac OS X Intel and PPC.
> A) Fix the samples
Consistent structure and style across all of them would be nice.
> B) Fix any big-time, regular crashers
Using Wx::GridCellBoolRender in a Wx::Grid crashes for me, have not
bothered to look into it too much.
> C) Add some documentation, if possible
I am pretty happy just using the standard wxWidgets HTML documentation
and knowing the naming rules for wxRuby.
- classes like wxDialog become Wx::Dialog
- methods like ShowModal() become show_modal()
- enums and constants like wxDefaultPosition become Wx::DEFAULT_POSITION
- etc.

Maybe we should just document the parts that stray from the C++
interface, like the wxWidgets docs do for wxPython and wxPerl.
> D) Add some easy, cheap ruby-ification to the API
I think for the first version we should leave this out and just try to
get a release under our belt. We can add it on later easy enough.
> E) Binary gems
I can help here by creating one for Mac OS X 10.4 PPC and Intel as
long as someone with more experience creates the gem spec.

I also have Ubuntu & Windows XP virtualized under Parallels on the
Intel Mac so I could help there if I have time.

I also think we should rip out all the comment fragments from the
include files, they are leftover from long ago the new classes added
do not have them.
>  And shout if your manager has just offered you two months off your
> normal job to workk on wxruby ;)
I wish :)

Sean

On Wed, 2006-08-02 at 14:21 -0700, Sean Long wrote:
> Alex wrote:
> > So I suggest that we now look to release an alpha version very soon,
based
> > pretty much on the current state of CVS plus pending check-ins.
> 
Sounds good, although we will need to agree on what "pretty much"
really
means.
> > A) Fix the samples
> 
> Consistent structure and style across all of them would be nice.
As long as someone is willing to take this on, fine. But I''m not sure
if
it would be worth delaying an alpha release for better samples. That is,
getting something out there with the problems documented might be better
than waiting (and waiting, and waiting). See below for related thoughts.
> > B) Fix any big-time, regular crashers
> 
> Using Wx::GridCellBoolRender in a Wx::Grid crashes for me, have not
> bothered to look into it too much.
Again, I would lean toward defining this as something like "if it causes
a sample to crash under simple usage, fix it". Otherwise, we run the
risk of trying to make it perfect before releasing, instead of following
the FLOSS rule of "release early and often".
> > C) Add some documentation, if possible
> 
> I am pretty happy just using the standard wxWidgets HTML documentation
> and knowing the naming rules for wxRuby.
I''m inclined to agree. This initial release should probably only be
used
by "motivated" developers who are willing to put up with a little
pain.
> > D) Add some easy, cheap ruby-ification to the API
> 
> I think for the first version we should leave this out and just try to
> get a release under our belt. We can add it on later easy enough.
I would rather postpone this, partly because I would like to really
think it through rather than making a little tweak here and there that
might end up being replaced by a better rubification a little later.
> > E) Binary gems
> 
> I can help here by creating one for Mac OS X 10.4 PPC and Intel as
> long as someone with more experience creates the gem spec.
> 
> I also have Ubuntu & Windows XP virtualized under Parallels on the
> Intel Mac so I could help there if I have time.
I can certainly create a Ubuntu-compatible Linux tarball. I have never
created a gem of any kind, so I would hope to get some guidance on that
part.
> I also think we should rip out all the comment fragments from the
> include files, they are leftover from long ago the new classes added
> do not have them.
I don''t view that as critical, although I think it''s a good
idea to do
eventually.

So I guess my take might be "release JUST what we have right now,
including pending patches, with known problems documented". I''m
just
afraid that fixing anything will delay the release by weeks, or months. 

A looser version would be to freeze the library code right away, and the
samples a week later, or some other "reasonable" amount of time.

Kevin

My two cents on this would be to get an alpha out ASAP that documents
known issues.  It would be helpful if the naming conventions and
parameters are generally the same as WxRuby1, but other, stylistic
changes can wait.

I found the "Poor Man''s
Documentation" to WxRuby1, as well as the code samples to be mostly
adequate in combination with the general WxWidgets documentation.  A later
documentation choice might be to annotate the WxWidgets documentation with
Ruby differences (that cannot be stated in general terms like naming
conventions).  I found such documentation for WxPython and WxPerl to be
helpful.  Essentially, the main WxWidgets documentation had insertions at
the beginning of each class description that pointed out what was added,
missing, or different in the calling syntax or behavior of the Python or
Perl implementation.

I would guess that the release of an alpha version will help to
create momentum for subsequent iterations of the project, stirring
more intrest, feedback, and contributions from the Ruby community.

Regards,
Jamal

hi

Basically, I think all Kevin and Sean''s preceding suggestions in this 
thread are excellent. So, for alpha1, in summary:
- no new classes/methods, bar pending patches
- fix major crashers, only,  in samples
- a bit of extra docs, on known bugs and how to use the WxW C++ docs
- I''m happy to make gems from supplied Linux & Win binaries as well
as OS X

Kevin Smith wrote:
> Sounds good, although we will need to agree on what "pretty much"
really
> means.
>   
how about, for the sake of alpha release - no new classes and methods. 
Everyone - yell if there''s something that you think MUST be in there 
that isn''t. And, preferably, follow the yell with a
patch.
>> Consistent structure and style across all of them would be nice.
>>     
> As long as someone is willing to take this on, fine. But I''m not
sure if
> it would be worth delaying an alpha release for better samples. 
>   
I agree
>  I would lean toward defining this as something like "if it causes
> a sample to crash under simple usage, fix it". 
I agree
> I''m inclined to agree. This initial release should probably only
be used
> by "motivated" developers who are willing to put up with a little
pain.
>   
OK. Let''s just make sure we add a brief, obvious note on how to use the
WxWidgets C++ docs.
> I would rather postpone this, partly because I would like to really
> think it through rather than making a little tweak here and there that
> might end up being replaced by a better rubification a little later.
>   
Yes, I think you and Sean are right. I''ll release my pure-ruby syntax 
sugar extensions shortly after the main alpha release to get some 
discussion going.
> I can certainly create a Ubuntu-compatible Linux tarball. I have never
> created a gem of any kind, so I would hope to get some guidance on that
> part.
>   
I''m have a working gemspec, and am happy to create binary gems for all 
platforms, if you supply me with a strip-ped platform .so/.lib/.bundle

Also I think we should supply a pre-swigged set of source files, for 
those that like that sort of thing. As a tarball and source
gem?
> So I guess my take might be "release JUST what we have right now,
> including pending patches, with known problems documented". 
Let''s do it! Roy/Kevin/Curt - are any of you able to review &
commit
mine and Sean''s pending patches some time in the next few days? I can 
htve a go otherwise. And throw anything back that causes probs, and if 
there''s no quick fix, we can integrate after we
release.
> A looser version would be to freeze the library code right away, and the
> samples a week later, or some other "reasonable" amount of time.
>   
ditto

all the best
alex

> Also I think we should supply a pre-swigged set of source files, for
> those that like that sort of thing. As a tarball and source gem?
The problem I see with the pre-swigged source files is that they are
specific for each platform. So for example we would need a release
like the following:
wxRuby2_alpha_1_src
wxRuby2_alpha_1_mac_os_x_ppc_gem
wxRuby2_alpha_1_mac_os_x_x86_gem
wxRuby2_alpha_1_windows_gem
wxRuby2_alpha_1_ubuntu_x86_gem

wxRuby2_alpha_1_mac_os_x_ppc_swigged_src
wxRuby2_alpha_1_mac_os_x_x86_swigged_src  #this one probably is the
exact same as ppc
wxRuby2_alpha_1_windows_swigged_src
wxRuby2_alpha_1_ubuntu_x86_swigged_src

That is a heck of a lot of files for an alpha release, especially
since it can not all be done on one machine by one dev (2 machine
minimum - a ppc mac, intel mac and virtualization software)

I say we shoot for the raw src and the 4 gem files. SWIG is not too
hard to install if someone is curious.
> > So I guess my take might be "release JUST what we have right now,
> > including pending patches, with known problems documented".
> Let''s do it!
I agree fire up CVS and lets add some patches!

Sean

On Thu, 2006-08-03 at 16:01 -0700, Sean Long wrote:
> The problem I see with the pre-swigged source files is that they are
> specific for each platform. 
> That is a heck of a lot of files for an alpha release, especially
> since it can not all be done on one machine by one dev (2 machine
> minimum - a ppc mac, intel mac and virtualization software)
> 
> I say we shoot for the raw src and the 4 gem files. SWIG is not too
> hard to install if someone is curious.
I agree.

Kevin

On Thu, 2006-08-03 at 19:27 +0100, Alex Fenton wrote:
> Let''s do it! Roy/Kevin/Curt - are any of you able to review &
commit
> mine and Sean''s pending patches some time in the next few days? I
can
> htve a go otherwise. And throw anything back that causes probs, and if 
> there''s no quick fix, we can integrate after we release.
I don''t expect to have any time until the middle of next week, at the
earliest. Total chaos here.

If things go according to plan, I should start to free up by the 12th.

Kevin

Just FYI: I am going to try really hard to set aside half a day this
weekend to catch up on wxruby cvs work. Really, really hard. I''m
announcing this as a further incentive to myself, to avoid breaking a
public commitment.

The good news is that two of the four "real life" pressures that have
been taking up my time for the last few months should be mostly finished
tomorrow. The other two are weekday activities, so hopefully I will be
able to put in some wxruby time each weekend for a while.

Kevin

On Fri, 2006-08-11 at 01:04 -0400, Kevin Smith wrote:
> Just FYI: I am going to try really hard to set aside half a day this
> weekend to catch up on wxruby cvs work. Really, really hard. I''m
> announcing this as a further incentive to myself, to avoid breaking a
> public commitment.
And fortunately I was able to follow through. All the July/August
patches have been merged (except one that I rejected).

I still have a bunch of messages from April to go through, but I believe
they were all problem reports, technical discussions, etc. 

If anyone has submitted patches that I have not responded to, please let
me know.
> The good news is that two of the four "real life" pressures that
have
> been taking up my time for the last few months should be mostly finished
> tomorrow. The other two are weekday activities, so hopefully I will be
> able to put in some wxruby time each weekend for a while.
I remain optimistic that I will be able to give wxruby at least 4-8
hours a week this month. Hopefully more after that, but it''s hard to
predict that far in the future.

Kevin

On Wed, 2006-08-02 at 14:21 -0700, Sean Long wrote:
> The most annoying bug I have is that pre built dialogs are starting
> out with a negative x value for the dialog location and are not being
> shown on screen when show() is called. An example of this is in the
> caret sample when Wx::message_box() is called for the about box as
> well as when Wx::get_number_from_user() is called. This problem exists
> on Mac OS X Intel and PPC.
Strange. The wx api clearly shows default values of -1 for the x and y
parameters. Looking at the wxruby code, it would seem that we are indeed
passing -1, -1 if those are not passed in from ruby. So it sounds like
an upstream bug in the Mac version of wx.

Kevin

This is a SWIG bug, the same as I was mentioning before.

Roy

Kevin Smith wrote:
> On Wed, 2006-08-02 at 14:21 -0700, Sean Long wrote:
>   
>> The most annoying bug I have is that pre built dialogs are starting
>> out with a negative x value for the dialog location and are not being
>> shown on screen when show() is called. An example of this is in the
>> caret sample when Wx::message_box() is called for the about box as
>> well as when Wx::get_number_from_user() is called. This problem exists
>> on Mac OS X Intel and PPC.
>>     
>
> Strange. The wx api clearly shows default values of -1 for the x and y
> parameters. Looking at the wxruby code, it would seem that we are indeed
> passing -1, -1 if those are not passed in from ruby. So it sounds like
> an upstream bug in the Mac version of wx.
>
> Kevin
>
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>
>

There may be a SWIG bug, but that''s not what is causing the message box
to come up in the wrong place. At least, not from what I am seeing.
Unless it''s a Mac-specific SWIG bug, which seems unlikely.

The C++ wrapper generated by swig appears to correctly default x and y
to -1 values. It then calls the wx MessageBox function. At that point,
if wx doesn''t recognize -1,-1 as being the "default
position", that
would be a bug in the Mac implementation of wx.

Maybe I''m missing something.

Kevin

On Sun, 2006-08-13 at 16:22 -0400, Roy Sutton wrote:
> This is a SWIG bug, the same as I was mentioning before.
> 
> Roy
> 
> Kevin Smith wrote:
> > On Wed, 2006-08-02 at 14:21 -0700, Sean Long wrote:
> >   
> >> The most annoying bug I have is that pre built dialogs are
starting
> >> out with a negative x value for the dialog location and are not
being
> >> shown on screen when show() is called. An example of this is in
the
> >> caret sample when Wx::message_box() is called for the about box as
> >> well as when Wx::get_number_from_user() is called. This problem
exists
> >> on Mac OS X Intel and PPC.
> >>     
> >
> > Strange. The wx api clearly shows default values of -1 for the x and y
> > parameters. Looking at the wxruby code, it would seem that we are
indeed
> > passing -1, -1 if those are not passed in from ruby. So it sounds like
> > an upstream bug in the Mac version of wx.
> >
> > Kevin
> >
> >
> > _______________________________________________
> > wxruby-users mailing list
> > wxruby-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/wxruby-users
> >
> >
> >
> >   
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users

Kevin,

What you''re missing is that deep down in the bowels of Wx it''s
calling
back to a function wrapped by SWIG.  When it gets passed off through the 
director the return values for where it should go aren''t returned to
the
calling function.  At least, that''s what I recall.  It took me quite a 
while to discover what was happening.  It may be my recollection is 
off.  I know the problem occurs with wrapping GetTextExtent.  I think it 
also affected a couple others.

Roy

Kevin Smith wrote:
> There may be a SWIG bug, but that''s not what is causing the
message box
> to come up in the wrong place. At least, not from what I am seeing.
> Unless it''s a Mac-specific SWIG bug, which seems unlikely.
>
> The C++ wrapper generated by swig appears to correctly default x and y
> to -1 values. It then calls the wx MessageBox function. At that point,
> if wx doesn''t recognize -1,-1 as being the "default
position", that
> would be a bug in the Mac implementation of wx.
>
> Maybe I''m missing something.
>
> Kevin
>
> On Sun, 2006-08-13 at 16:22 -0400, Roy Sutton wrote:
>   
>> This is a SWIG bug, the same as I was mentioning before.
>>
>> Roy
>>
>> Kevin Smith wrote:
>>     
>>> On Wed, 2006-08-02 at 14:21 -0700, Sean Long wrote:
>>>   
>>>       
>>>> The most annoying bug I have is that pre built dialogs are
starting
>>>> out with a negative x value for the dialog location and are not
being
>>>> shown on screen when show() is called. An example of this is in
the
>>>> caret sample when Wx::message_box() is called for the about box
as
>>>> well as when Wx::get_number_from_user() is called. This problem
exists
>>>> on Mac OS X Intel and PPC.
>>>>     
>>>>         
>>> Strange. The wx api clearly shows default values of -1 for the x
and y
>>> parameters. Looking at the wxruby code, it would seem that we are
indeed
>>> passing -1, -1 if those are not passed in from ruby. So it sounds
like
>>> an upstream bug in the Mac version of wx.
>>>
>>> Kevin
>>>
>>>
>>> _______________________________________________
>>> wxruby-users mailing list
>>> wxruby-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/wxruby-users
>>>
>>>
>>>
>>>   
>>>       
>> _______________________________________________
>> wxruby-users mailing list
>> wxruby-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wxruby-users
>>     
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>
>