[wxPython-dev] SoC Unit Test Status

[Robin Dunn]

Kevin Ollivier wrote:

> Looking at the test failures, I think a number of them are due to 
> ambiguities, as Frank mentioned. For the ClientRect failure, my guess is 
> that the client rect is adding the control's border to the x and y 
> positions. Or perhaps it's giving it's x,y relative to the parent? 

     wxRect GetClientRect() const
     {
         return wxRect(GetClientAreaOrigin(), GetClientSize());
     }

Both GetClientAreaOrigin and GetClientSize will call platform specific 
methods located in the derived classes, so they can (and do) vary across 
platforms and window types.  IMO because of this potential variability 
the only valid test for GetClientRect is that it returns a rectangle 
positioned at GetClientAreaOrigin and with a size of GetClientSize.


> Also, 
> will GetClientSize always return a value >= the MinSize?

No.  The min size is just a hint for sizers and in the case of top-level 
windows it's also a hint for the window manager.  In most cases it's 
possible to explicitly set the size smaller than the minsize.  Even if 
that is not the case, the min size is for the whole window, whereas the 
client size can be smaller than that depending on window type, platform 
and how borders and other decorations are accounted for.

> 
> As for the virtual size failures, I suspect the issue is that 
> SetVirtualSize doesn't allow the virtual size to go below the control's 
> current size? Is that correct?

It is limited based on what the virtual size hints are currently set to. 
  Here is the common (platform independent) base class version:

void wxWindowBase::DoSetVirtualSize( int x, int y )
{
     if ( m_minVirtualWidth != wxDefaultCoord && m_minVirtualWidth > x )
         x = m_minVirtualWidth;
     if ( m_maxVirtualWidth != wxDefaultCoord && m_maxVirtualWidth < x )
         x = m_maxVirtualWidth;
     if ( m_minVirtualHeight != wxDefaultCoord && m_minVirtualHeight > y )
         y = m_minVirtualHeight;
     if ( m_maxVirtualHeight != wxDefaultCoord && m_maxVirtualHeight < y )
         y = m_maxVirtualHeight;

     m_virtualSize = wxSize(x, y);
}


Again this method can be overridden in the derived classes to have 
different behavior if needed for that class.



>  It makes sense, but if so, we should 
> update the tests and the documentation to reflect that. Also, Robin, the 
> Get/SetVirtualSizeWH APIs just convert tuples into wx.Size (and 
> vice-versa) then call the wx.Size version of the method, right?

SWIG sees these declarations:

     void SetVirtualSize(const wxSize& size );
     %Rename(SetVirtualSizeWH, void,  SetVirtualSize( int w, int h ));

so in addition to the wrapper for the regular SetVirtualSize it 
generates a Python wrapper method named SetVirtualSizeWH which calls the 
C++ SetVirtualSize which takes two parameters.  On the C++ side we have 
these methods:

     void SetVirtualSize( const wxSize &size ) { DoSetVirtualSize( 
size.x, size.y ); }
     void SetVirtualSize( int x, int y ) { DoSetVirtualSize( x, y ); }


So, yes they do exactly the same thing, but just provide a way for the 
programmer to have more choices on how to call them.  For the getters we 
have this for SWIG:

     wxSize GetVirtualSize() const;
     DocDeclAName(
         void, GetVirtualSize( int *OUTPUT, int *OUTPUT ) const,
         "GetVirtualSizeTuple() -> (width, height)",
         GetVirtualSizeTuple);

And this C++ code:


     wxSize GetVirtualSize() const { return DoGetVirtualSize(); }
     void GetVirtualSize( int *x, int *y ) const
     {
         wxSize s( DoGetVirtualSize() );

         if( x )
             *x = s.GetWidth();
         if( y )
             *y = s.GetHeight();
     }


This same pattern is fairly common in wx and wxPython.


> If so, 
> maybe a test that ensures GetVirtualSizeWH returns the same value as 
> GetVirtualSize would be sufficient.

Also that setting the same value via the two setters results in the same 
values.  Also via using the VirtualSize property.


> 
> One last question for Frank. I noticed you have an assert for missing 
> wx.Slider.GetRange(). AFAICT, that function is not part of the wx.Slider 
> API. It probably SHOULD be, as we have SetRange(min, max), but right now 
> you get the values by calling GetMin() and GetMax(). It was probably 
> done this way because in C++ returning two values is difficult and they 
> didn't want to use wx.Size or wx.Point for it, so they just stuck with 
> the GetMin/GetMax functions.

Actually it's good to point out things like that because it's super easy 
to add something like this in the declarations that SWIG sees:

     %pythoncode {
         def GetRange(self):
             return self.GetMin(), self.GetMax()
     }


-- 
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!