World: r3wp

Graham - as far as my understanding goes, it actually can be released 
without the finished Core. Maybe few fixes to View kernel will be 
needed (especially if we want Unicoded display), but it can be imo 
released with recent Core.

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 prefer it here at home, yes. But it would be wonderful with an 
external Cheyenne server on a good connection.

Aaah, Cheyenne, I thought so. Not sure I would use it instead of 
Apache2, but you might talk me into it. Well, off-topic here ...

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

It defines set-words as local? Is it related to former Carl's blog?

... apparently so ...

Pekr, you keep asking these low-level questions I can answer during 
times that I am asleep. We have to deal with that :)

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.

Your characterisation of the current system is not quite accurate. 
A single draw block per style is the simple case that will do for 
most.

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.

Back to your comments...

OS-compatible behavior will be handled, don't worry. OS-compatible 
appearance will be done on the skin level though. These are not the 
same thing at all, so don't get them confused.

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.

You are wrong in thinking that the design is set in stone. Nonetheless, 
some parts of the design are not going to change because they are 
already the best choice. Other parts of the design will change in 
subtle or dramatic ways. Other parts haven't been done yet. That 
is why the design is not set in stone - it's not done yet.

Keep asking questions though! There's going to be stuff we haven't 
considered yet :)

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

Well, back then I was busy with DevBase :)

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?

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