World: r3wp

this really is about as minimal as it can get with the layout dialect. 
validation would be another reactor.

I think it will improve with the next prototype. then it will be 
clearer what's going on inside ON-EMIT.

for e.g. on-update was usefull ... when user updated the field ... 
it could cause setting/updating another field. The method was so 
advanced, that if you deleted the record via the API, it caused DB 
updates, so e.g. if you accepted something on-stock, then deleted 
it, it was withdrawen automatically.

on-update is a different concept, which would be done using an ATTACH 
reactor. We still have to decide how this is going to be done. Carl 
did not like the first suggestion of adding a flow engine.

Henrik - is there any progress on more important GUI parts, like 
keyboard navigation, etc.? :-)

keyboard navigation is already there. we just lack a GOB to display 
which face is tabbed.

next will be to return to ATTACH and see how we can do this as simply 
as possible without getting a "no" from Carl.

Do we count for so called "accelerator" keys? I mean - in Windows, 
you can see underscorred letters, which you can use as a keyboard 
accelerator keys. But I can also imagine other aproach, e.g. that 
pressing Alt will display small boxes displaying accelerator keys. 
E.g. Lotus Notes does so. If there will be layers introduced, it 
could be rather easy to have such visual markers (ditto for mouse-over 
help)

I noticed this under Experimental in face-reactors.r3:


signal: ["Send a signal to another face." id [word! integer!] who 
[word! none!]] [
	unless who [face: parent-face? face]
	do-style face 'on-signal id
]

Pekr, that might be possible to do. An interesting issue is how to 
write up accelerator keys in a simple way. I'm considering a small 
dialect: [alt ctrl d] or something.

I guess my bias is that the burden of what input goes where is on 
the data/application model. To give the UI that responsibility would 
seem unnecessarily complex (that's not to say it wouldn't be favourable 
to some applications, but this is core design, right?). I'd find 
it more useful to have the UI have an independent data model where 
I could extract some data to send one (or more) place, extract other 
data to save another, and so on.


I find that's what I miss when working with R2 VID, not so much that 
it doesn't bind to data sources...

Off the topic.

One off the things I added to my events  handler is the propagation 
of the events (from the inner to the outer face).
Like in R2

It's so much handy when styles have sub-faces (allowing generic actors).
Henrik, don't you have the same need ?

I'm not sure what's meant by generic actors? I haven't investigated 
whether we can do that now or how it would be used.

ok, an example.
You make a button style with subfaces.

But the click event must be throwed to the container independantly 
of which sub-faces received it at first

I'm not sure why I would want the subfaces to be receiving the event, 
if the container face is supposed to act as the button? I would perform 
the action on the container face.

But I think this is fully possible, if you need it.

But actually, the event will not be sent to the container if you 
move your pointer over a sub-face

if you don't povide it in the event-handler, I meant

If I need to communicate with the container, I usually just: do-style 
parent-face? face actor-name

I was just wondering why you don't need it, actually :)

well, ok it will work, but  in your case, the child faces must be 
well aware of the need to redirect some events to the parent.
In my model, they don't need to know it.

The container "capture" the events he needs

ok, we'll just have to see if this becomes necessary later. the model 
I base containers on is a little different.

right now I have some trouble getting the new record reactor to work....

:)

Chris, you are somewhat right. At least there are some parts of GET-PANEL 
and GET-FACE I've not paid enough attention to. The thing for the 
prototype is that it collects data from faces and puts them in an 
object in kind of a convoluted way.

What about the following design for GET-FACE:

- When used on a panel, GET-FACE returns a flat object

- If a face doesn't have a set-word name, then it's not included 
in the object


And for SET-FACE, it would have to be directly opposite, so you can 
say:

set-face get-face panel

I think that'd be good step forward, and quite intuitive...

And if possible, the top-level layout object...

This http://www.rebol.net/wiki/Template:GUI_TOC leads to this http://www.rebol.com/r3/docs/gui/gui.html
and this message


So, you found this page from the sitemap? Sneaky.

This GUI section 
is under construction (on a different server). It's not meant for 
publication yet. To be transferred here as they move into final draft 
stage.

Many of these links don't yet exist. They are being filled 
in at this time. Also, the image links are not yet setup.

So, no I didn't.

Are scripts like Jawi script supported?

Guess right to left is not

Chris, the top level layout object is the window and it should be 
possible to get that too, but by using GET-PANEL directly. GET-FACE 
on the WINDOW style returns a value that would be stored by clicking 
an ok or cancel button in the window.

...but the value is not yet stored as the ok and cancel button styles 
don't yet exist.

Looking at reactors now, this seems to be the way to store these 
emit functions. Reactors are more powerful than I thought and according 
to docs, under the place Graham links to above, we can write our 
own. The MAKE-REACTOR function doesn't exist though, it's called 
MAKE-FACE-ACTIONS.


