World: r3wp

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?

or - will we have any chance to refer to context, module? Something 
like self/parent/a: value?

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

But according to the blog, it might seem that many users could in 
theory prefer using funct quite often. Wouldn't it be better then 
to have it as a native? (it can come later, of course)

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

The slow or complex parts of funct are already native. Remember, 
func isn't native either. Only make function! is.

Please keep asking questions. As long as you are patient the questions 
can act like a Plato-style dialectic discussion, providing valuable 
information for the rest of the community. If you don't ask, we won't 
know what people want to know.

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.

As for questions, I would prefer that you ask them now, as long as 
you can take "maybe", "don't know yet" or "hasn't been decided yet" 
as an answer on occasion. There are things that we need to know, 
but the overall design strategy is a good one so far.

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.

There is new Doc showing, how to "easily" view all styles - http://www.rebol.net/wiki/GUI_Example_-_View_all_styles

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

thanks.

Henrik - when I compare your panel skin designs so far (e.g. 40 vs 
48), dunno why, but I like of liked the panel look in image number 
40. It remings me like you mentioned those "natural materials". It 
almost looks like it is carved into the surface. Not sure it would 
work if multiple such panels would be on one page ....

I think it could work, but I have some problems figuring out the 
right draw block so that it works with alpha. The panel is still 
under heavy revision.

I think that heavy alpha TV like interfaces might need completly 
separate skin? I remember how Carl wanted his list style for 1.3 
project (the style was not released, it is in IOS world) to support 
borderless list styles. When you go alpha, it is similar - borders 
might not work  easily ...

Henrik - question towards your skinning experience. So far it seems, 
that when you choose gradient based backgrounds, the overall colors 
are darkish - round button, slider. Are you settiling for such a 
theme, or still just experimenting? The problem is, that when you 
make it brighter using gradients, it starts to look glossy (maybe 
not necessarily, dunno).

I'm experienting until the skin is done. Anything can change at any 
time if I find that a particular element is not working or if I get 
a better idea along the way.

I am doing some background experimentations with your screenshots 
in primitive Windows painter :-) With my color (mild themes of orange, 
or water, sky, gradiented, the UI works ....)

ok :-)

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.

What is thick-skin good for? I really can't firnd practical example 
usage for that. I would instead prefer behavioral changes, e.g. being 
able to animate style, without change to style low level ...

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.

Thanks, Anton. I should have included the second note :


2. Although the REBOL kernel does support Unicode, the graphics library 
does not yet handle unicode strings.

So does this mean that the graphics library is still treating a string 
as being 8-bit encoded?  No doubt according to the current Windows 
codepage?


does READ-STRING convert  utf-8 to whatever 8-bit encoding the graphics 
library is using?

BrianH: with new DocBase example, we can see view/across, which changes 
the layout direction. Is there also across/below keyword in VID directly, 
as in VID2?

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

shadwolf - how do you know it is or is not possible? :-) That is 
why I am asking about it :-)

http://www.rebol.net/wiki/GUI_Note_-_Shapes_in_DRAW_Blocks- I think 
that we should be aiming at graph based low level AGG based design, 
with the ability to cache various nodes. IIRC Cyphre was talking 
about something like that, but not sure it is implemented ... good 
that such low level things are explained though ...

pekr, no across or below available in the dialect itself (yet).

Henrik - thanks for the info, but anyway - eh, why to have it at 
'view level, which gives you the possibility to adjust the direction 
only once? Hmm, maybe it makes sense, because at panel level you 
can use panel, or group to "change" orientation, although those styles 
serve different purposes ...

Pekr, I'm not sure if it has been decided yet whether they go in 
or not. If Carl misses them enough, they might go in. GROUP does 
all what they do, though.

I also noticed change from 'acts to 'reactors :-)

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.