AltME groups: search

Currently, PANEL produces a background along with a border. That's 
why there are a lot of rounded borders in the first screenshots. 
Due to a bug (?) in the layout engine, PANEL must have a draw block 
assigned that fills out the background with a neutral color.

GROUP behaves as follows:

- No background

- When not specifying elements in a group block, they layout vertically.

- When specifying elements in a group block, they layout horizontally.

- When specifying a number for the group block, each element lays 
out horizontally until the number is reached and then a new row is 
started.

Differences from VID3:


- There is no concept of rows and columns. Elements of uneven sizes 
will uncritically be laid out right next to eachother. I've not yet 
discussed with Carl whether this goes in or if there is a different 
solution. I've observed code for grid management in both GROUP and 
PANEL and a facet reading "grid: true", but it seems not to be working.

A couple of articles I found interesting about the future of interpreted 
programming languages. 

http://weblog.infoworld.com/fatalexception/archives/2008/10/virtual_machine.html

http://weblog.infoworld.com/archives/emailPrint.jsp?R=printThis&A=/article/08/10/13/42TC-dynamic-futures_1.html

VM, JIT and access to other programming languages libraries is the 
future...
Maybe Rebol 4 ?

There is no concept of rows and columns.
 <--- this was a bug and has been fixed.

Petr, most of the styles in VID3 use just one draw block. Also when 
using multiple gobs, eg. in a scroller, they have one draw block 
each too, and state is just changing the value of some words. Carl's 
version just limits this to a single draw block, without automatic 
resizing. Which, you're forced to do if you remove the distinction 
between feel and look (you're stuck with whatever gob structure was 
in the original style anyway without that distinction).

New VID related blog posted - http://www.rebol.net/r3blogs/0152.html
- GUI: Thin skins, thick skins, and in-between

It kind of made point, when Carl posted once in two months. But now 
it is almost daily, so maybe I will stop it, to not flood here. Surprised 
a bit by low number of reactions. I thought ppl will be more interested 
in new GUI and how it starts to turn out ....

I hope the subject of the example, a colour picker, isn't an indication 
that the new Rebol GUI isn't going to native dialogs. Windows, Gnome, 
KDE and Mac OS X all have native colour pickers don't they?

I would welcome more real-life scenarios, which are not yet implemented. 
Accelerator keys and focusing. We need to be able to follow OS compatible 
behavior.

