World: r3wp

so, enter is the event being passed to 'set-clr ?

Yes, 'set-clr itself belongs to what widget? To window itself?

It's a function of some type defined lower down

... from source code it seems though, that the action is somehow 
fired from slider? But you drag slider by mouse, no? So how are you 
supposed to get 'enter event there? I would understand it, if particular 
slider would be focused ...

it's not an enter

it's an event

when you slide the slider, the event is passed to set-clr

what is "when [enter]" then? 'enter being just a function argument 
name?

guessing so

can't be all events ...

so perhaps 'enter refers to some particular type of event

So we have got high level (VID) ability to define actions ....

I would welcome more real-life scenarios, which are not yet implemented. 
Accelerator keys and focusing. We need to be able to follow OS compatible 
behavior.

basics first

Isn't it basic? Those things can not be easily plugged into imo. 
They might influence the design (look at VID2). VID3 hopefully counts 
on it. E.g. if button or other elements are supposed to support accelerator 
keys, you need to use rich-text there instead of text for the description 
....

what's an accelerator key?

Hmm, keyboard shortcut to get focus to the element you want? #key 
in R2 VID.

uh.. ok

petr, from what i see, on [enter] means that the action is executed 
when the window is shown (you "enter" the window), and it is also 
executed when the sliders change (do 'set-clr), so it's reused.

i don't like at all the lab50 thing. that will NOT allow localization, 
just to make an example. i consider having to size things explicitly 
a HUGE mistake and i will never say it loud enough.

E.g. with labels the situation is interesting :-) You have to somehow 
display in label (usually by underscoring particular letter), what 
key is going to be used as an accelerator, but the focus is supposed 
to be given to the field ....

Gabriele, Carl does not like it either.

Gabriele - such opinions are strongly needed. Please go and put them 
into blog comments section ...

Status:

Ah crap... sorry

was it supposed to be private? :-)

Pekr, no, it's that stupid default that Enter sends the message. 
I hate it. I want to KILL IT! :-)

So, if the enter refers to the slider moving event, what about other 
events like mouse over etc?

Henrik - you can change it in settings, no?

Pekr, yes... but the point is that it's default and I set up new 
AltMEs all the time. I hate it.

Gabriele - how is lab50 thing different from simply creating new 
style? Or is just the specification of size the problem you are talking 
about?

So, Henrik, what's the status?

Status:


- Asset management is a big question. There are design questions 
to solve with regards to loading and unloading assets to make it 
easy to switch skins. Carl has mentioned the three skinning layers 
in his blog post.

- I proposed a method to specify lists of materials in a very simple 
way like FONTIZE and Carl liked it, but it's not yet implemented. 
This is inspired by what 3D modeler software does to manage materials, 
rather than what other GUI engines do. It's much more formal.

- I proposed a method to generate materials for gradients in styles 
in a very simple way. Carl liked it. This is halfway implemented.

- There's a function to generate a gradient from a description in 
a compact way and then apply a function to it to create a real adjustable 
specular highlight. This means you don't have to work with a big 
set of tuples in a block to create a good gradient. You can see that 
in action here: http://rebol.hmkdesign.dk/files/r3/gui/026.png

- Carl is working on panels and groups. We're building small apps 
to try to reveal bugs in the layout engine.

- Panels has a bug that cause cells to overlap when resizing. This 
is not evident in my screenshots though. 

- Resizing with refresh bug has not yet been fixed and you may see 
it sneaking in, in some of my screenshots.

- Text handling (cursor movement, selecting, etc.) is still pretty 
basic. I think it's due to the event system being grabbed directly 
from VID3, as it behaves the same way. There needs to be a person 
capable of writing this code, as it can be done as an isolated project. 
Gabriele is a prime suspect here, but he's probably too busy at the 
moment. If not possible to do now, then it will have to wait a bit.

- Carl talks about getting more people working with VID3.4 this month 
to get them to write real apps to reveal bugs in the layout engine. 
Needs lots of testing.

- Text fields allow text to be painted right out to the edge of the 
area-size, which looks a little silly. Carl wants Cyphre to look 
at DRAW clipping.
- Accelerator keys - no work done yet.
- Disabled or focused items - no work done yet.

- I have skinned button, toggle, slider, text, area and progress. 
I hope to skin scroller and panel today.
- Constantly working towards simplifying styles.

Henrik - you still feel no need for frames to return?

I've not needed it so far. In fact the last remnants of frames have 
been removed in the latest build.

Code example:

do %load-gui.r

files: read %*.r

view/options [
	tight [
		text-list files do [set-face ca read-string pick files value]
		scroller
	]
	ca: code-area
][
	title: "REBOL Scripts"
	columns: 0
]

Produces

http://rebol.hmkdesign.dk/files/r3/gui/036.png

That is why I suggest strategy of not adding new styles, but adding 
ALL subsystems. Because then you can see, if your upper layers do 
fit. Accelerators, focusing, disabling or other states combinations 
might change the view, if one single draw block is sufficient, or 
not ...

Henrik, that's cute! :-)

what is read-string?

oh no, I hope we did not go with read-string and all possilbe read-my-file-format 
instead of clean read/as and decoders aproach?

>> source read-string
read-string: make function! [[file][deline to-string read file]]

Henrik - I know it might be easy. Carl does not see it as a problem, 
many of you probably too. But using myriad of read-* is imo anti-rebelious 
and suggests that not enough emphasis was put into design. I hate 
how rebservices are polluting name space, cloning all possible send, 
do, wait, open, etc. functions ... but everybody of us has his/her 
own preferences .... I really don't want to end with 100 of read-* 
functions ...

Today I was supposed to try to edit one corporate .swf file. Oldes 
suggested me some decompiler. There are items like - shape, image, 
font, text, button, frame, action, misc tags ( http://www.xidys.com/pekr/flash-structure.jpg
). It seems like flash (dunno if decompiled view is identikal to 
their proper IDE) is using kind of page-layout engine. Our corporate 
flash presentation is like browsing dynamic web. So far, with VID3, 
I can't see enough of  "rebol browser" in there, but more an app 
dev. platform. What is our equivalent of "page" - is it a 'panel?

'panel is the base for a window (currently), so it probably is.

It seems you settled for the final button look? Looks decent, at 
lest grey variant works. As for toggle, not sure color distinction 
is enough (colour blind ppl), and we should not add kind of 3D effect? 
(Button pressed, like in VID2?)

toggle is pretty noticable when you use it.

when looking at 35.png, the gradient is a bit strange - looks like 
2 color segments, instead of gradient ... is it supposed to be like 
that?

it might be a little strong

Henrik, is your website down? (The rebol.hm... one)

my wifi connection is pretty bad these days, so try again later if 
it doesn't work too well.