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

[Andy T. <an...@ha...>]

Alex Tweedly wrote:
> 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).
> 
> 

+1

Regards,
Andy
-- 
--------------------------------------------------------------------------------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/