Re: [Pythoncard-users] time to share your PythonCard gripes and likes

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

Sells, Fred wrote:

>A. Pythoncard runtime support.
>
>
>5. Additional compound widget. - a static text "label" and a text field 
>good idea; most common use is label:control so you need some way to define
>the default spacing so a bunch can be placed in a column with the labels and
>data entry fields properly lined up.
>
I still have no idea whether this would be
 - a single new component  (probably too many values need to be attached ??)
 - a container with two components (probably too complex)
 - a resourceEditor convenience only
 - something else.

I think the issue of getting a number of fields into columns and lined 
up well is just a specific case of alignment, and is going to be solved 
anyway, by either the ability to select multiple components (and then 
align and move them), or the ability to specify sizing / layout schemes, 
or both.

> Anticipate need for one label and
>several data entry fields on a single row like city-state-zip.
>  
>
But each of those would be a label : field on its own, wouldn't it ? 
What additional features would be needed in the "compound widget" to 
support this ?

>B. Geometry managements (aka sizers, resizing, etc.)
>We had a simple grid (default to 100x100) with "attachment properties" on
>each widget.  If both right and left edge of widget were attached, it would
>move and resize with window resize, etc.  To simplify the use of
>attachement, we had an attachment dialog that had 4 sets of identical
>"attaching controls" arranged at North, South, East, West.  Combined with
>multiple widget select, you could attache left and right sides of a bunch at
>once, then go back and individually set top,bottom.  It was not as elegant
>as most UI builders, but it was easy (the product was, after all, "ezX")
>  
>
I think it's a little bit too simple for Pythoncard; it can't adequately 
handle some very simple cases (e.g. the scrolling text dialog, with one 
growable size textarea and one fixed size button below it), and I think 
that could put a lot of people off.

>New Feature Request: Need to be able to specify containers either in same
>file or different file to control multiple widgets at once. Handy for a
>"mode change" where one set of controls vanishes and another appears.
>Valuable to define this stuff in a different file/window and then import
>(perhaps only at runtime, use space holder in resource editor) so gui is
>more modular.
>  
>
Hmmm - interesting viewpoint. I want them in the resource editor more 
than I want them at runtime. I'd like to use them for moving groups of 
components around, selecting the subset to align or distribute, etc.   
Some of that can be done with "at the time" selection of multiple 
components, but I'd really like to make some of those collections 
"permanent" (e.g. all the address components in a contacts database).

There is an experimental "container" component - but I think it was 
problematic (before my time :-)  Making it a "first-class" component I 
think introduces some difficulties - need to get it into the event 
hierarchy, etc.

I'd be content with a simple "list of other component names" which could 
be used to select a set of  components in one operation - both in 
resource editor, and at run-time to enable the vanishing you described.

Not sure what extra modularity you were looking for - I can't imagine a 
case where you wouldn't want to be able to see / modify these groupings 
in a layout editor.

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



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.10.3 - Release Date: 25/04/2005