[REBOL] Re: percent! - new datatype request
From: joel:neely:fedex at: 13-Jun-2002 11:38
Hi, again, Carl,
With respect to the View issues...
Carl Read wrote:
> So, because you have no need for a percent datatype, noone has?
>
I never said that. What I *did* say is that I believe RT could
do some other things that would have a bigger effect on the
widespread adoption of REBOL.
So far the "datatype as clue to View layout" is the only issue I've
seen raised in this thread that wasn't simply a matter of a shorter
(and arguably more conventional) way to write floating-point values
that indicate ratios or factors.
> Fair enough. But others using other OSs and every IOS user
> (I assume) are using View. And they need to be able to create
> dynamic layouts with ease. A percentage datatype is the obvious
> way to do this.
>
I might agree that it is *A* way to do it, but I don't think it's
the only possibility by any stretch of the imagination.
> > 1) I spend a bit of time with graphics and color issues, so
> > my first thought on seeing the above was:
>
> Your lack of knowledge of VID shows there.
>
Now, with all due respect, I must insist that you missed *my* point.
If the burning need here is to have a distinct data type so that one
can stick an unlabeled value in a layout block and have View use it
for control of scaling, then I'd still wonder whether a decimal!
value could serve that purpose.
It is certainly arguable that a string attribute of a button widget
is most reasonably assumed to be the label displayed on the button.
However, the more attributes we add to a widget, the more we have
the possibility that multiple attributes can reasonably have values
of the same type. Instead of addressing this situation by insisting
on the creation of a new data type for every attribute (or for those
attributes deemed most common for some purposes) I question whether
the "datatype as only clue" approach itself scales well.
The punch line is that I have serious reservations about a notation
that leans heavily on datatypes (and large doses of assumption about
the most likely meaning or most frequent use) to specify complex
artifacts.
> Though it's possible a percent datatype could be used for colors and
> decimals for face sizes, but I supect RT would go for using a percent
> datatype for sizes. Either way, it'll be a useful addition.
>
I'm sure some of use would consider it useful (for some definitions of
use
at least ;-). I'm just suggesting that "useful" and "most urgent
to deal with right now" are distinct concepts.
> Well, I answered your problem regarding adding words to a list to
> my satisfaction, (though perhaps not to yours), so perhaps you'd
> like to show me an easy way to modify this little View layout...
>
> view/options layout [text-list][resize]
>
> so that when you resize the window the text-list resizes with it?
> My prefered way to do it would be this...
>
> view/options layout [text-list 100%x100%][resize]
>
I'll be glad to respond, with a few disclaimers:
1) I make no pretense at View expertise, so it'll be easy for someone
to pick at details or inconsistencies with other View notation. I
trust that's not the purpose of your question, however.
2) I've fiddled quite a bit over the years with a variety of toolkits
for building GUIs, and have some fairly strong impressions about
what was (or was not) well done in various languages.
I believe that building a usable GUI for a non-trivial application
is a very demanding task, already difficult enough if one assumes
fixed-sized windows. If we throw resizing into the mix, then
specifying what is and isn't to flex can become *highly* complex
IMHO. Look at all of the complexity surrounding "layout managers"
in Java (and how often programmers give up on the fancier options
in favor of simplicity) as an indication of how nasty it can get.
3) I haven't thought long and hard about how I think a GUI
specification
notation should look or function, so you're getting off-the-cuff
responses here.
With that said, let me add my preference for a design strategy of
"Make simple things simple, and complicated things possible"
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...
For any more complex scanarios, I'd put the monkey back on the
programmer
with something vaguely like
view/options layout [... some widget specs ...] [resizeby function]
where the offered function (by name or anonymous) would be invoked to
handle the resizing, and would be able to use some simple interface to
adjust the size of each component widget within the layout, so that a
programmer wanting a more sophisticated layout-management strategy
would have a way to implement it.
Again, let me repeat that I'm not trying to play "duelling examples"
here, but to ask the question "What could be done to make REBOL more
attractive to users and developers who currently are not aware or
interested?" I trust we all would like to see that result!
-jn-