petr, from what i see, on [enter] means that the action is executed 
when the window is shown (you "enter" the window), and it is also 
executed when the sliders change (do 'set-clr), so it's reused.

i don't like at all the lab50 thing. that will NOT allow localization, 
just to make an example. i consider having to size things explicitly 
a HUGE mistake and i will never say it loud enough.

Gabriele - such opinions are strongly needed. Please go and put them 
into blog comments section ...

Pekr, yes... but the point is that it's default and I set up new 
AltMEs all the time. I hate it.

Status:


- Asset management is a big question. There are design questions 
to solve with regards to loading and unloading assets to make it 
easy to switch skins. Carl has mentioned the three skinning layers 
in his blog post.

- I proposed a method to specify lists of materials in a very simple 
way like FONTIZE and Carl liked it, but it's not yet implemented. 
This is inspired by what 3D modeler software does to manage materials, 
rather than what other GUI engines do. It's much more formal.

- I proposed a method to generate materials for gradients in styles 
in a very simple way. Carl liked it. This is halfway implemented.

- There's a function to generate a gradient from a description in 
a compact way and then apply a function to it to create a real adjustable 
specular highlight. This means you don't have to work with a big 
set of tuples in a block to create a good gradient. You can see that 
in action here: http://rebol.hmkdesign.dk/files/r3/gui/026.png

- Carl is working on panels and groups. We're building small apps 
to try to reveal bugs in the layout engine.

- Panels has a bug that cause cells to overlap when resizing. This 
is not evident in my screenshots though. 

- Resizing with refresh bug has not yet been fixed and you may see 
it sneaking in, in some of my screenshots.

- Text handling (cursor movement, selecting, etc.) is still pretty 
basic. I think it's due to the event system being grabbed directly 
from VID3, as it behaves the same way. There needs to be a person 
capable of writing this code, as it can be done as an isolated project. 
Gabriele is a prime suspect here, but he's probably too busy at the 
moment. If not possible to do now, then it will have to wait a bit.

- Carl talks about getting more people working with VID3.4 this month 
to get them to write real apps to reveal bugs in the layout engine. 
Needs lots of testing.

- Text fields allow text to be painted right out to the edge of the 
area-size, which looks a little silly. Carl wants Cyphre to look 
at DRAW clipping.
- Accelerator keys - no work done yet.
- Disabled or focused items - no work done yet.

- I have skinned button, toggle, slider, text, area and progress. 
I hope to skin scroller and panel today.
- Constantly working towards simplifying styles.

oh no, I hope we did not go with read-string and all possilbe read-my-file-format 
instead of clean read/as and decoders aproach?

Henrik - I know it might be easy. Carl does not see it as a problem, 
many of you probably too. But using myriad of read-* is imo anti-rebelious 
and suggests that not enough emphasis was put into design. I hate 
how rebservices are polluting name space, cloning all possible send, 
do, wait, open, etc. functions ... but everybody of us has his/her 
own preferences .... I really don't want to end with 100 of read-* 
functions ...

It seems you settled for the final button look? Looks decent, at 
lest grey variant works. As for toggle, not sure color distinction 
is enough (colour blind ppl), and we should not add kind of 3D effect? 
(Button pressed, like in VID2?)

Henrik - I reread you list of things which are being worked on. Just 
wanted to ask, if so called "skinning" is not overrated? I still 
can see mainly aplication development aproach with VID 3.4 so far. 
Because - when you think more about browser aproach - what is there 
to skin? Each page usually might mean totally different graphics. 
Buttons, fields, etc. -  the forms, are just little subset of what 
is usually a "website". So - the button will always be the button, 
field will always be just the field. What users might be more interested 
in, is animations, transitions, and that can't be covered by just 
changing the skin. Dunno - tried WindowBlinds (http://www.stardock.com
) once in the past, and imo skinning is overrated - still the same 
thing expressed many times, while web = different aproach each time 
....

Skinning is the only way we'll get apps that look and act like the 
platform they are running on. It is how every major cross-platform 
application manages to look and feel fairly normal.

Every major platform uses parametric UI layout and coloring. Even 
it we want to use the system metrics we need to have a way to apply 
them. That means that we require a skinning-capable design just to 
be able to fit in. Plus, if we do it right it's good marketing.

By the way, animations and transitions are a separate issue from 
skinning, and can be implemented independently.

Brian - we were never supposed to get exact OS look. The target was 
its own, decent cross platform look. If someone wants his app to 
look like native one, well then, but it is death for REBOL. And skinning 
is imo not going to solve the "act" part of the it?

There are a lot of features that have to work together to make skinning 
work, and those features are also useful for other reasons, especially 
when they work together well. Skinning is just a bonus ability. Personally, 
I want the ability to skin my apps, especially given my preference 
for dark interfaces - Henrik's stuff is great, but a little too grey 
for my tastes.

However, I am aware that my taste in interfaces is not shared by 
the community in general, and I would not it on others.

Henrik told us in the past (VID3), that his skin looks grey, as he 
starts with 4 basic colors to prove the concept that "it works" and 
that later it can be done more colorful. I am against the grey interface 
overall. It is an old desing. Nowadays look at iphone, flash, Fedora, 
Vista - blue, black, colorfull is the trend :-)

it seems that Carl is trying to build really strong foundation to 
make development, debugging/testing and using the gui an easy enough 
task ...

