[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...
http://www.rebolforces.com/archive/view099users.html
> 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