Paul McNett wrote: > At the risk of becoming an unwelcome complete pain in the ass :) I'd > like to suggest > an idea based on Qt Designer for the following workflow for form/class design: > > 1) The appdev adds controls, etc. > > 2) Position and size controls to the level of accuracy the appdev prefers, > without > sizers. > That sounds good to me. I added a set of 'multi-control' features to Pythoncard to allow easy movement, alignment, spreading, etc. and I could easily see myself prototyping a convertion of those features into ClassDesigner (though not until I've had a while to familiarize myself with Dabo, CD, etc.)
Finding the right ways to build a set of selected controls was probably harder than doing the various operations once the set was selected. What I finished up with was - click to select a single control - ctrl-click to toggle inclusion of a single control in the set - marquee-drag to select a set of controls - ctrl-marquee-drag to toggle inclusion of a set (*) (*) - should it toggle each one, or use a voting scheme to make the entire operation an include or exclude for all of the toggle-set ? An undecided question .... Given these selection methods, I think a 'lassoo' is overkill (and I think potentially hard to implement and/or use). > 3) Add the sizers after the prototype design is (mostly) done. Options for > lassoing > controls to put in the same sizer, or a set of builders/wizards that analyze > the > design to try to determine the best layout. If labels/controls are all lined > up, use > a gridsizer, etc. > > I like that idea in general, though the implementation of this kind of builder/wizard/dwim is tricky. Given that the 'Object info' window already has a tree view of the sizers/controls, it should be feasible to add selection of a control/sizer/set-of-controls within that window, and to implement drag/drop of that selected set to another part of the object tree. I did implement something much like that within the PythonCard layoutEditor (though it was never released, or - to be honest - completely finished, for various reasons). It was pretty quick and convenient to do this tree-building and modification for most window layouts. > There'd be a separate hierarchy of objects for actual controls and sizers. At > any > time the appdev could disable the currently defined sizer hierarchy, make > some design > mods, and then reenable the sizer hierarchy or start fresh with sizers. > > This gives the lowest barrier to entry, allows for really quick design > prototypes, > yet still encourages sizers. > I'm not 100% convinced it encourages sizers - but I would say that making the two modes completely distinct discourages them. -- Alex. _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/[EMAIL PROTECTED]
