AltME groups: search

For example: If you can't get AGG to work, you need to do a replacement 
with an equal API layer.

Graham, I don't see a real good case to use the R3 DLL within R2. 
Why to do this? And the interpreter in the DLL is nothing "useful" 
on it's own. It requires at least a simple host environment to do 
something useful.

Transformations are handled by matrix computations in AGG, how do 
you want to accelerate that and keep it portable ?

the draw context in a face is always there ... it's embeded in it 
no need to say HEY YOU KNOW WHAT  NOW WE WILL DO A SQUARE IN THIS 
WINDOWS AND PUT SOME CONTENT in it using some engine

let imagine you do a button you want to draw something on the background 
with AGG and then have the regular button borders and fonts to be 
applyed over  using AGG it's possible to have that effect  with the 
context phylosophy the VID button is a separated entity from the 
agg entity  you have the QT context the QT widgets display in it 
and the AGG widget is one of the few widgets you have but you can't 
mixe content ...

My status: Currently testing the dialog system prototype. This is 
ported from the VID Extension Kit and should allow for a large number 
of different dialogs. Still some work left to do, but have some basics 
working.

I do a lot of dynamically creating layouts .. I suspect it's related 
to that

hmm... yes. I still don't see how you are able to do that. From what 
I can gather, it's not much different from VID in that face names 
are set as they are laid out, and when that's done, you can use the 
face. Talking about the *speed* at which widgets are instantiated 
worries me a bit. :-) That should never be an issue unless you are 
doing some form of multithreading.

now that I think of it, I'm not sure how much good it will do to 
add callbacks to CLOSE, since CLOSE for dialogs is meant to give 
a fixed way out of a dialog.

as it is now, the dialog system "forces" some specific routes. the 
intent is that dialogs must allow dozens of different standard dialog 
layouts and standard buttons. combined, forms in layouts would automatically 
be validated and the dialog would behave appropriately, i.e. not 
closing if the form and provide warnings is invalid. this works now 
in the prototype, and the end user won't have to do anything to use 
it in the standard dialogs.

You need a close reactor to do the save-your-stuff prompts.

It may be the time to discuss the style name, I just do not know 
what is the best forum for it

HTML refers to this as "inline" (and the line may wrap).
I used 
grid-face/LAYOUT-DIRECTION: 1x1  and  
grid-face/MOVE-FIRST: 'horizontal
in my old GRID style.
	do http://anton.wildit.net.au/rebol/gui/demo-grid.r

But the parameters needs to be clarified some more.

Academic papers published as PDFs often have two columns of text.

That means a single line of text wraps horizontally, vertically, 
and horizontally again.

Eg. The line of text first wraps (horizontal) when the right hand 
edge of the first column is reached,

then, after many rows are similarly wrapped, when the bottom of the 
first column is reached (vertical wrap).

All of that occurs again for the second column (and perhaps more 
columns) until there is no more room on the page,
so the final level of wrapping is horizontal. 

So I would have 
	face/WRAP: [horiz vert horiz]

which specifies three levels of wrapping, horizontal for chars, vertical 
for lines of text, horizontal again for columns (so that the next 
page is underneath the first one).

To put pages horizontally, you would just have 
	face/WRAP: [horiz vert vert]


Or you could specify an extra level of wrapping, eg. so that you 
could have groups of two pages shown horizontally
	face/WRAP: [horiz vert vert horiz]


The direction for each level of layout should be specified to correspond, 
eg.
	face/LAYOUT-DIRECTION: [1 1 1 1]
which would give left-to-right and top-to-bottom.
(Use -1 for right-to-left  and bottom-to-top directions.)

I think it should be possible to make a style like that, if you really 
want it. (Most of the time, you don't want it, but when you do, you 
do.)

Anton, you are free to do that, but it will break the philosophy 
of how styles work together. I think this point is not properly understood, 
but it will move the GUI to the next level, where you spend zero 
time thinking about colors or theme, can properly divide UI design 
between a graphical designer and one producing programs.

simply put - it is not that it would not be technically possible 
to pass any such argument to the style during the construction. It 
is about - we don't want to do that for some attributes, color being 
one of them, because it could ruin overall look of the GUI ...

