From: Simon W. <si...@in...> - 2002-04-30 14:39:07
|
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. 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'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 ;) Regards, Simon |