World: r3wp

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

ok, thanks, that would be good. just post it on the discussion page 
for the specs.

Can you post a link to your doc on DocBase? Can't find it from menu 
...

http://rebol.net/wiki/R3_GUI_Specs

created a section called Accelerator Navigation. you can post in 
there.

who has read the whole source code for the R3 GUI?

 ... I have, and my gut feeling is it could be made simpler without 
 much loss of functionality ... it just feels too "denormalized". 
 That's not intended as a criticism, but a statement of [my] preference.

right

I Agree, lack of factorization. It should not weigh as much...

I haven't read the GUI source in a while, but remember it to be kinda 
disorganized. That is what prompted Carl to make a module system.

So, same impression as the rest of you.

 AGG group about a bug in TRANSLATE

. henrik not a news that bu exist since 3 years i submited it long 
time ago when i was implementing matrix translation in AGG when i 
was writing SVG renderer. So far no one seemed to care about that...

So far there is no high level widet like flexible tables  treeview 
etc...

windows still can't be transparent

the bug has already been fixed, so this will be available in an upcoming 
R3 build.

no note view no status bar no menu bar no menu pop  that still very 
rought interface ....

henrik  glad to hear that

no tooltip ...

( and on tooltip using AGG some cool effect can be done there ... 
 ( like a progressive fade away in time) )

it's a pain every time you need an advanced widget to have to do 
it from scratch  you then spend alot of time  designing widgets instead 
of inputing fonctionalities to your software

widgets should be organised in my opinion in 2 categories the first 
one are the "most used ones" not every one will put a tree view or 
a menu in his main windows but everyone will put  labels fields and 
buttons to most of their applications