it's not just looks. deep semantics that are used to make the GUI 
function properly relies on functional styles rather than appearance 
of styles. if you have a red button, the GUI won't know of its importance. 
but if you have an OK-BUTTON, you can tell how important it is, when 
it should be focused and what you are allowed to do with it. automating 
this can cut off hundreds of hours of development and testing time, 
because you don't have to pay attention to those details. the UI 
system does that for you.

Gregg, one thing that became clear in discussions of function doc 
strings recently in Curecode is that it is impossible to fully describe 
the behavior of some programming functions and objects using just 
one name, one sentence, whatever. No matter how long you allow the 
description to be, any sufficiently complex thing won't be describable 
in that limit. And you *want* limits because people have to read 
and write these terms, even more so for fundamental stuff that will 
be used a lot. The use of small, preferably non-compound words will 
speed up the process of humans reading and writing layouts. Java 
failed this pop quiz, btw.


This is why we have names for stuff (and people too: Does "Gregg" 
describe you?). A name serves as a placeholder for the knowlege you 
already have about the object in your head (preferably) or in the 
documentation. As long as we have good documentation, any small, 
easily distinguishable name will do. You will never fully describe 
the term, but by reading the documentation, or source, or through 
experience, the programmer will know what is meant.


In this specific case, "panel" is a general term, but many GUIs have 
traditionally used the word "panel" to describe the corresponding 
concept in their systems. That term never fully describes the behavior 
of that object, but it makes a good, easy to remember name for a 
complex concept that the developer is expected to have to learn. 
By using PANEL, at least experienced developers will know that they 
will have to look things up, and inexperienced developers will have 
to look things up no matter what name we choose. You don't get the 
same benefit from the term BOARD, for instance, because while the 
English terms are similar, "board" doesn't have the historical connotations 
that "panel" does in the computing world, so it doesn't gain the 
benefit of them.

attach: [

 "Set state of a face to our face's value and performs its main function."
	name [word!] field [word! none!] our-field [word! none!]
] [

 set-face/field get name get-face/field face field our-field ; (none 
 is allowed)
	do-face get name
]

how it looks now.

>> source guie/actions/attach
guie/actions/attach: make function! [[face value

    {Set state of a face to our face's value and performs its main function.}
    name [word!] field [word! none!] our-field [word! none!]
    /local
][
    set-face/field get name get-face/field face field our-field
    do-face get name
]]

; also VALUE is in there.

there is no longer a single "action". what you do is state a reactor 
or a set of reactors and it's this set of reactors that would be 
equivalent to R2's action, in that DO-FACE performs that set of reactors 
in sequence.

Although I've implement 5 complete GUI frameworks, so far I've stayed 
relatively silent on the R3 GUI front cause I'm building my own framework 
and I don't want to interfere with the R3 system.


but I will pitch in here and say that what Henrik proposes is a good 
idea (I use the same name for a relatively similar feature), though 
it needs one thing if it is to be usable by newbies.


a way for do-face NOT to call attach.  the reason is that if you 
want several cooperating controls, they must not create feedback.

BOOPSI used an intermediate structure which acted as a controler 
to which you connect everything that has dependencies. then you call 
do on IT.

an other simpler way, is to have a refinement on do-face,  /REACT 
 which indicates that its being driven from another control.  so 
then, you make sure that this face's do-face doesn't follow up on 
its own.

but Carl may have some ideas on where to do it. I'm not sure we need 
to delve into adding whole engines and state machines to do this. 
75% of what is needed is already implemented.

Maxim, DO-FACE doesn't directly chain into other DO-FACEs. I'm therefore 
assuming that we need to somehow store the caller face?

The ATTACH and DO reactors are the only one that is able to run other 
reactors. You can of course freely design your own reactors, but 
we are basically relying on the content of the reactors to help avoiding 
screwing things up.

ok so then does ritch text is a really something to be set as default 
inside the VID extension or isn't it wiser to let that as a side 
project to make research about the perfect way it could be done... 
and we let in draw a set of basic commands related to draw (a revamped 
set ofcourse) for instance I think that a ritch text engine is too 
much for the syntaxe colored editor we made ... it's like taking 
a nuke bomb to kill a single little fly .... but such an engine by 
default can anyway open new perspectives. but what annoys me in the 
process is to do this  raw script -> conversion to ritch text dialect 
-> conversion to draw by the rich text engine ...  instead of doing 
this raw script text from file.r -> conversion to draw using parse. 
But maybe i'm wrong ... anyway one way or another i will do a port 
of area-tc. and i assume that if the rich text engine seems too much 
for me then i could still do my proper engine relying on the draw 
for text lower level instructions.... (not to mention i like the 
idea of learning parse through  experiements)

and more complexity you will add to your engine more unexpected problems 
you will face...


 Like what we experienced in area-tc... suddently our perffectly working 
 engine under wnidows XP shows strong bugs in rendering just by arriving 
 on windows7. After 6 month in searching the why  and not finding 
 any cause to that rendering jam I by chance tryed the ultimate thing 
 no programer does i retro versionned back like 10  version below 
 the rendering engine and there suddently i found that rendering problems 
 disapeared by miracle...


I spend 10 times more time searching why the rendering was defective 
on windows 7 than doing area-tc and viva-rebol.r.  And that's too 
what  completly killed my mood. What else can i do than try to make 
this community know my experience with extensive text processing 
in draw with R2 to not have the same conceptual lacks repeated in 
R3.


And clearly  in R2 the text commands in AGG/draw were not suited 
for docuement rendering... That  doesn't means AGG can't do it ... 
that means at that time the dialect draw wasn't designed to exploit 
 intensivly text rendering. I always said before runnning you have 
to learn to crawl, then to stand up, then to walk. for me the way 
i  saw the realisation of a rendering engine text oriented for draw 
dialect was first step changing the color of  choosen elements in 
the text, then changing the font spécificity anytime anywhere in 
the document then being able to do strong text manipulations like 
moving by drag and drop paragraphs, inserting multimedia content 
in the document, scaling paragraphs etc... 

ROBERT: 

In fact that depends what  the rich text engine aims ... for example 
read only rendering is pretty different of  real time editing wisiwyg 
engine... The complexity betwin both approach is like 1 to 100...

(I still need to do a few changes before handing it over to Carl)

How about a bounty for the text rendering?


To be honest I don't care to much about better quality at the moment. 
We need a way to display text and some formatting (which works) and 
special chars like Umlauts. That's good-enough for us to use R3 for 
commercial development. Optimal text-rendering is nice to have but 
invest to do it must be covered by some revenue first.

The bounty is possible - but who has the skills to do the real work 
apart from Cyphre? :-) And also - how many man-days approximatelly 
would it take? (research plus implementation).

