World: r3wp

This is the DRAW code for BUTTON:

draw: [
		; shadow
		pen false
		fill-pen shadow-fill
		box 0x1 (area-size + 0x2) 3

		; edge
		fill-pen edge-color
		box 0x1 (area-size + 0x1) 3

		; background
		grad-pen linear 0x1 1 (area-size/y - 1) 90 1 1 area-fill
		box 1x2 (area-size - 1x0) 2
	]

And that's about as bad as it's allowed to get.

draw: ?

it complicates the draw block

. There would be no complication, if frames would be used! You would 
use different draw block. I'll tell you, where will it lead with 
more complicated styles or states and their combination (animation 
of style, up, down, over, disabled, focused, selected, on-drag-over 
- and that is just button - it imo can't be covered by one draw block) 
- ppl start to patch the system. You will have no other chance, than 
to introduce kind of frames in no system way, e.g. providing something 
like face/state/frames: [], where you will store alternate draw blocks, 
and you will switch them on various events.

Pekr, frames for such a thing would make the style 3-4 times larger.

Why? As far as I can see, the main problem is following simplification 
= 1 style = 1 gob = 1 draw block. And then somewhere under the hood, 
the text gob is applied over it? (that is the section which is not 
apparent from docs so far, how text is being handled). What is the 
point to have gobs at low level, and their ability to be chained 
(contain another gobs), if not used? Some things would not need to 
be repeated (and hence style bloated with x-times the draw block 
for each state), but gobs could be layered ....

Using multiple gobs for a thing like Graham suggests would make the 
style even more complex and we're back to VID3. Not having to manage 
gobs at all is quite a relief.

Henrik - I understand very well, why Carl tries to keep the design 
simple. And so far, VID 3.4 looks good, that is apparent. But - when 
something is imo oversimplified and we start to hear - "you can't 
do it easily, or the system would be complex", then we should ask 
ourselves - will user call for such features, or not? Because if 
users will require such features, they will start patching the system, 
which is not prepared to be patched, and it can lead to kludgy solutions 
...

We turned the system from low level clean gob design to single-gob-SVG 
renderer ...

OK, I'll wait for addition of focusin/selection system, as it might 
prove, that single draw block might not be sufficient, because it 
can't handle conditional drawing - to draw something, or not. E.g. 
I would like to have some glow like outline blurred effect for focused 
face. How do I do it with one single draw block?

Pekr, it doesn't matter how you put it together, but adding gob handling 
for each style will make this system more complex. Besides, I'm still 
not yet working on compound styles. I'm learning as I go. I know 
perhaps 30-40% of the system right now.

Nothing is set in concrete yet, right?

For focusing and such effects, it makes more sense to separate that 
out into a small gob system layered on top of the GUI. Similarly 
for drag'n'drop, bubble help, etc. It's not hard to do.

Graham, for anything that involves floating gobs, no. I think Carl 
has thought it up, just not coded it yet.

Henrik: sounds interesting. While I would rather probably have styles 
living in their autonomy = reacting to various events themselves 
(as is correct aproach in OOP system), I do remember how I did 'disabled/'enabled 
style - inserting face (gob) in front of style, so it was independent. 
So you are right, it can be done different way, but e.g. animation 
of the style will not be possible ...

Graham - the truth is, it is set in stone already. The desing follows 
the logic of one draw block per style, plus minus parametrisation 
via facets and selection of gradients to express materials or something 
like that. That is why my opinion is, that we should not do the mistake, 
of first trying more complex styles, but - we should aim to introduce 
all possible subsystems, as focusing, disabling, accelerator keys, 
keyboard navigation. Those things are not vertical, but horizontal, 
and they can show, that you have difficulcy to express it ... hence 
Henrik's proposal, that such "additional" stuff (which is additional 
only because the design does not count them in), can be layered by 
different aproach ...

we should aim to introduce all possible subsystems

 ... I think we should aim to have something, anything, out ASAP with 
 as few subsystems as required to get a workable result that satisfies 
 80% of folks. The other 20% can wait another 10 years for "all possible 
 subsystems" to be designed and implemented.

Ashley - I am not the one who agrees to everything designed by Guru. 
If you are like that, well then. But - we were promissed, that this 
time, the system is going to be done the right way. I really don't 
understand your position, as you surely do understand, what we are 
talking about here. It is not about rounded buttons and such details! 
"all possible arguments" is just one single thing - OS compatible 
behaviour. And if you suggest we should wait 10 years here - well, 
time to move away from VID then ...

Pekr, I think it's too early to comment on parts that have not yet 
been written or decided. Can we settle for discussing parts that 
have already been done?

Note: If my site is slow or down, it's because it's raining. My wifi 
connection is bad, because a big tree has started blocking my antenna's 
line of sight. I've not received permission yet to cut the tree down.

poison it!

I mean, top the tree ..ie. trim the branches

:-)

yes Henrik, slow. I thought it might be my browser. Last months, 
there is something happening on the internet overall. Lot's of "invalid" 
connections dropped on our routers ...

I sometimes have to reload sites. But maybe just my AVG plus Vista 
plus FF3 combination, dunno ...

Your site is so slow, that I can sometimes even see textual path 
of the file, which starts to be downloaded a bit later :-)

Since no matter how long we spend on VID++, it can't be released 
without a finished core, doesn't it make sense that work on core 
be restarted?

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