wxruby users - Apr 2006 - Re: StaticBoxSizer bug?

Daniel,

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

Roy

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

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

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

On Mon, 2006-04-24 at 00:00 -0400, Roy Sutton wrote:
> Daniel F. Savarese wrote:
> > After that, I realized the overridden virtual method was missing in
> > wxStaticBoxSizer.h.  I''ve attached a patch.
> >   
> The patch didn''t apply for me.  I have created a new patch for the
two
> affected files.
The follow-up patches didn''t look right to me, as they were missing the
"virtual" keyword in some cases. So I took a mix of Daniel''s
original
patch and your two patches, and hopefully ended up with something great.
A special thanks to Daniel, not only for the patch, but for submitting a
great problem report with sample code. Definitely makes my job easier!
> > Now that I''ve spent enough time getting familiar with the way
the
> > code is generated, I''m left wondering if there''s an
alternative to
> > maintaining custom wxFoo.h headers.  Is there a way to generate them
> > from existing wxWidgets headers?  It seems error prone and a lot of
> > work to maintain a separate set of headers.  I''m probably
just
> > revealing my general ignorance of SWIG.
Not at all. The biggest problem in trying to SWIG the wx headers
directly is that wx is a complex cross-platform app. They actually have
a set of shared headers, and then a whole large set of headers for each
platform. The only way I could see that it might work would be to swig
each platform''s set of headers separately, but I''m afraid that
would
minimize our ability to fix bugs in one place to benefit all platforms.

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

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

Kevin

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

Roy

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

Roy

On Sun, 2006-04-30 at 02:07 -0400, Daniel F. Savarese
wrote:
> This is one of those style issues that''s hard to argue
convincingly one
> way or another.  I recommend always redeclaring overridden virtual methods
> as virtual so it''s obvious to the human reader they are virtual
without
> having to navigate the trail of ancestor classes.  
I agree.
> Of course, the compiler doesn''t care one way or another :)  
Actually, there may be cases where SWIG doesn''t have access to the
parent class. In those cases, it is critical that virtual is
re-declared.
> Roy and Kevin, thanks for all of the answers and explanation.  I''m
> used to the way things work at Apache, so I wasn''t sure what the
> development model was for wxruby2.  I''ll try to pitch in with
patches
> when and where I can, but it will probably come in a slow trickle.
Cool.

Kevin