World: r3wp

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

why debug red lines can't be seen, if full gob size is utilised? 
Can't it be layered inserting new gob into gob/pane?

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.

Yes, but why not insert it at the tail then? Because, when not seen, 
it does not work for you, no? What about styles, which do utilise 
the whole gob size?

Read the first line in my response for your first question. :-)

Anyway - I was surprised by addition of debug modes. It will greatly 
improve situation over R2 VID.

... when you debug, you don't want to see your lines that are supposed 
to be there :-)

The second question: Some styles will occupy the entire gob size, 
yes. That's no problem. The red box is mainly there to display where 
the border is on the gob. Nothing else. I had great trouble aligning 
styles without it.

your site's down ....

Pekr, correct.

I see, perhaps it's one of the mysterious Cheyenne crashes.

BrianH: As I understand UCS-2 cannot be used to encode characters 
outside the BMP. It is a full subset of UTF-16. It should not cause 
problems with WIndows Unicode API except that it would not be able 
to display characters outside the BMP. (It would instead include 
 an non-displayable character for each 2-bytes returned by Windows.)