Most major UI frameworks have theming support nowadays, mostly to 
support system theming - it's a checklist item when comparing frameworks. 
Not as much of a deal killer as a lack of Unicode support, but still 
what people expect. A clean, unified cross-platform look is a necessity 
to include, but making it the only look would reduce the uptake of 
REBOL. Many business apps need a platform integrated look, and many 
other apps want to establish their own identity (look at WinAmp, 
Chrome or the Apple apps).

Henrik has said in the past that his basic design aesthetic is to 
start with shades of grey and then add color as needed. This tends 
to make elegant, business-like interfaces. My aesthetic is more shades 
of black and white with color accents, avoiding blue as much as I 
can in user interface elements - more of a night person look. To 
each their own.

My hope is that we can have generic themes that can be used by many 
apps, and made by a theme editor with minimal code. I would love 
to see R3 themes on the many theming sites out there already - good 
advertising :)

My opinion on skinning in general: I think skinning is something 
that has been gravely abused over the years. The last time I enjoyed 
skinning was with MUI on the Amiga because MUI was made for skinning. 
It was simple to get a good looking user interface without compromising 
usability or functionality. Nowadays we try to skin OSX and Windows 
in ways they were never meant to, and you feel it when using it. 
There are slowdowns or functionality is sacrificed. When you flip 
through a skin catalog, 99,9% of them are terrible junk and it's 
difficult to come up with your own.

I plan on trying a very different skin after this one.

BrianH: "I've been working at the infrastructure level ..." - are 
you saying you are now part of the implementation team? So you and 
Carl are doing VID3.4 development now?

