World: r3wp

only need to be coded :)

instead of just hard coding those, I'd rather build a scheme to perform 
automatic shape/size/color/transparency transitions.

those gui elements are live and functioning ...

I agree with Henrik ...

as you can see at the end of presentation.r script, Jeff Kreiss built 
a nice dialect. Reminds me of Scala script ...

i try something like this in my VID, i have a scheme named animator 
(basically a collection of animations, plugable in styles)

the burden is that most of animations need to hack the draw block 
of the gob on which they apply

so i created a function CAPTURE

What do you mean by "my VID"? :-)

I use it like that:
>> capture gob [pen stroke-color]
which means:

if the gob has a [pen color!] in its draw block, then the var stroke-color 
is intiated with it.

And the [pen stroke-color] replace the initial sequence or if not 
found, add it in the draw block.

my VID ?, i do my own research on VID. I don't intend to use the 
standard one in my own apps, sorry for that.

That's OK, no? Noone said there should be just only one GUI. But 
we could exchange some ideas, of course if it is not fundamentally 
different :-)

see the idea:

gob: make gob! [
	draw: [
		line-width 3
		pen red
		text [...]
		...
	]
]

stroke-color: none
capture gob [pen stroke-color]

print [gob/draw stroke-color]
[
    line-width 3 pen stroke-color
    text [...]
    ...
]
255.0.0

will it work with more complex gobs? so far, VID3.4 uses one gob 
per style, but maybe for some styles, multiple gob aproach (along 
with dialect like Gab's make-gobs) might be used ...

I use this to merge effects with existing draw blocks (it's called 
by the constructor of each animation).

It's up to you to merge the effects with inner gobs if the style 
got many.


The VID, I build, doesn't matter if the style contains several gobs.
Thanks to my propagation model of events.

I use the same idea than R2, events are propagated from inner gobs 
to outer gobs, so that i can have only one reactor on a parent gob 
(the container) which trigger the same actions on all its inner gobs.

It's the thing i don't like in the current VID and it's why styles 
can't deal easly with several children gobs to my mind.

I use this to merge effects with existing draw blocks (it's called 
by the constructor of each animation).

It's up to you to merge the effects with inner gobs if the style 
got many.


The VID, I build, doesn't matter if the style contains several gobs.
Thanks to my propagation model of events.

I use the same idea than R2, events are propagated from inner gobs 
to outer gobs, so that i can have only one reactor on a parent gob 
(the container) which trigger the same actions on all its inner gobs.

It's the thing i don't like in the current VID and it's why styles 
can't deal easly with several children gobs to my mind.

Steeve, above script does not run for me using latest R3...

Script error: skip does not allow word! for its offset argument

first version works though..

insert strokes: skip find fire: [

Bingo! Nice!

A small question: I am reading the GUI documentation. Are concepts 
exposed going to change since the resuming of developments ?

Some parts in the docs don't match the source that we have here, 
but I'm not sure if it's something that Carl is doing or if they 
are mistakes left in.

As far as we can, we'd like to keep the concepts as they are, while 
probably introducing 1-2 new concepts. There are just some areas 
that need better working parts, like resizing.

I get an error with this example from the docs:

button "View" view [button "Close" close]

** GUI ERROR: Cannot parse the GUI dialect at: button Close close
** Throw error: halted by user or script

view: ["Change the contents of a panel." what [word!] where [word!]] 
[
		; Allow it to open a new window too ??
		switch-panel get where get what none
	]

Seems you can't pass a block to the 'view reactor.

it seems that reactors are supposed to be self documenting, but I'm 
not sure how to get the help information out...

Any progress on R3-GUI side? Has the work already started? :-)

I've been working on docs (a dialect for image annotation in docs, 
actually) for a program, so not much here. Some things are actually 
very difficult to do in DRAW. I could use a pure alpha overwrite 
mode. I've posted a report in the AGG group about a bug in TRANSLATE.


I might add something to specs, which I've been working with as part 
of writing docs: A way to use a layer to provide editing tools, i.e. 
box handles, rotate handles, swipe selections, moving and resizing, 
like you have in many graphics editors. I think this can be done 
in a generic way and would make it easy to build any kind of graphics 
or GUI editor.


