From: Winston W. <win...@st...> - 2006-04-29 03:29:34
|
I agree 100% on the Aims. The rest, I can't comment on though. -ww > 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 > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Pythoncard-users mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncard-users ______________________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com learning by creating - video game courses for kids in new york |