Re: [Pythoncard-users] anchor layout manager

[Michael S. <mik...@ya...>]

--- Alex Tweedly <al...@tw...> wrote:
> Michael Sorich wrote:
> 
> >Attached is my latest attempt at a simple layout
> >manager. Once again, it is based on anchors with
> >automatic partitioning of the background into a
> grid
> >based on the positioning of expandable components.
> >Major changes from the previous attempt include:
> >  
> >
> >3) can now anchor so relative position of component
> to
> >both sides is held constant (component size does
> not
> >change)
> >
> >An example is attached. If anyone has a pythoncard
> >example where they have used wx sizers, see if this
> >method can replicate the result. Alternatively,
> send
> >the code to me and I will give it a go. 
> >  
> >
> The findfiles tool that comes with PythonCard is a
> good example using 
> sizers.

Findfiles seems to be a very simple example - the
listResults expands in the x and y dimensions and the
rest of the components remain anchored left and above.
Simply set the xAnchor and yAnchor values for
listResults (defaults will suffice for the rest) and
pass the components to GridAnchorLayout. Also, the
components defined in the resource file need to be
properly laid out (presumably because sizers were to
be used and hence positioning them well did not
matter). This reproduces the sizing on my windows box.
I don't have a Mac or a computer running Linux, so I
can't tell how cross platform the result is.

self.components.listResults.xAnchor = 'Both (resize)'
self.components.listResults.yAnchor = 'Both (resize)'
self.panel.layoutManager =
anchor.GridAnchorLayout(self.components)
self.visible = True
##self.sizerLayout()
 
> >I think that this method would be enhanced if it
> could
> >be complemented with an easy means of using
> splitter
> >windows (the split would not need to be visible or
> >user adjustable). This method divides the
> background
> >into a grid. In some/many cases different parts of
> the
> >background should have separate grids. 
> >
> >This method deals with resizing/repositioning of
> the
> >components with a change in the background size. It
> >does not deal with changes as a result of font size
> >changes.
> >  
> >
> I had to change your code slightly - in anchor.py,
> there were 3 cases of
>      for component in self.components:
> that needed to be
>      for component in self.components.itervalues(): 

Sorry about this. I find calling .itervalues()
unintuitive and have made components directly
iterable. I should remove the alteration so I am a
forced to use itervalues. 

> I also noticed that if I made the window wide
> enough, button3 and 
> button1 would overlap - was that expected ?

Due to the reduction in the number of gridlines
produced, it is now possible to set the anchors such
that the components overlap upon expansion of the
container (an obvious example having 2 components and
setting the left one to be right anchored and the
right one to be left anchored). In the example
provided only Button3 and StaticText2 have their
anchors explicitly set. All the rest are using default
values. The default value for buttons is left and
above. Button1 (and StaticText1) should really have
xAnchor = 'Right'. I originally had the default anchor
being the closest gridline, however in some examples
this did not come out right and it seemed to be best
to stick to left and above. I don't think that it will
be possible to correctly set anchors automatically for
all components.

> For splitter lines: I'd suggest a (temporary)
> convention using "Static 
> line"s that follow some naming scheme, e.g.
>  any Static Line whose name is anchorXyz is used as
> a splitter

I am not sure how this would work. Eg if you had a
horizontal static line that spanned only half the x
range of the container, what would this mean? Would
this be equivalent to a horizontal splitter at y =
staticLine.position[1]?  I think The alternative would
be too complicated. What happens when there are both
horizontal and vertical staticLineSplitters? Unless
placed well, it would be difficult to tell which takes
precedence (with 2 partions there are 2 choices for
producing 3 regions as would occur with a splitter
window) or whether they cross and produce a grid with
4 regions. I am not sure whether it would be more
difficult to write this hack or to simply tackle the
container issues of pythoncard :) 

>  there is a call available to turn all such lines
> invisible
>      (I almost said do that automatically - but it
> would be interesting 
> for now to see them, so make it under prog control)
> 
> Do you think there's room for using "Static box" in
> a similar way - the 
> box is treated as a separate sub-grid ?

I am not sure. I think that it is very important to
have use cases of layouts that need to be handled.
Most of the pythoncard samples are either trivial or
the components placed so haphazardly that I cannot
tell how they should be repositioned/resized.

> The biggest thing I'd like to see, which I think
> should be possible, is 
> to combine the anchor/constraint scheme with sizers
> used at the level of 
> built-in components. i.e. as you do the sizing, you
> allow components to 
> produce their own min size according to "standard"
> sizer methods, and 
> then use that within the constraint layout. IF
> that's possible, then I 
> think you have a good chance of overcoming the most
> significant 
> advantage of sizer schemes (automatic handling of
> cross-platform font 
> and decoration variations).

Is it possible to simulate cross-platform changes in
fonts etc using a single platform (windows in my
case)? Perhaps by simply changing the font? It would
make it easier to test some of these layout methods. I
suspect the repositioning/resizing method used to
adjust to font changes would be quite different to
adjusting to container resizing. I presume that the
adjustments would only need to be done once (at
initialization). If so, the font and container
adjustments would probably operate independently. When
the app is initialized the layout is adjusted for the
font used. Subsequently the container resizing layout
manager is initialized and used.

I am not completely sure what you are getting at in
regard to using "sizers at the level of built-in
components". Is this simply in regard to querying the
components for their minSize? If you could give and
example, it would be great.

Thanks for the comments.

> 
> -- Alex.
> 
>  
> 
> -- 
> Alex Tweedly       http://www.tweedly.net



Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com