World: r3wp

Currently, PANEL produces a background along with a border. That's 
why there are a lot of rounded borders in the first screenshots. 
Due to a bug (?) in the layout engine, PANEL must have a draw block 
assigned that fills out the background with a neutral color.

GROUP behaves as follows:

- No background

- When not specifying elements in a group block, they layout vertically.

- When specifying elements in a group block, they layout horizontally.

- When specifying a number for the group block, each element lays 
out horizontally until the number is reached and then a new row is 
started.

Differences from VID3:


- There is no concept of rows and columns. Elements of uneven sizes 
will uncritically be laid out right next to eachother. I've not yet 
discussed with Carl whether this goes in or if there is a different 
solution. I've observed code for grid management in both GROUP and 
PANEL and a facet reading "grid: true", but it seems not to be working.

are you the only person testing AltVid?

no

Just the only one talking :)

So far :-)

A couple of articles I found interesting about the future of interpreted 
programming languages. 

http://weblog.infoworld.com/fatalexception/archives/2008/10/virtual_machine.html

http://weblog.infoworld.com/archives/emailPrint.jsp?R=printThis&A=/article/08/10/13/42TC-dynamic-futures_1.html

VM, JIT and access to other programming languages libraries is the 
future...
Maybe Rebol 4 ?

There is no concept of rows and columns.
 <--- this was a bug and has been fixed.

Petr, most of the styles in VID3 use just one draw block. Also when 
using multiple gobs, eg. in a scroller, they have one draw block 
each too, and state is just changing the value of some words. Carl's 
version just limits this to a single draw block, without automatic 
resizing. Which, you're forced to do if you remove the distinction 
between feel and look (you're stuck with whatever gob structure was 
in the original style anyway without that distinction).

Henrik - it seems your button design does not work for darker button 
variants, does it?

It's very difficult to produce anything useful with a darker color.

maybe changing button text color to white will be needed in such 
cases, or white 1px outline of text, but not sure how would it turn 
out ...

That would complicate the code a bit too much. We can only recommend 
that people don't use dark buttons. :-) It's easy for the user to 
adjust anyway.

Henrik - you latest screenshot simply shows, that 'label should be 
antialiased imo ....

Carl's now describing a bit sizin model in following chapter - http://www.rebol.net/wiki/GUI_Panels

New VID related blog posted - http://www.rebol.net/r3blogs/0152.html
- GUI: Thin skins, thick skins, and in-between

That Panels doc is a work in process.

Color picker example - http://www.rebol.net/r3blogs/0153.html- I 
gues now with Carl's frequent enough blogging, there is no point 
in posting such links?

I mostly find links to Carl's blog these days by first going here. 
So it's good from my point of view.

It kind of made point, when Carl posted once in two months. But now 
it is almost daily, so maybe I will stop it, to not flood here. Surprised 
a bit by low number of reactions. I thought ppl will be more interested 
in new GUI and how it starts to turn out ....

Generally we are people who do things, not read about them!

My free time is not proportional to Carl's posts. :-\

I hope the subject of the example, a colour picker, isn't an indication 
that the new Rebol GUI isn't going to native dialogs. Windows, Gnome, 
KDE and Mac OS X all have native colour pickers don't they?

Can anyone guess, what is "Face DO reactor (event action) reuse" 
in Color picker blog? It is represented by code like:

set-clr: when [enter] do [ ... some code here ...]

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