Henrik - with your experience of OS level skinning - we should be 
sure, that our system is done the right way then. What I am not sure 
about is, if ppl are interested in skinning at all. Sometimes we 
can see only thin-skins (as per Carl's blog terms), but those are 
boring, mainly some color and rounding changes. What we should aim 
for is the ability to medium to thick skins, to simply mimick various 
needs (e.g. producing iPhone like animated UI for the mobile market, 
while business decent one, for corporate ...)

Yes I am. So far I've been doing code auditing and cleanup while 
I get a feel for the overall system. The design is really cool, though 
some parts are still under construction. Not modularized yet, nor 
should it be until it is more finalized. Most of the core design 
is pretty stable.

Pekr, I don't know what it will look like, when handling thick-skins. 
I would personally like to see some that are downloadable from RT 
(official skins) and then provide simple tools for letting you create 
skins to inspire people to create their own. This will be important 
for pages, where people want to get their own look.

A new DevBase is still intended to be a testbed for REBOL technologies, 
including the new GUI and LNS.

I can't go into the core changes right now because some of them aren't 
finalized (and it's 4am here), but here's a teaser: SELECT on object! 
acts like GET IN, but much faster. If the argument word is not a 
field in the object, #[none] is returned - no errors, no undefined!, 
just like with map! values.

So far, we are solving panel (page) style elements. What I miss is 
one layer above it, namel split-window. Hopefully it will not be 
problem. When I look e.g. at Outlook, the UI is - one window, background, 
and panels. When you move over the space between the panels, mouse 
pointer changes to that of resize. I wonder how would we do it?

Graham, I'd be happy with a DevBase that isn't a usability nightmare 
and implements a collaboration model that makes sense.

chicken and egg

The current design of DevBase has been useful to show us what works 
and what doesn't. The new DevBase will be valuable to the community 
beyond its specific use, but I intend for it to be worth making on 
its own merit.

If we are concentrating on VID, perhaps we need to locate the most 
common widgets and see if there any dificulties in creating them 
... like Pekr's split windows

If we don't want to start with own windowing system (which might 
be important for browser plug-in where using pop-up windows could 
get problematic because of blockers), then we should start with some 
kind of split window, and look for inspiration to various nowadays 
apps. Once you divide your app window into such sections (it imo 
still can be done with adapted panel style), you can then place icon-bar/menu 
at the top, icon-list or tree on the left, and the form on the right 
side. What some REBOLlers I talk to are also expecting, are styles 
like tree-view, tabs, grid, out of the box ...

How realistic is it to want to be able to drag and drop widgets?

and have the ability to drag items from one widget to another?

Graham - we are kind of object oriented. And why should it be a problem? 
You can go and locate effect-lab2.r script in R3-alpha world. This 
clearly shows, that drag and drop is not the problem, and that items 
even react to such stuff, including mouse pointer change. Simply 
put, all you need is to get low level event which tells you the drag 
is happening, and then you provide on-drag, on-drag-over event handler, 
where you can ''cause-event (in Gab's version) and style can react 
to it ....

and the type of widget being dropped is known to the event?

we have to support multidrop though ... imagine selecting several 
images and dragging them at once ...

Henrik, BrianH: could you please ask Carl to add one rather simple 
style, called Icon? It should consist of Image, text description, 
and it should be selectable (blue translucent color upon selection). 
I would like to see, how such selection is being drawn, if not part 
of draw block. If you want small but real-life app to test, please 
port effect-lab2.r to VID 3.4. We can then compare. Gab's version 
handles dragging and mouse-pointer change too.

Graham, drag support is already in the new GUI. All that would be 
needed for full drag-and-drop is some idea of what dropping is supposed 
to mean, which varies depending on the situation.

Pekr, R3 will use real modules. The initial public development releases 
of the GUI will not. The module system (and even spec) are not finished. 
We will be able to resume work on the module system soon, and the 
design of the new GUI's code is being done with a module system in 
mind. It's helping to do the GUI first because it serves as a use 
case and inspiration for low-level semantic fixes like a module system.

simply put, button and even panel rounding, even if rather small, 
does not look good, when you place stuff one to each other. E.g. 
with buttons tied close together. While I like button as is, I don't 
like rounded panel at all. Once again it is my preference. IIRC RebGUI 
has it as a preference and all styles adjust. First thing I do is, 
that I go for strict boxy desing, no rounding ....

and then you have the events for each button ....

This is the DRAW code for BUTTON:

draw: [
		; shadow
		pen false
		fill-pen shadow-fill
		box 0x1 (area-size + 0x2) 3

		; edge
		fill-pen edge-color
		box 0x1 (area-size + 0x1) 3

		; background
		grad-pen linear 0x1 1 (area-size/y - 1) 90 1 1 area-fill
		box 1x2 (area-size - 1x0) 2
	]

And that's about as bad as it's allowed to get.

it complicates the draw block

. There would be no complication, if frames would be used! You would 
use different draw block. I'll tell you, where will it lead with 
more complicated styles or states and their combination (animation 
of style, up, down, over, disabled, focused, selected, on-drag-over 
- and that is just button - it imo can't be covered by one draw block) 
- ppl start to patch the system. You will have no other chance, than 
to introduce kind of frames in no system way, e.g. providing something 
like face/state/frames: [], where you will store alternate draw blocks, 
and you will switch them on various events.

Why? As far as I can see, the main problem is following simplification 
= 1 style = 1 gob = 1 draw block. And then somewhere under the hood, 
the text gob is applied over it? (that is the section which is not 
apparent from docs so far, how text is being handled). What is the 
point to have gobs at low level, and their ability to be chained 
(contain another gobs), if not used? Some things would not need to 
be repeated (and hence style bloated with x-times the draw block 
for each state), but gobs could be layered ....

Using multiple gobs for a thing like Graham suggests would make the 
style even more complex and we're back to VID3. Not having to manage 
gobs at all is quite a relief.

Henrik - I understand very well, why Carl tries to keep the design 
simple. And so far, VID 3.4 looks good, that is apparent. But - when 
something is imo oversimplified and we start to hear - "you can't 
do it easily, or the system would be complex", then we should ask 
ourselves - will user call for such features, or not? Because if 
users will require such features, they will start patching the system, 
which is not prepared to be patched, and it can lead to kludgy solutions 
...

For focusing and such effects, it makes more sense to separate that 
out into a small gob system layered on top of the GUI. Similarly 
for drag'n'drop, bubble help, etc. It's not hard to do.

Graham - the truth is, it is set in stone already. The desing follows 
the logic of one draw block per style, plus minus parametrisation 
via facets and selection of gradients to express materials or something 
like that. That is why my opinion is, that we should not do the mistake, 
of first trying more complex styles, but - we should aim to introduce 
all possible subsystems, as focusing, disabling, accelerator keys, 
keyboard navigation. Those things are not vertical, but horizontal, 
and they can show, that you have difficulcy to express it ... hence 
Henrik's proposal, that such "additional" stuff (which is additional 
only because the design does not count them in), can be layered by 
different aproach ...

we should aim to introduce all possible subsystems

 ... I think we should aim to have something, anything, out ASAP with 
 as few subsystems as required to get a workable result that satisfies 
 80% of folks. The other 20% can wait another 10 years for "all possible 
 subsystems" to be designed and implemented.

Ashley - I am not the one who agrees to everything designed by Guru. 
If you are like that, well then. But - we were promissed, that this 
time, the system is going to be done the right way. I really don't 
understand your position, as you surely do understand, what we are 
talking about here. It is not about rounded buttons and such details! 
"all possible arguments" is just one single thing - OS compatible 
behaviour. And if you suggest we should wait 10 years here - well, 
time to move away from VID then ...

We can later try to influence Carl, to decide what is going to be 
done next. If you notice rebol.com R3 section, according to plan, 
next is the LNS overhaul. Dunno how long would it take. And then 
my suspicion is, that in order to release host sources, guys will 
try to do DevBase client in VID3.4 :-) So who knows when do we get 
back to Core ...

antenna problem partially fixed. it was full of water, shorting the 
wire and the tube, but it's only temporary and only a part of the 
problem. site should work again.

ah, water - that is bad. We have something like 550 customers. And 
trees are already bad itself. We have antennas properly fixed, watertight 
connectors. Water is the killer of the signal ... are you on 2.4 
or 5GHz at home? You can as well install stronger antenna, but watch 
out regulatory authorities :-)

