r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

Henrik
28-Oct-2008
[7785]
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.
Pekr
28-Oct-2008
[7786]
so no 'attach keyword?
Henrik
28-Oct-2008
[7787]
not needed there
Pekr
28-Oct-2008
[7788]
Henrik - is there general 'list style, so that e.g. text-list is 
based upon that?
Henrik
28-Oct-2008
[7789]
I've not studied it yet, so I don't know how lists work.
Pekr
28-Oct-2008
[7790]
aha, never mind. I was just curious, if there is one, if it supports 
iterated faces, or not ...
Gabriele
28-Oct-2008
[7791]
string! internally is NOT utf-8 in R3.
Anton
28-Oct-2008
[7792]
Oops. Isn't it utf-16, at least when necessary ?
PeterWood
28-Oct-2008
[7793]
Thanks for that clarification Gabriele.Though iIt does rasie the 
question what is the format of string! in R3?
BrianH
28-Oct-2008
[7794x4]
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 :)
Pekr
28-Oct-2008
[7798]
BrianH: could you try to explain, what the thick-skin is? I don't 
understand it from its description....
BrianH
28-Oct-2008
[7799x3]
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.
Pekr
28-Oct-2008
[7802]
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?
BrianH
28-Oct-2008
[7803x2]
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.
Pekr
28-Oct-2008
[7805]
So thick skin allows complete change to layout, while the lower layers 
stay identical?
BrianH
28-Oct-2008
[7806]
Yup. Complex styles are laid out like panels. Their layout is just 
as easy to change.
PeterWood
29-Oct-2008
[7807]
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.
Henrik
29-Oct-2008
[7808]
If you want precise control of the content of string data, use binary. 
String! is no longer meant to be used for such tricks.
Pekr
29-Oct-2008
[7809]
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?
PeterWood
29-Oct-2008
[7810]
If by "precise control" you mean accessing a string! from C, how 
would you use binary! instead?
Gabriele
29-Oct-2008
[7811x2]
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.
PeterWood
29-Oct-2008
[7813x3]
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?
Henrik
29-Oct-2008
[7816]
Pekr, yes, VALUE comes from the face itself, just like in old VID.
Pekr
29-Oct-2008
[7817]
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 ...
Henrik
29-Oct-2008
[7818x2]
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 :-)
Pekr
29-Oct-2008
[7820]
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 :-)
Henrik
29-Oct-2008
[7821]
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.
Pekr
29-Oct-2008
[7822]
what is on 061.png? Just boxes? :-)
Henrik
29-Oct-2008
[7823]
just boxes
Pekr
29-Oct-2008
[7824x2]
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
BrianH
29-Oct-2008
[7826x4]
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.
Pekr
29-Oct-2008
[7830]
Henrik - you'r from Germany? :-)
Henrik
29-Oct-2008
[7831]
no :-)
Pekr
29-Oct-2008
[7832]
Then contact Carl to fix his blog :-)
Henrik
29-Oct-2008
[7833]
I did :-)
Pekr
29-Oct-2008
[7834]
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?