[Pythoncard-users] Proposal for adding sizer support to PythonCard and the layoutEditor

[Alex T. <al...@tw...>]

Comments, suggestions, or any other feedback, welcome.

Aims

1. To provide support for sizer-based layouts, making it easy to design 
new projects which are fully based on a set of hierarchical sizers.

2. To continue to support absolute position based layout.

3. To make it easy to convert an existing absolute position based 
project into a sizer based one.

Summary.

Add a new child window to the layoutEditor (sizerWindow), which holds 
the tree of sizers and components. It will also hold a separate tree of 
"unplaced" components - i.e. those components from the absolute layout 
which have not yet been placed into the sizer tree. It will be possible 
to create new sizers and add them to this "unplaced" tree, and indeed to 
add components to such sizers, prior to placing the sizer into the real 
application sizer tree.

The user will be able to select components (one or more) in the layout 
window or in the sizerWindow, and then allocate those components into a 
sizer in the sizerTree; each sizer or component will have the obvious 
parameters set (e.g. weight, position, growability, etc.)

The ideal edit mode for moving components into the sizer tree is 
probably drag-and-drop, but because of the limitations on how items can 
be dropped into a treeCtrl, the initial version will use right-clicking 
on the tree to provide a pop-up menu providing options (e.g. edit 
properties, unplace, add selected components before, add selected 
components after, etc.)

Since no component can be placed more than once in the placed sizer 
tree, we can "fake" the ability to select sizers in the layout window. 
When "placing selected components" into a sizer, any component which has 
already been allocated to a sizer will not be (cannot be) allocated; 
however if this applies to all components within a particular sizer 
(i.e. they have all been selected), then that sizer will be allocated. 
This will facilitate the building of sizer trees "bottom-up" from an 
existing absolute position layout.

Impact on infrastructure.

The sizer information will be kept in the "background" dictionary within 
the resource file, under the key name "sizers". This will contain a list 
of sizers, each of which is a dictionary containing a name, type, flags, 
and "contents" - a list of items (components or sizers) or, in the case 
of  GridBagSizer,  a list of lists of items.  There will also be a new 
piece of background info which indicates that the sizer info is to be used.

This is therefore fully backward compatible - existing versions of the 
framework will silently ignore this entry (assuming it is correct Python 
code). New version of the framework used with old resource files will, 
based on the lack of  "useSizer" info will also ignore it, but if the 
useSizer flag is set they will instantiate a sizer tree, and also set 
the 'visible' flag to False for any components not listed in the sizer 
tree (thereby allowing the user to override the placement of complex 
examples, such as the layoutEditor itself, which use overlapping 
alternate components, etc.).

When the useSizer flag is being set true within the layoutEditor, or 
thereafter when the file is saved, the user will be warned if there are 
any such unplaced components being set to invisible.

Debugging ?

Fairly soon, wxWidgets (or maybe wxPython) will include the ability to 
get visual indication of the sizer boundaries, but until then the sizer 
layout will include the ability to display these; and in addition there 
will be an ability to provide log / print info on the sizers being 
added. The layoutEditor will also be able to output Python code 
equivalent to the specified sizers, which will give an alternative way 
to understand and debug the resulting layouts.

Phases of development.

Phase 1.

Framework. Build the code to be used within the application to create 
sizers and add the components to them. Initially this will be supplied 
as a separate additional file - will be integrated with resource/model 
later.

Phase 2.

Add the basic sizerWindow, support BoxSizers only. Simple component 
selection and flag/parameter setting.

Phase 3.
Add support for GridBagSizers, probably help / tooltip / documentation / 
walkthrough / ...

Phase 4.
The rest :-)

Phase 5.
Add drag-and-drop, replacing treeCtrl with a custom control if needed.


I expect Phase 1 to be complete in a day or two, Phase 2 in a week or so 
(but I haven't used treeCtrl before, so this is subject to some 
uncertainty).


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



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.6/323 - Release Date: 24/04/2006