They don't render in different directions. All of them render from 
the top down. What you are talking about is internal coordinates. 
How the gob is located externally has nothing to do with how it is 
coordinated internally.

So all you are talking about is Draw. It wouldn't have anything to 
do with switches to a gob, since it would be fully contained within 
one gob.

that is what you asking view to do.

shadwolf - maybe you should stop accussing guys, who try to do something 
for us. It is not about the money itself, it is about the manpower. 
We have to prioritise things, and money can make help here. As for 
me, I always fighted against - now you can code it yourself attitude 
- that simply sucks. But - in opposition to the past, we actually 
can let it happen - if you contract some developer. In the past, 
all sources were hidden from us ...

Pekr  WHAT HAVE YOU DONE THE PAST MONTH TO TRY TO GET ME CONVINCED 
TO PARTICIPATE IN THIS PROJECT ?


Any time I try get a serrious conversation here about  where are 
we going or how things are done i get cheap lame excuses and I'm 
tired of it ! 


I stated a long ago the current phylosophy in communautary contributions 
don't fit with me (it was in may 2005)  you can't sit on 2 chairs 
at same time and expect to be stable.


You can't say rebol is a commercial trade marked business  and don't 
pay  the contributors and give them credits for their contributions 
.

You can't say a part of it is commercial an other part is free that's 
ethically not right. 

That's my way to see it ...


Then i won't participate to a project where the all mighty god fater 
can come out of nowhere and trash my month of hard work in a blink 
of an eye without any justification.


I won't participate in a team with people that don't want to share 
knowledge.


I won't participate in a team where people can take in hostage the 
whole project to get  money for themselves. 


I won't participate in a project where i can't  do any proposal with 
being insulted...

Did I made myself clear ?

Graham , you have to send small chunks of the data (according to 
Carls notes for the R3 schemes the chunk should be smaller than 32Kb..this 
is true othervise the port connection 'hangs' for me if the chunks 
are bigger ) and do the update during that periods when you need. 
That's all the magic.

inside the layout, you are fine:

view [f: field button do [set-face f "boo"]]


