World: r3wp

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.

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

will only scroll the last text-list-box.

so no 'attach keyword?

not needed there

Henrik - is there general 'list style, so that e.g. text-list is 
based upon that?

I've not studied it yet, so I don't know how lists work.

aha, never mind. I was just curious, if there is one, if it supports 
iterated faces, or not ...

string! internally is NOT utf-8 in R3.

Oops. Isn't it utf-16, at least when necessary ?

Thanks for that clarification Gabriele.Though iIt does rasie the 
question what is the format of string! in R3?

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.

Pekr, being able to animate styles continues to have nothing to do 
with skinning :)

BrianH: could you try to explain, what the thick-skin is? I don't 
understand it from its description....

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.

In theory, medium skins could be non-app-specific, able to be applied 
to different R3 apps. Thick skins would likely be app specific, or 
at least specific to certain complex styles. At this point there 
aren't many complex styles because the design of the system tends 
to make styles simpler to implement than you would otherwise expect.

In what sense does thick-skin allow to change behaviour? Own reactors? 
The whole layout? The thing is, that I can't imagine practical case. 
Will thick skin be used to cover platform differences, e.g. scroller 
arrow positions, etc?

I think a medium skin will cover that well enough. Scrollers are 
currently implemented in a single face with draw commands.

You may be off in looking for practical reasons for thin skins - 
that is a reason why I chose Winamp as an example. Still, if you 
want a practical example, there is a Chinese version of OpenOffice.org 
that uses a vertical version of Office 2007's ribbon interface instead 
of OOo's menus. That is the kind of thing that would be possible 
with thick skins.

So thick skin allows complete change to layout, while the lower layers 
stay identical?

Yup. Complex styles are laid out like panels. Their layout is just 
as easy to change.

I disagree with "it doesn't matter what strings are internally". 
If Rebol3 is going to be extensible as promised, the internal representation 
of all dataypes matters.

If you want precise control of the content of string data, use binary. 
String! is no longer meant to be used for such tricks.

From file list example: "text-list files do [set-face ca read-string 
pick files value]" - where does the 'value come from? Is it internal 
facet of 'text-list style?

If by "precise control" you mean accessing a string! from C, how 
would you use binary! instead?

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.

Peter, if you're talking about plugins, then you *won't* have *direct* 
access to the internal datatype representation, but there is always 
an abstraction layer. in any case, that abstraction layer hasn't 
been finalized yet, so, at this point it doesn't matter what strings 
are internally.

Thanks for the information, Gabriel. Yes, I was taking about plug-ins. 
It will be interesting to learn of the details once things have been 
worked out.

Is the array to 16-bit unisgend values effectively UCS-2?

Sorry that should have been :

Is the array of 16-bit unsigned values effectively UCS-2?

Pekr, yes, VALUE comes from the face itself, just like in old VID.

Henrik - thanks for third video. Still uses lower frame rate? Scrolling 
still seems being rather slow. It will probably need some optimisations 
by Cyphre in low level ...

Pekr, it was meant to be 40 fps, but it ate almost 100% CPU. Rendering 
is usually about twice as fast.

h264 realtime encoding is CPU intensive :-)

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 :-)

I'm not sure if it's related. Carl has only just inserted this feature, 
so I don't know what optimizations are missing. I would guess it 
does very excessive ON-DRAW on each of the faces in the panel.

what is on 061.png? Just boxes? :-)

just boxes

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 
...

http://bbrv.blogspot.com/2008/10/everything-everywhere-ii.html

Pekr, subpanel was slow on Henrik's demo because of his debug settings.

Peter, the array of unsigned values would effectively be UCS-2 if 
it behaves the way Gabriele says. This would mean it would be faster, 
but use more memory for those with characters outside the BMP. It 
would also cause a problem on Windows because Windows >= 2000 is 
internally UTF-16, as are all of its Unicode APIs.

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.

Henrik - you'r from Germany? :-)

no :-)

Then contact Carl to fix his blog :-)

I did :-)