This is not something that we want to add now, but it's nice to think 
into the design, so that it's simple to do later (and to remove, 
when Carl announces that he doesn't like it).

So this is for group (us) to consider, and for Cyphre to implement? 
:-)

TRANSLATE is for Cyphre to consider. The rest is me and everyone 
else.

But generally said - we are still waiting for Carl to move View to 
command! interface and releasing the sources? Carl almost finished 
GUI docs, which is nice, but I still miss one doc - his pov on - 
where to go next - still some concept descriptions missing, e.g. 
his plan for layers, etc.

Yes, some things are a little odd in this respect: the docs state 
functions that don't exist, such as MAKE-REACTORS, but he hasn't 
said anything about whether he's modifying the sources. Once the 
View host gets released, many more people can work on their things.


For us, there are plenty of things to work on: Begin the implementation 
of a proper table, better dialogs and more styles.

those things you mention (more styles) can be done even in recent 
VID state? Do you regard architecture being stable? E.g. - I remember 
you (and me too) did not like max-size. But it is basis of Carl's 
resizing model calculation. So no fear of later changes on your side?

One never knows if the architecture changes, but I don't think that's 
likely. There are some things that are unclear with styles, such 
as how to change FACE/CONTENT dynamically, but otherwise there is 
plenty of styles that can be implemented.

Henrik, for once the docs about the design were preceding the implementation.

Playing with R3 GUI...I see panels and groups resize horizontally 
but is there a way to get it to resize vertically...or does that 
involve playing with the style code?

resizing is said to be broken .. so I'd wait

yes, this is currently broken.

I need to ask who has read the whole source code for the R3 GUI?

you, BrianH, and me :-)

but I am a lamer, not a coder, so I can only bug you with many questions, 
and point out some things I eventually don't like (and in many case 
I don't like them because of my wrong understanding of the topic 
:-)

Pekr, do you find it understandable? Does it help you to understand 
how it could be extended?

ok

VID3.4, from what I have seen, is more understandable than VID2. 
Maybe also because we now have docs, describing faces, their fields, 
on-* methods, etc.

What I did not like in the past was departure from multiple gob design 
and make-gobs, and limiting style to single draw block. But later 
on BrianH explained to me, that the design is ready to use multiple 
draw blocks (kind of original frames concept)

where my "experience" ends is event - mainly keyboard, editing. Rather 
difficult topic for me. So I am still eager to see, how keyboard 
navigation is going to be supported. This is BIG topic for me. Because 
as I already said in the past - users are forgiving non-platform 
specific look, but not behaviour. And I am a person using keyboard 
so much. So tabbing, accelerator keys, ability to swith tabs by ctrl+ 
tab (non trappable by REBOL at all) etc. - those things were not 
adressed yet ...

E.g. such simple thing as displaying the accelerator key - under 
windows, you can see underlined letter, representing the keyboard 
accelerator key. But - that would mean, we would have to use rich-text, 
for such things, as button, or even fields, etc. Or - we would have 
to come-up with different concept - e.g. pressing Alt key displaying 
small boxes around the styles, displaying the accelerator keys (layers 
could be used here) ... such concept is used by Lotus Notes ...

Well, the keyboard navigation in the VID Extension Kit is a much 
bigger hack than in the R3 GUI. That's thanks to a good design and 
treating the window itself as a style. There are still some issues 
with Carl's method of tab navigation colliding with mine. Carl has 
a tendency to work functionality that should be generic into a few 
specific styles. I don't really get why he does that, because it 
scales like crap.

So - there are still some design choices to make. And what I miss 
is discussion about those topic, unless we go too far, to later realise, 
we have to rebuild somehing because of new ideas ...

accelerator key visibility is missing from spec. do you want to write 
something up, just to collect notes? I can clean it up later.

Yes, I can write something up ... I already did with Marketing related 
documents (waste of time :-), but it will just collect basic requirements, 
I am not able to outline, how should it be done ...