Outside, you need to go through the GUIE context, but I don't recall 
the path.

that would not be the place to do it. it would happen on a lower 
level.

GRaham sure ... but you know things piles up you don't do the most 
 easy part and having the most  impact because you have other better 
things to add more important and in the end you have 10 times the 
gob doing the same thing in an ugly way ...

basic-styles: We need to provide some basic styles with resizing 
etc. included, so you can see how this all works. This is what we 
currently do. Sprint review is today. Than I will have a better overview 
about where we are at the moment. ASAP we will release the GUI to 
you.

I'm just curious to see what the overall concensus would be here 
- there have been so many fads in UI design 3D, aqua-look, flat, 
etc. What is attractive now and for the medium term? Another thing 
I'd like to see are proposals that break away from the traditioanal 
and try to push the envelope. This could possibly involve the use 
of animation, 2 1/2 D, gestures (yes, I know you don't think much 
of  this kind of stuff Henrik :-) , but not in frivolous ways. Personally, 
I hate cluttered UIs that don't do anything to improve usability.

I know a guy who recently left Adobe to do GUI design on contract. 
 He was employed as a GUI designer and has been doing it for many 
years now.  I've suggested to him that this 'could' be a good way 
to get some recognition 'IF EVER' R3 made some ripples in the development 
world.  I didn't get a firm committment that he would do it or not, 
but I will follow up to see if he wants to make a submission of a 
mockup or two.

Robert - what is further "low-level" plan? I can see ( http://www.rebol.net/wiki/Host-Kit_Development_Notes
) that we will get A104, A105, which are going to be more of a merge 
releases. But do you have an idea, what will Carl work on next? Not 
that there would not be lots of work ahead :-) ( http://www.rebol.com/rebol3/index.html
) Will e.g. tasking be next?

Two notes here. Please ask Carl for two small changes/additions:


- Add Projects page directly to the right menu here: http://www.rebol.com/rebol3/index.html
- it is simply hidden and can be seen only from a Roadmap page ...

- I thought we already added tasking/IPC methods to the projects 
page. It is imo important and legitimate, and it should be briefly 
added, untill such feature is implemented - http://www.rebol.com/projects.html

as my futur contribution ? plain and simple their will be none  of 
it ... i shown some thing asked from years now are easy to do and 
i won't do them  to show the lack of serrious and vision of this 
community.


After having being treated the way i have been past week considere 
me as a non active member of this community.


I wish you the best realise your ambitions  even if we all know here 
that it's not possible  for you.

I predictate your faillure in less than 4 more moth ... January 2011 
maximum the actual bounty hunters R3 group will be disbanded and 
nothing concrete will have been done apart the extraction of VID 
from R3.exe to hostkit. When you take money you do things like professionals 
that's the minimal things this means a list of what will be done. 
A roadmap with important steps and release dates  for those important 
steps before starting anywork you make that dev plan to appreciation 
to the public you debat it serriously you remove things you add things 
... You try to get involve the most possible people that have been 
already involve in R2 GUI use or creation because they have the practice 
knowledge and experience. 


Thousand way of being serrious starting a positive attractive motion 
for this part could have been done but by lack of interrest and generosity 
you end doing what you are doing ...

I predictate your faillure in less than 4 more moth ... January 2011 
maximum the actual bounty hunters R3 group will be disbanded and 
nothing concrete will have been done apart the extraction of VID 
from R3.exe to hostkit. When you take money you do things like professionals 
that's the minimal things this means a list of what will be done. 
A roadmap with important steps and release dates  for those important 
steps before starting anywork you make that dev plan to appreciation 
to the public you debat it serriously you remove things you add things 
... You try to get involve the most possible people that have been 
already involve in R2 GUI use or creation because they have the practice 
knowledge and experience. 


Thousand way of being serrious starting a positive attractive motion 
for this part could have been done but by lack of interrest and generosity 
you end doing what you are doing ...

ladislav i foresee what i want and this R3 gui have not better reason 
to succeed than the previous intents since it's based on the same 
main problems to it's achievement in time you will get it.

I have no reason to shut my mouth when i see things so wrong. I exposed 
what i though of this process now please don't fuel me anymore do 
as i was far and in january 2011 remember i said this was going to 
a faillure.

The IF command in the dialect would get rid of the COMPOSE and do 
this: view [button if (condition) button button]

