[REBOL] Re: percent! - new datatype request
From: joel:neely:fedex at: 18-Jun-2002 7:04
HI, Carl,
Carl Read wrote:
> Hi Joel,
>
> Seems a while since you wrote this now, but I've been a bit snowed
> under with stuff. Anyway...
>
I know the feeling!!!
> Well, consider these two, (no, make it three), hypothetical
> functions...
>
> add-tax: func [price [number!] tax [number!]][price * tax + price]
>
> add-tax: func [price [money!] tax [number!]][price * tax + price]
>
> add-tax: func [price [money!] tax [percent!]][price * tax + price]
>
...
> So to the third example with the percent datatype. This would also
> have the advantage of built-in error detection if a percent value
> wasn't surplied, plus there'd be no need for converting the percentage
> values supplied by users to 100th of their value before they were
> used...
>
I'd only add (PTP;-) that
add-tax: func [price [money!] tax [decimal!]] [tax + 1.0 * price]
would work just fine with my later suggestion regarding #"%" as a
numeric suffix, allowing
add-tax $14.95 8.5%
or
add-tax $238.15 5%
because (in that proposal) the "scale-radix-left-by-two" meaning of
the trailing #"%" would always yield a decimal! value. Thus we get
notational benefit (for those who think that's a benefit) and type
checking with this approach as well.
> 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, 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).
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.
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.
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. That's
not true for all computer users, obviously.
Anyway, I guess I'm dancing around the underlying questions:
- Why do windows need to be scalable?
- Do all windows need that feature?
- What problem are we really solving?
- Are we playing with symptoms, or is there a real "root-cause"
issue involved here?
> Execution speed is an issue with REBOL, but it isn't the usual
> reason you choose a high-level language, is it? Or more correctly,
> execution speed isn't, but developement speed probably is, as is
> ease of maintainance. All the better if the execution speed is
> good, but if a high-level language isn't easy to develope in,
> where's the advantage in chosing a high-level language over a
> lower-level one?
>
Good questions, all.
I tend to see language selection (regardless of "high" versus "low")
as a complicated balancing act in which one tries to find a happy
compromise among a large number of factors (in no particular order):
1) Ease of development
2) Ease of maintenance
3) Availability within the target environment/platform
4) Skillset of the professionals who will do (1) and (2)
5) Access to more professionals who already have skills with
the language/environment/platform
6) Interoperability with existing systems
7) Ability to re-use existing code/components
8) Run-time performance (both for current and projected loads)
9) Cost and availability of tools/training/learning
and (not because I've exhausted the issue, but just worn out my
fingers and your eyes... ;-)
10) The nature of the project (one-shot ad-hoc task, prototype,
proof-of-concept, research, 24x7 dark room production, etc.)
as it interacts with all of the above.
I certainly don't believe that run-time performance is the most
important issue in most cases (as long as it is adequate for the
task at hand!), but it is one of the easier factors to measure!
That means that, until REBOL can provide performance that is
roughly comparable to some other widely-used tools, it's going to
have a hard time elbowing its way into application areas where
those tools are already in use.
> > If I can imagine changing View to follow that principle, I would
> > favor something like the following. If you write
>
> > view/options layout [... some widget specs...] [resize]
>
> > then ALL enclosed widgets would scale proportionally when the
> > container resizes. I'd add widget-by-widget attributes of
>
> > scalex
>
> > to mean fixed-height, scaling-width,
>
> > scaley
>
> > to mean fixed-width, scaling-height, and
>
> > noscale
>
> > to mean just what it sounds like. Thus, for example, a vertical
> > scrollbar would have SCALEY as an attribute to allow it to resize
> > vertically but not change width, a horizontal scrollbar would
> > have SCALEX, a thumbnail icon could have NOSCALE, etc...
>
> Using my example above as a template for a test of this, we get...
>
> view layout/options [
> across
> text-list "aa" "bb" "cc" 100x300 scaley
> area 300x300
> ][resize]
>
> Which is quite nice, and some might say better than using percentages
> without automatic scaling of everything, (my prefered option), which
> would look like this...
>
> view layout/options [
> across
> text-list "aa" "bb" "cc" 100x100%
> area 100%x100%
> ][resize]
>
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! ;-)
> Why I don't like the idea of resize turning every pane into a scalable
> one is you have the likes of buttons and so on which in most cases
> you wouldn't want to scale. They could have their defaults set to
> noscale though, which would be consistant with the current VID way of
> doing things.
>
Which is exactly what I had in mind (although I used icons as the
example of a non-scaling widget rather than buttons). I can also
imagine having a button that e.g. spans the width of a display across
the bottom having a SCALEX attribute.
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
