World: r3wp

I don't have to do that. Windows does that on its own perfectly fine. 
Which doesn't help my blood pressure. :-)

you can already write your own styles.  though I found issues with 
using sub-gobs in your face/gob.   the event and other systems try 
to use them as faces... which is wrong.  

I had to patch various event handling funcs so they ignore gob/data 
= none

Maxim, that would be an important issue to fix as soon as possible.

yes... especially since AFAIK the idea of gobs is to use many sub 
gobs for a single face...

well, actually the faces do contain other faces, in a VID style configuration, 
but it may very well be that event handling is not done correctly.

do styles generally use one bog + one or multiple draw blocks, or 
multiple gobs + one or multiple draw blocks can be used? I remember 
Gab's VID used multiple gobs for one style, no?

I don't explicitely want to use a face within a face...  for graphics, 
I want multiple gobs in a single face... so event detection, which 
starts at the gob, should allow us to have a state where if its user 
data is none, its just ignored from the stand point of the generic 
face handler...  at some point, it will hit the actual parent gob 
which IS the face, and event handling should occur there.


just ignoring the none user data is all event detection rountines 
in the r3gui you posted, did just that. IIRC.

is = in

Pekr, AFAIR, a single gob is used per face. Several gobs were manually 
managed by the style writer in Gabriele's VID3 and was part of why 
styles were harder to write. I don't think, however there is much 
that prevents the style writer from writing a style that uses several 
gobs.

I find it easier to use many gobs for many styles... especially when 
mixing different gob types to form a single face.

well, I found it harder, so this is a relief. :-) but inside a style, 
I think it's possible to freely use any number of gobs.

yep.. as long as the event problems noted above are fixed... is already 
works well  :-)

Maxim, if you have some fixes for R3 GUI, please, share them with 
me.

oh it was mostly hack and slash rambo stye fixes... the most important 
is just adding a sub to any style and trying to make it go thru events... 
its easy ... it crashes until all events flow thru gobs which have 
user data set to none.

subgob

New r3-gui.r3:

http://94.145.78.91/files/r3/gui/r3-gui.r3

My domain seems to be gone. Will have to fix that later...

I will begin working on database reactors soon and will want to review 
it with the community.

database reactors? what is that? I mean - how will it link to particular 
db?

sort of, yes. write a form and add a few keywords and you can add, 
edit and delete records in a db.

interesting ... I can't imagine how it will work. Each of us uses 
different DB, different relations, different aproach to things ....

what would be interesting would be to have the community write a 
simple flat-file database backend for it

Pekr, the reactors link to some functions, which then in turn create 
the specific procedures for adding, editing and deleting in a table 
for a specific database.

I would like to better see more styles, keyboard navigation, editing, 
tabbing, etc. :-)

sounds good, don't forget update ...

this is also just one approach, one strongly advocated for by Robert 
and if done right, it will be quite fast to work with

db-reactors is high priority, so I have to work on it now.

Pekr, tabbing is beign worked on right now

maybe db-*, as for naming convention, as I can imagine e.g. delete 
or update reactor for some non DB related purposes too?

Rebolek - cool then!

A basic example of how it looks right now:

f: view [
	form-panel: panel 2 [
		group 1 [
			title "Record fields"
			bar
			group 2 [
				label "Name"		name: field		; stored as name
				label "Address"	address: field	; stored as address
				label "Age"		age: field		; stored as age

    label "Skipped"	skip-field: field options [skip: true]	; not in the 
    list
				label "Ignored"	field			; not in the list
			]
		]
	] options [record: 'rec]
	group 6 [
		button "New" obtain 'form-panel add-record
		button "Save" emit 'form-panel update-record
		button "Delete" do [delete-record]
		pad
		button "<" obtain 'form-panel next-record
		button ">" obtain 'form-panel previous-record
	]
]


The 'rec is a record object, which is filled with data from the server, 
using the backend function, and when submitting, is used to gather 
data from the form and into the server.

what is 'skip for the field? Is it for tabbing to ingore the field?

The trick is that a panel acts like a record. You specify the record 
object in OPTIONS. Then any named field, checkbox, slider or whatever 
participates in the record unless the option SKIP is true.

SKIP allowed reading the record, but not writing back changes, such 
as a "last updated" field, which you don't want to write back.

then there are OBTAIN and EMIT reactors, which are siblings to the 
SUBMIT and ACQUIRE reactors.

http://94.145.78.91/files/r3/gui/db-reactors.r3

This shows a simpe skeleton of what it's made of.

The SKIP and RECORD options are scoping, so if you define a panel 
with SKIP, everything inside it is skipped on EMIT.

henrik there is already a decent db on rebol.org from Pavel... might 
want to look into that.

thanks

if you read his posts here, its quite interesting... probably just 
what we all want RIF to be.

RIF is RIF, let's wait for RIF, and not use pseudo dbs! Apart form 
that, doesn't Robert have SQLite for R3?

the point was really not to find a database, but to connect to it 
from the db reactors.

why ignore what Pavel has done?  why shoudn't his research contend 
for being RIF if it actually tackles the issues and works?

yeah... just saying that its a nice rebol-based experiment.

Henrik might as well use plain blocks :-) What are reactors after 
all? VID level actions, which unde the hood refer to some functions, 
so ... you could as well use rebDB or any in-memory aproach ...

right. it's those functions that would be nice to have written for 
various different DBs.

The thing is, that for multimedia, kiosk, tablet, multitouch etc. 
UIs, all that stuff is useless, and that is my point all the time 
:-) Henrik - one question - aren't you afraid, that all the stuff 
you work on, might be dismissed by possible change in architecture, 
when some other subsystems are going to be added? And also - how 
all this stuff is going to be optional? Look - even low-level R3 
now has various boot options, so e.g. someone can write and replace 
even module system. Now how pluggable (functionality wise) is new 
GUI going to be?

What if I don't care for your validation, your DB reactors? What 
if I am used to work with form and db my own way? Will I get one 
bloated gui? Carl was very picky for each single function to add, 
and now we are adding whole layers upon the GUI, which is still far 
from being finished.

Pekr, db-reactors and validation are optional features. Reactors 
are made using the MAKE-FACE-ACTIONS function, which specifically 
is designed to add a new aspect to the GUI in a way that doesn't 
interfere with its original functionality. And while you don't care 
about it, we do, because we need specifically to builds apps that 
use them, and I've missed these things in VID since I first used 
it. There's also that little detail about shaving off months of development 
and testing of large apps. The "bloat" you talk about would be around 
5 kb of code for now.

That's not bloat of code, but bloat of functionality I tam talking 
about. My experience is as follows - sometimes I like to use frameworks, 
but I don't like using frameworks just for the sake of frameworks 
themselves. Young guys did new SW for our old kiosks we installed 
around, and it seems so complicated (all xamp, web, replicated mysql), 
that they had to call their guru to set-it up.

I just wanted to say, that sometimes it is easier to not use some 
framework, because 1) each framework can do only certain stuff 2) 
you have learn this stuff 3) more complicated things are difificult 
to do. Goog example is that overhyped DB for Rails, don't remember 
the name. In 5 minutes, I needed more complicated set-up, and the 
answer? Bad excuse about framework being good just for certain things 
... no, thank you ...