I'm on 2.4 Ghz, plain 802.11b. The problem is that there is supposed 
to be a plastic lid sealing the end of the antenna tube (it's a homemade 
"cantenna"), but they tend to break and fall off due to weather exposure. 
The bottom of the cantenna has a hole to let the water seep out, 
but it's apparently closed up. And yeah, trees are a real killer. 
I'm going to have to find some stronger material for the lid, and 
isolate the antenna wire better from the tube.

I will build new server, I might provide some reboller access there 
(rebol.cz ). Our whole backbone is on 5GHz and the main connection 
is professional Ceragon (26GHz) radio. But I understand you want 
to have your server at home :-) I have mine too, so far ...

I thought you might be curious to see how FUNCT works. It's very 
useful:

>> source funct
funct: make function! [[
    {Defines a user function assuming all set-words are locals.}

    spec [block!] {Help string (opt) followed by arg words (and opt type 
    and string)}
    body [block!] "The body block of the function"
    /local ctx
][
    spec: copy/deep spec
    body: copy/deep body
    ctx: make object! 4
    bind/set body ctx
    unless find spec /local [append spec /local]
    append spec words-of ctx
    make function! reduce [spec body]
]]

Pekr: "There would be no complication, if frames would be used"

Using frames, especially the way you describe, would be a big complication. 
Nonetheless, that kind of thing is supported in the current system. 
However, it is not the simplest way to accomplish the task and for 
most purposes would not be the best approach.

Henrik hasn't been working at the low-level, Carl and I have - division 
of labor :)