That is what I meant by a Parse-like IF. Possibly not doable in the 
layout dialect, due to overhead.

The DO [ ... ] is an action modifier to the button declaration.

I had to learn a lot of VID's internals to do the resize project. 
But I don't really need to make GUIs much.

the dialect word 'do switches the layout parser to the do dialect

Not unless it has been changed recently. According to the design 
of the R3 GUI, DO doesn't switch the layout dialect into DO dialect 
mode, it declares an action for the button (in your example) to perform 
when clicked.

The code performed by that action is evaluated by the DO dialect, 
but it is evaluated at runtime in response to the action being triggered, 
not at layout time.

As for R3 is supposed to do .. has anyone read the specs??

as I said, the 'do word switches to the 'do dialect

so either there is a compose/deep somewhere .. or there is a switch 
to the do dialect occuring

The reason we never refer to the R3 GUI as VID (for the last 2 years) 
is because we don't want to confuse people. The R3 GUI has nothing 
to do with VID.

Actually there are several changes by Bolek and Cyphre, that I've 
not yet studied, but much of the work that was handled by LAYOUT 
before is now relegated to PANEL and GROUP, which is why we talk 
so much about them and not a central LAYOUT function. They call various 
subfunctions that specifically focus on creating faces and laying 
them out and resizing them.


So the styles themselves are capable of custom layouts and resizing 
mechanisms and also mechanisms such as face init and triggers. So 
that means you are no longer a "slave" of the LAYOUT function.

That's also why:


1. I was talking a while ago about that you can build a style that 
emulates VID, complete with a dialect, or replace the layout mechanism 
with your own, by rewriting PANEL or GROUP or adding new panel styles.

2. That whenever you want to do a new thing, you should make it as 
a style. That's where you start.

There is no confusion, sooner or later we do reach the matrix's "there 
is no spoon" = there is no R2 - old, forgotten, boring. Do you call 
Delphi 6 not a Delphi, because you can't run the code in Delphi 2 
anymore? Does Perl 6 rename, even if different to the old generation? 
VID is a good name. Simply put version 3.x is not compatible with 
version 2.x, easy as that ... I can't see any confusion, if we talk 
about VID in R3 related channels ...

Gabriele, thanks for that "dying for our sins" thing. That was a 
classy thing to do :)

resizing: This is a quite complex topic and we need to make tests, 
try different approaches and fine tune tor the special cases we find. 
So, we don't do it completely up-front, but we adopt it on the way 
until it stabilizes.

so the second to last example ...


move y ( move the bottom menu bar down ) resize x ( and widen but 
do not make it taller )

what functions? form validation related you were talking about earlier? 
OK, do you have anything to test, including some basic instructions? 
If so - send it in ...

it's not a formal release. I decided to do this, because the build 
system became available for use internally today.

I have interest but little time right now Henrik. What do I need 
to set up here to review and comment?

Pekr:


- init already happens on window open. you can specifically validate 
and display init symbols in the indicators.
- possible to do with attach or set reactor
- panel validation already works

Henrik - the proposal does not need to alter the style, right? That 
is indeed good. But - I still have to think about the form design 
- do I have to count for the space for the validator? I talk about 
some alignment stuff ...

Pekr, correct. What you need to do is attach an option for how you 
want to validate. Then you need to place the validation-indicator. 
Then the rest is supposed to take care of itself, auto-updating, 
etc.

Henrik - any progress on new styles, integration of resizing model 
into current system, etc.? You surely can't do business apss with 
just buttons and fields being the only styles available? :-) What 
is currently being done in the R3GUI area? (as View transition to 
Extension has mostly finished?)

the material only represents colors and gradients. it doesn't do 
anything to the draw block.

Rebolek - I do understand the process. I am trying to find out possible 
workflow, nothing more ....

Henrik - maybe I do, maybe I don't. What I did not get is - why the 
stuff is not nested? I mean - is 'required parameter kind of related 
to validation stuff? If so, I would expect something like:

validate [method: not-empty required: true]


... the way it is - we  might polute 'options namespace, which serves 
also other purpose. But again - its just a note, not a complain ...

and the resizing? do we need to set some size of the screen?

Am I doing anything wrong? Why the button moves down = "is attached" 
to the bottom left corner?

 view [title "test" button "OK" do [print "ok"]]

In clean R3 A105 session, I do following to get following image:

do %r3-gui.r3
view [field] ; resize needed to see anything ...

result:
http://www.xidys.com/pekr/rebol/a105-field-strange-chars.jpg

Any idea?

Robert - this is OK with me. In the past, I worked with Cyphre, Romano, 
to do personal testing ... lot's of errors and misconceptions caught 
on my side. In such early phase, I might cause a flood, so if you 
want, I might stop for few more releases ...

A106, text-test3.r - when I position caret to the last position:


** Script error: caret-to-offset does not allow word! for its position 
argument

** Where: print switch handler while applier wake-up loop applier 
wait do-events
 if view catch either either applier do
** Near: print [
    "otc:" mold otc: offset-to-caret gobt event/offs...

henrik, ok, in any case, we can use them within a draw block, which 
isn't that hard to do anyways... in the meanwhile

Yes, this is not so easy to do as you need to always manage the window 
differently for almost every gfx system. I have in works AGG accelerated 
using OpenGL using one trick which makes things much easier and still 
pixel precise. But I need to try convert the pure c++ prototype code 
into the Hostkit first to see how it behaves in 'real world' usage 
cases...

Pekr  na i know it's not the ended thing I repeat the  overall widgets 
are cool  their organisation is cool  but its the grey scale .. 2) 
anyone ? not me at least since people are paid for that the least 
they can do is do a professional default skin ... Henrik i judge 
what is shown that's you don't want to be commented don't show imperfect 
not ended things ...

auto-resizing is good ... if it works as expected of course. I liked 
Carl's model - not the model, but that it did what I mostly expected 
it to do (by examples posted). So far R3 GUI does not work for me 
yet (button sticking itself to bottom left corner for e.g.), but 
it is most probably very preliminary to do any judgements right now 
...

Pekr no i never coplained cause i didn't got some half made work 
in progress to test ... I just complain to get the direction to know 
what would be the futur and to know the agenda ... that's all !!! 
 I don't caore of host kit i don't care of the widgets anyway if 
it doesn't fit my taste I'm grown anough  to do my own widgets anytime 
like i did with R2 /VID

ok, there is a bug (surprise), that I've been able to trigger once 
by accident. I've not been able to do it more than once, but we need 
a way to reproduce it.

what I did was create a GUI similar to this one:

view [
	panel 1 [check]
	panel 1 [button button button]
]


When you resize this vertically by a few pixels, the bottom panel 
will resize incorrectly. That is known and will be fixed. What I 
managed to do, was to either move or resize the window in a way, 
that would cause resizing to get stuck in a loop (!), so it goes 
up and down in size by a few pixels vertically on its own, and the 
window just sits there shaking up and down in size. If possible, 
we would like some help with reproducing that.

Can you resize programmatically, to do it in discrete steps in an 
attempt to find the combination of values that trigger it?

I haven't tried it, and I'm not sure it's a specific size that does 
it, but more a series of events. The testing system is not yet in 
place to do it this way.

It's gray because I tweak colors only when I have nothing better 
to do. Once the GUI functionality is finished, there will be some 
simple color/style designer written in R3GUI to make some decent 
look for it.

Henrik - to your above code example - what I don't like is, why the 
resize system dictates me, how to shring the window. When I want 
to maximize a window, it should not do so only in horizontal axis, 
but also in vertical one. That's just my opinion, but I would find 
it more predictable.

And I can still observe the same behaviour, when I maximize the window 
of "view [title "test"  button "ok" do [print "ok"]]" - the button 
keeps attached to left bottom corner - why? :-)

I don't care if it 30MB in size.   I could help you with the debugging, 
but right now its very tedious to do.

the materials system specifically maps various surface appearances 
to the face states. perhaps it needs to be refined as I haven't looked 
at it in two years, but the intent is to do this in the material 
specification instead of inside the style. so you say "I want material 
X" and then all variants of it are used in the style.

ah think I found the handler problem.


view's awake function now calls the do-event (it used to be handler).


so its just an adjustment to any code running after it loaded r3-gui.

The reason why I am confused about priorities is, that you surely 
are not going to do business apps by using only buttons, fields and 
check-boxes. Areas, scrollbars, draggers, tabs, grids, tree might 
be usefull too :-)

the revision 0 thing in the header will be fixed, once the build 
system can get a revision ID from SVN. if anyone knows how to do 
that, I would appreciate it.

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

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.

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.

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