I hope to make use of triggers as well. Triggers are faces that are 
not stored in the layout after they have been processed. They are 
performed either when entering a panel during layour or when exiting 
it (possibly also other places). I hope that triggers can be used 
to pass specific options to already laid out faces, making triggers 
appear as options to a face.

ok, triggers can't be used, as they only work on panels. There's 
too much work involved in making them work for individual faces, 
it seems.

Making a trigger work on a face would require making the face contain 
other faces. Which would turn it into a panel.

BrianH, yes, that would be a work around, so I'm not using triggers.


I've written a GET-DB-PANEL function now that fulfill the specs, 
including SKIP, TABLE, _DATA, scoping, etc. This function is custom 
to RM-Asset, so I'm not sure we want it in the R3 GUI other than 
as an extension package.


Also, I've written an EMIT reactor that emits the panel in GET-DB-PANEL's 
object format as an SQLite record (predefined object).

I'm using options for now along with GET-DB-PANEL.

What this shows:

- Writing reactores is easy peasy.
- Using reactors is even easier.

- Doesn't break anything in the R3 GUI, if you GET-PANEL instead 
of GET-DB-PANEL.

An example of how this is used:

rec: make object! [] ; the SQLite database record object

view [
	form-panel: panel 1 [
		id: field options [skip: true]		; write-only field
		name: field				; stored in the object as 'name
		age: field				; stored in the object as 'age

  note: field options [_data: true]	; both these will be stored in 
  the _data map!
		bytheway: field options [_data: true]
	] options [record: 'rec]
	button "Emit" emit 'form-panel
	button "Submit" submit 'form-panel %form.txt
	button "Acquire" acquire 'form-panel %form.txt
]

So when you press Emit, 'rec will be set to:

make object! [
	name: ""
	age: ""
	_data: make map! [
		note: ""
		bytheway: ""
	]
]

If you press Submit, this object is made:

make object! [
	id: ""
	name: ""
	age: ""
	note: ""
	bytheway: ""
]

and is stored on disk with the name %form.txt


If you press Acquire, the above mentioned object is automatically 
loaded from disk and into the form.


Still need a one-liner for loading SQLite data into the form. Going 
to work on that now.

I know that you guys are doing some stuff for real apps, but those 
concepts really seem very preliminary, and kind of high-level in 
relation to GUI itself. Maybe this does not even belong to GUI itself. 
I alway hated, when GUI dictated me, how should I work with my data 
.... it is always like that - you come up with just one method, of 
possible tonnes of other methods of data to form relation handling. 


We don't have tabbing, focusing, accelerator keys support, unicode 
support, layers, transition effect, rich-text and draw probably still 
need some improvements,  etc., we don't have any more complex style 
to prove our GUI allows to be extended flexibly, so I think that 
solving how to handle data from SQL at this stage is very very preliminary 
:-)

This is just my opinion :-)

Robert needs this for an application as soon as possible. I can assure 
you that if things like GET-PANEL and SET-PANEL aren't working correctly, 
getting data in and out of the UI will be quite painful, worse than 
digging through an R2 face tree manually. But fortunately I spent 
these few hours yesterday, making sure it's easily done in a single 
line of code.

so, why not to fix get-panel and set-panel then? :-)

fix? could you rephrase that? I already fixed them.

Anyhow, a form like this:

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

can be set in one line of code and retrieved in one line of code.

Nice! Henrik - one question. In Zachary app generator I used in DOS 
era for Clipper, there were basically two options, of how to initialise 
form - 'new, and from DB. Simply put - you set-up new record, and 
you want to have some items to be pre-filled with some default values. 
Is that possible with your concept?

Nice "skin" too :-)

I used Genifer for dBase and Clipper

Currently the form is bound to one record. Good question, btw. on 
new item. It's simple to do in principle, but I think it requires 
a clearly defined set of functions (reactors) for simple db operations:

I guess one wants these reactors (names not finalized):

emit - get data out of form to table. Done.
obtain - get data from table into form. Done.
next - next record
previous - previous record
first - first record
last - last record
new - new record
delete - delete record

In Zachary I really liked one feature. There was subtale, where you 
defined On-update ... simply you could add multiple to-update records. 
So - you e.g. added 5 iPhones to stock. The field has registered, 
that on-update updates stock amount. If you deleted order, it was 
automatically withdrawn from the stock ... etc.

there is also the case for displaying multiple records in one form. 
I've solved that in the VID Extension Kit, by providing an alternative 
form with fields that are disabled. clicking a checkmark enables 
the field and lets you set a value. when the value is set and you 
submit, the involved records have that value updated.

When will we be able to build more complex styles, as tabs, grids? 
I mean - is all infrastruture inside already?

I do remember how I disliked one simple draw block (one gob) to represent 
a style. IIRC BrianH said, that multiple gob styles are possible. 
Would that be a hack? Or is method already supported?