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

[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 ]