At 03:38 PM 4/30/2002 +0100, Simon Willison wrote:
> At 12:44 30/04/02 +0100, Simon Willison wrote:
> >The simplest way of allowing a user to create a resizable component would 
> >seem to be to allow the user to specify the component's dimensions as a 
> >percentage rather than a fixed width in pixels (similar to how tables and 
> >divs can be sized in HTML). I don't know how feasible it is to combine 
> >fixed-relative-to-corner positioning with 
> >take-up-as-90%-of-available-space positioning but from a resourceEditor 
> >user perspective the two combined could create a very powerful but easy 
> >to use interface for creating resizable documents.
> 
> I've thought about this a bit more and percentages may not be the best way 
> to do this. In most situations I (as an end user) would rather just select 
> a component and instruct it to expand either vertically, horizontally or 
> both to fill any available space. Combine that with 
> positioning-relative-to-corners and simple applications (such as my 
> ScratchPad program) would have all of the basic sizer functionality needed 
> to handle resizing.

I'd expand the idea just a teeny bit and talk about relative to 
borders/edges rather than just corners. A layout with more than two 
components in the x or y direction would be pretty cumbersome to code and 
keep in synch with only corner anchors, methinks.

> Another thought: Rather than specify that a textarea should expand to fit 
> horizontally and take up as much horizontal space as possible for the sake 
> of aesthetics it would be preferable to be able to specify a "margin" on 
> the side that is being expanded. The definition of such a component might 
> look a little like this:
> 
> {'type':'TextArea',
>      'name':'ScratchPadText',
>      'position':(0, 30),
>      'relative': 'top-left',
>      'size':('*', '*'),
>      'font':{'faceName': 'Courier New', 'family': 'monospace', 'size': 8},
>      'rightMargin': 8
>      'bottomMargin': 8
>      },
> 
> The *s in the size tuple mean "expand horizontal" and "expand vertical". 
> The right margin and bottom margin are explicitly defined - this is the 
> space in pixels that should be left between that side of the component and 
> the border of the application (or the start of the next component anchored 
> on that side).
> 
> Final thought: It would be useful if GUI designers could specify a 
> "smallest possible" size, after which the application can not be resized 
> any smaller (a similar effect can be seen in the Samples Launcher which 
> can not be shrunk below a certain size). This will prevent problems with 
> users resizing the application to the point where the position rules 
> defined for the widgets (with respect to corners of the application) cause 
> them to overlap each other.

I think this is an important feature. In fact, ultimately it would be way 
cool if there were a background/window property that basicallly prohibited 
the user from shrinking the window to a size too small to show all the 
components. A bit dictatorial, I know, but perhaps justified.

> I'm currently reading up on wxPython with the intent of hacking around 
> with the PythonCard prototype a bit at some point, but ion the meantime 
> (if no one minds) I'll keep throwing ideas at this list and see if any of 
> them stick ;)

Nobody here is going to mind you throwing ideas at the list! That's one of 
the big reasons it and we are here.

> Regards,
> 
> Simon
> 
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pythoncard-users@[...].net
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users


_______________________________________________
Pythoncard-users mailing list
Pythoncard-users@[...].net
https://lists.sourceforge.net/lists/listinfo/pythoncard-users