We are working on core as well, implementing system enhancements 
and fixes suggested by problems that arise.

For instance, that funct function above doesn't work as-is without 
changes to make function!, and the underlying "search for set-words" 
ability may be extracted from the internals of bind/set for general 
use. Once that is done I know how to back-port the whole lot to R2.

We are not working with a single-complex-gob system only, we also 
allow compound gobs, rich-text-only gobs, image gobs, whichever is 
the best for the situation. We even have modes and custom draw handlers 
for more complicated situations. The new GUI's approach is both simpler 
and more flexible than the frames system you describe, even flexible 
enough that you can implement that frames system in your style if 
you like.

It will be better to not ask anything. Already with Gab's VID, I 
was the only one asking many questions, so it looked like I am constantly 
wanting to know many things. In fact, I found it pretty depressing 
that from the vital community, only two persons (me and Henrik) were 
trying to look at VID3 and trying to understand its workings ...

After VID2 and what it is, I am scared of not asking though, and 
later to hear - ah, you would need such a feature? Well, it can't 
be addeed ...". You can as well write your own VID :-)

One question towards 'funct. What if I have global word, e.g. 'a, 
and then I would need to set 'a also in the fuction body? Am I supposed 
to use "normal" function, instead of 'funct?

Most of the funct functions set global stuff through paths or accessor 
functions. All set-words refer to local words. If you need something 
else you can still use func (and many functions do).

It's basically a convenience function, though used widely in and 
by the new GUI code.

We also can choose different aproach - wait for first official alpha 
release. My questions are just guesses based upon study of Gab's 
VID and upon docs posted to DocBase.

The funct function (or whatever the name turns out to be) will be 
built-in to R3 and likely back-ported to R2, don't worry.

I may not have studied Gabriele's system as much as you have, but 
I have studied many other GUI systems and implemented some as well. 
There are a lot of differences between the systems in implementation 
details, but to a great extent they accomplish many of the same things. 
I know enough about Gabriele's and Carl's GUIs to be able to tell 
you that the overall design strategy is different, but the capabilities 
are comparable.

Good to know that all the bases are being covered and not in concrete. 
 Thanks Brian.

BrianH: could you please elaborate a bit on following?


- what is make-panel function good for? To predefine statical layout, 
without viewing it?  General question then is, if we don't miss 'layout 
function with R3 VID. Is there more functions like that, e.g. make-face 
as with R2?


- could you please explain a bit 'plane style? I thought that 'panel 
style itself spans available window space, and if the content is 
larger, scrollers are used automatically (kind of area with auto-scrollers 
:-) And if we need to distinguis resize or don't resize states, wouldn't 
it be enough to use something like "panel all-pan options [resize?: 
no]"?

Thanks a lot ....

>> source make-panel
make-panel: make function! [[
    {Create a panel from layout dialect block and options block.}
    style [word! none!]
    content [block! none!] "Contents of the panel"

    options [object! block! map! none!] "Options of the panel" /local 
    options face
][
    if content [
        unless options [options: copy []]
        extend options 'content content
    ]
    face: make-face style options
    init-panel face
    bind-faces face
    do-style-all face 'on-init none
    do-triggers face 'load
    face
]]

Pekr, some answers.

- The make-panel function is currently used internally by most of 
the group-like styles during their creation.

- A panel will resize its contents when it is resized, a plane will 
maintain a fixed internal size and provide a scrollable surface with 
scrollbars if its external size gets smaller than its internal size.

- No, it is not easier to distinguish resizable states that way. 
For one thing, that requires more typing. For another, a plane is 
a compound style with extra internal faces for the scrollbars, while 
a panel is not. Simpler styles are faster and easier to debug. They 
already share most of their internal code, so it is no big deal to 
add another style.

I'm confused by these statements in Docbase:


 "1. The READ-STRING function is a temporary function used to read 
 files and convert them from binary (and possibly in Unicode format) 
 into a string datatype."

