wxSizerItem used for painted (solid) areas

[ATS]

> On Sat, 15 Mar 2008 16:27:14 +0000 (UTC) ATS <asteinarson at ...> wrote:
> 
> A> [discussion related to patch [ 1906333 ] wxSizerItem - IsEmptySpace]
> 
>  Thanks for posting here, I think I do understand what you mean now.
> But unfortunately now that [I think] I understand it, I don't like it 

First of all, this technique comes from an application that uses wxW. 
It's a stand alone library, that's all. There hasn't been any suggestion 
to include this technique in wxW or have wxW do the same thing. That's
off topic.

However, I developed the wxWrapSizer in this context and found it quite
useful. I don't depend on having it in the library, but wanted to make 
that contribution. 

I find it strange if the wxWrapSizer can no longer be used in the context
it was built in, due to opinions. 


> A> The basic idea is:
> A> 
> A> - wxSizerItem in spacer mode can represent either
> A> 
> A>   A - An empty area (this is the implicit assumption
> A>       in wxWidgets).
> A> 
> A>   B - An area that is painted in some other way. 
> A>       It is not a wxWindow and not a wxSizer but 
> A>       still painted on screen (despite being referred
> A>       to as a spacer).

B fits 100% into the use of a wxSizerItem, before specializing and 
creating a subtype called 'spacer' (which BTW is never exposed outside
of the file sizer.h/sizer.cpp).

> 
>  First, I disagree with the basic idea. For me -- and I think for most
> people when they hear the word "spacer" for the first time -- a spacer
> always represents a space and nothing else.

Finding new uses for an existing algorithm / data structure is very
much associated with development I feel. In particular if it is based on 
efficient reuse of existing code / classes and it leads to improved 
performance and reduced memory use. 

Try a slight modification here: 

    enum
    {
        Item_None,
        Item_Window,
        Item_Sizer,
        Item_Spacer,
        Item_CustomPainted,  // New line
        Item_Max
    } m_kind;

and there's no naming problem anymore. (NOTE!: I'm not asking anyone 
to do this but it illustrates that it's a matter of naming and could 
be resolved in this simple way.).

I think the name 'spacer' was chosen because it described the problem
initially looked at. Not to limit future usefulness of generic 
algorithms on rectangular areas.


> A> Type B items are very useful for representing small bits 
> A> and pieces like grippers, edges and micros buttons. Using 
> A> a wxWindow for each such item is too heavy and really not 
> A> needed. 
> 
>  Second, I disagree with this motivation: creating an extra window or two
> (or a dozen) is not a huge burden nowadays and if we really want to

A window caption uses 5 painted micro items. A toolbar group with 4 
small toolbars uses 4 of them. The layout I'm looking at has four 
such windows with captions and toolbars. Then there are edges. It 
adds up to 

  4 x (5+4) + 3 = 39 items 

A wxWindow object allocates (including system resources) around 4 kb
of space on GTK. So it saves around 160 kb directly in one window. 


>  In any case, I really, really object against using spacers for drawing.
> This would be very confusing and mixes totally different concepts.
> 

No-one is using using a spacer for drawing and they cannot paint itself. 
No-one has suggested to add such features to wxW. 

A separate app uses this technique:

1 - Rectangular areas are managed by wxSizer and wxSizerItems. 

2 - A class that owns a wxWindow.

3 - It traverses the layout tree and queries the items for their
area. It then paints those areas in a DC created for the owned 
wxWindow. 

In this context the wxWrapSizer was developed and as a generic sizing
algorithm contributed to the library. 


The technique has worked quite well for a long time now. I've found 
it easy / intuitive / efficient to work with. 

On the whole, the technique has suited the given layout problem well.
My experiences with it are positive, and that's after quite some use. 


Regards
// ATS.