Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: percent! - new datatype request

From: carl:cybercraft at: 21-Jun-2002 15:02

Hi Joel, On 19-Jun-02, Joel Neely wrote:
>> I agree, but what is most urgent is a bit subjective and depends >> on the individual's point of view. Mine is that designing GUIs >> with VID is quite close to being good but is seriously let down >> by how difficult it is to make them scalable. > If I may ask, what do you really mean by "scalable"? Is the issue > to allow a user to arbitrarily change window size at any time for > whatever reason,
Yes, that. I should've said resizable, not scalable.
> or is it to allow a user to adjust the display to > fit the size of the monitor (e.g. closer to a "set it once and > forget it" scenario)? > If the latter, what about having a set of choices (based on the > common monitor sizes) from which the user can select? In that > case the UI designer can make sure that each is appropriately > laid out and all the positioning/scaling is "right" for each > but consistent in overall "feel" across all choices. The app > should remember the selection in a config file so that, once > set, it will present the same size every time (unless/until the > user explicitly overrides it).
No, that's much too much work for the programmer, and they'll invariably get it wrong for every second user, if they bother to attempt it at all. I think what RT mentioned in the beta docs about their "Virtual Coordinate Space" would be a better way than that. Another quote from it... ---8<--- Virtual coordinates are defined in the span facet of a window's top level face. To set the span, use the /span and /size refinements with layout to display a new face. The /span will indicate the virtual coordinate space while /size specifies the actual pixel size of the window. layout/span/size face 4096x3072 341x25 | | Virtual Coordinate Space | Window's Size (real pixel space) The top level face is inherited from the global face object. Using the /span and /size refinement with layout will set the span and size facets within the top level face as it is inherited. The /size refinement must be used with the /span refinement to set the actual pixel size of the window. If the real pixel space window size is not set in this way, undesirable results may occur. ---8<--- The full docs can be found in the Rebol Forces archives...
> A user behavior I've seen repeatedly is to size one or more app > windows to (nearly) the size of the available display, then use > window switching to move between apps. Some users like to keep > the resolution low to make the text large and easily readable > (or readable from further away) while others prefer to maximize > the resolution to get as much content on the screen as possible.
Ideally they should be able to choose the fonts they're using on an apps by apps and windows by windows basis, overiding their default REBOL skin.
> Providing pre-defined settings for common monitor sizes (e.g., > 800x600, 1024x768, 1200x1024 (?), 1600x1200), initially auto- > detecting the available real estate and picking the largest that > will fit, and allowing the user a simple way to try other sizes > (e.g., "small, medium, large, huge" or something else without > lots of scary numbers) might be an approach that could actually > simplify life for the users.
Just resize and snapshot a window seems the simpliest approach to me. (Of course, you're thinking scaling there, but anyway...) I've done something like this with some of my view scripts. ie... rebol [] win-size: 300x200 win-offset: 50x50 lo: layout [ across vh2 "Window Title" snap: button 20 "S" [ ; Clicking the button saves the window's size and offset. ] return stuff: area ] resize-response: does [ snap/offset/x: lo/size/x - 40 stuff/size: lo/size - 40x80 show lo ] resize-response view layout [ button "Test" [ view/new/offset/options lo win-offset [resize] lo/feel: make out/feel [ detect: func [face event][ if event/type = 'resize [resize-response] event ] ] ] ] That keeps the snapshot button in the top right of the window when you resize it. (The need for the window with the "Test" button is because you have to setup the event routine after the window has opened to capture a resize. So you have to use view/new for this to work - which doesn't work if it's the first window you open in View...)
> Of course, I'm assuming in the above that users are treating > their computers as tools to do some task, and the focus is on > the task, not on playing around with the computer itself.
Of course. (;
> Anyway, I guess I'm dancing around the underlying questions: > - Why do windows need to be scalable?
Because if not, your average programmer assumes everyone has a 1024x768 display or better...
> - Do all windows need that feature?
It should perhaps be the default, but probably a bit late to introduce it as the default now.
> - What problem are we really solving?
Different sized displays - from 320x200 (cell-phones and the like) upwards...
> - Are we playing with symptoms, or is there a real "root-cause" > issue involved here?
Root cause is different sized displays. But that's with scaling. Resizing's different... --- Why do windows need to be resizable? 1) Because sometimes the same window will have different amounts of content. Text in an area is an obvious example. It's nicer to avoid scrolling if you can, and enlarging the window can do that in some cases. 2) And because sometimes you like to shrink a window just to give you more deskspace to get at other stuff. If the contents don't resize with the window, shrinking the window can mean you can't see some of it. A shrunken text-box which you can still see and scroll through is better than one you can't see at all. --- Do all windows need that feature? Probably not. A... view layout [banner "Quit?" 210 across button "Yes" button "No"] is better without resizing I think. --- What problem are we really solving? Insufficient space to have all the information you want on screen at once. --- Are we playing with symptoms, or is there a real "root-cause" issue involved here? The root cause is room-wide screens cost too much. (; And they also can't fit in your pocket. [snip comments about percent datatypes]
> Although I now have to point out that you are assuming TWO new > types: a percent! type, and a percent-pair! type. Scope creep rears > its ugly head once again! ;-)
Actually, I was just thinking of a modified pair. Pair was added with pixel coordinates in mind I believe, hence it only accepts integers, not numbers. So adding percentage support shouldn't break any existing scripts. (He guessed wildly:) -- Carl Read