I thought that the string datatype was now UTF-8 encoded.

Peter, binary mode is the default for READ.

READ-STRING looks at the binary and tries to interpret it, checking 
for unicode format (and maybe other formats), before converting to 
rebol string, which internally is UTF-8.

puting widget organisation into the view command ???  and if a want 
to mix below things and accross other things in the same pane I'm 
fucked ?

i put an example of that kind of mixed below and accross organisation 
of widgets in same pane and notice a bug

SCROLLER now has a tiny bit of intelligence: It will scroll the first 
face that responds to ON-SCROLL if one precedes it earlier in the 
layout code.

So:

view [text-list-box [1 2 3 4 5 6 7 8] scroller]


will automatically attach scroller to the text-list-box and scroll 
it.

As far as your code is concerned, a string! will be a series of Unicode 
codepoints. Internally, who cares? The implementation of string! 
is likely to be the same as the native implementation on the platform 
is running on, or whatever is more efficient. I think that string! 
is now UTF-16 on Windows, and the symbols behind word! values are 
internally UTF-8.


Still, it doesn't matter what strings are internally because AS-STRING 
and AS-BINARY are gone. All string-to-binary conversions will need 
encoding. REBOL scripts are going to be UTF-8 encoded though, as 
I recall.

It turns out that one of my earlier answers was not quite accurate. 
Though the implementation of plane and panel are different, it turns 
out that plane is actually less complex than panel rather than the 
other way around. The plane style doesn't need to be complex because 
scrollers magically find the faces they scroll.

READ-STRING is a temporary function because it is intended to replace 
it with a full encoding and decoding infrastructure supporting multiple 
formats and encodings. Until then, we have READ-STRING and WRITE-STRING.

A thick-skin is changing the entire layout and interactive behavior 
of an app. Think Winamp 5+

Medium skins will be the most common, and it is currently intended 
for a medium skin to come bundled with more than one thin skin. This 
may change though. It is intended for a medium skin to be able to 
be designed by a non-programmer graphic designer.

string! internals are not OS dependent afaik, and technically it's 
not UTF-16 either. currently, R3 switches automatically between an 
array of 8-bit unsigned values, and an array of 16-bit unsigned values. 
i assume a 32-bit mode will be added in the future as not all codepoints 
will fit 16 bits, though those that don't are very rare.

I was referring to subpanel, seems slow anyway. When you run R3 alpha 
script called button-colors.r, it is painfully slow. I asked Cyphre, 
and he told me it would need some optimisations. Those things really 
should be realtime, or we will not be able to write Office 2007 clone 
in R3 :-)

For the fans of REBOL - bbrv posted new blog. You can see there an 
advert, containing ED set-top-box. It was done during Viscorp times 
in 1996, when Viscorp was about to take over Amiga from Escom. OS 
was done by Carl Sassenrath, Jim Goodnow, and Carl even talked RJ 
Mical to join the group. The project was fiasco, but look at the 
screenshot. ED set-top-box UI was done in ABL\E, predecessor of REBOL 
...

You could store UTF-16 in an array of unsigned 16-bit values as long 
as your length, insertion and deletion routines are UTF-16 aware.

INDEX? and LENGTH? would be O(n) though.

It's not supposed to be seen, because otherwise I wouldn't be able 
to see the lines that are supposed to occupy those pixels by the 
style itself. The debug function is activated like this:

view [button "hello" debug]


and the red box appears in the face, not around it. The red box stretches 
to the very edge of the gob, so you can see where you draw.


The box is generated in the same draw block, by simply inserting 
a red box in the beginning, if the debug flag is enabled.

Having this box, helped us solved numerous layout bugs.

Henrik - is the gradient type/structure the same for the above mentioned 
calculator buttons and for the normal buttons in another screenshots? 
That calculator one looks good. But maybe it is because of white 
text color ....