wxSizerItem used for painted (solid) areas

[ATS]

> A> A wxWindow object allocates (including system resources) around 4 kb
> A> of space on GTK. So it saves around 160 kb directly in one window. 
> 
>  If this is really an important problem we should add window-less widgets
> which would allow to avoid this overhead. But it would be just wrong from
> design point of view to do this at wxSizer level. The window-less widgets
> must be encapsulated at wxWindow level and I really think you would agree
> with this too if you looked at the situation from a general point of view
> forgetting about your specific use of sizers for a moment. Don't you?

Well, building my app, I'm concerned with it of course and look to solve
those problems. I haven't really tried to create optimal window-less 
widgets. 

What has evolved is more a set of classes that handles painted areas 
whose geometry are _fully_ determined by a holding sizer. As a side
note, even wxSizerItem has a bit more members / data than actually 
needed, but the fit was good enough I thought, and I didn't have to 
re-write any layout algos. 

I'm sure this could be optimized and generalized and made to work 
better with wxW, but that hasn't been a primary goal. 

The whole area of cross platform issues to provide a working library 
must have higher priority than a generic expansion along these lines. 
And I'd agree to that.


> A> A separate app uses this technique:
> A> 
> A> 1 - Rectangular areas are managed by wxSizer and wxSizerItems. 
> 
>  Maybe we should make it possible to have user-defined wxSizerItems. This
> might provide some useful additional flexibility.

I've changed wxWrapSizer so that it now has a member function: 

protected: 
    virtual bool IsSpaceItem( wxSizerItem *psi );

So, the virtual bit is moved from wxSizerItem to wxWrapSizer. A 
class deriving from wxWrapSizer can now decide for itself if it is
a solid / space item. (This solution didn't come to my mind until 
yesterday). Note: This is not an API function, but something that 
a derived class can override (which my app will have to do). Most 
apps would not use it. 

I'll submit an updated patch for this.

Regrads
// ATS

>  Regards,
> VZ
>