AltME groups: search

Hmm, I would've expected Maxim to jump in and give his 2 cents when 
he stopped by...

Liquid is the perfect engine to add to R3 GUI.


After years of use in many different situations, I am now very confidents 
in its capabilities.


Liquid is a generic engine, allowing you to tell DATA to message 
DATA.  


This means you can use the same system that you'd use for the GUI, 
for the data itself, and then just plug it together.


Because Liquid was designed to allow very advanced procedural computation 
at a fraction of the complexity of other systems I've used I'd say 
its the best system we'll ever be able to build for R3.


Wrapping liquids within faces and the view dialect is rarely more 
than 5-10 lines of extra code, but then, you don't need to write 
"action" code afterwards.

I've JUST finished work on the first public version of a graphic 
editing software which will go public shortly.  It is built using 
Liquid extensively, using my glob technology (a.k.a. liquid paint).


In this project, I'm even using liquid to do automatic declinations 
of web originated information, some of it directly connected to buttons 
and fields.

Changing some parameters will automatically update other fields and 
button states when the web query is done.  


The software cleans itself up when some other part of the software 
changes internal data.

this is the true value of liquid. :-)

liquid even has data filtering mechanism built-in... so you can patch 
type conversion right in you data, for example, and connect any other 
compatible datatype without needing to build ANY extra code.


Did you notice the detail... I didn't say type conversion in your 
GUI... 


so If your age is supposed to be an integer... pluging it into a 
field can actually make the field an integer field, without the field 
knowing anything about integers.   :-)

anyone can learn liquid.   its dead easy.


its the concept of messaging and dataflow itself which is challenging.

I like to use fields where the prompt is an image in the background 
which disappears on focus, and reappears on loss of focus unless 
some text is present

We should be shown some liquid usage example, the simple one, to 
understand the concept. Then we should be shown more complex working 
app. If liquid is general flow engine (usefull also to non GUI parts), 
it could be added to rebol as a concept, and maybe even made native, 
but I am not sure if it fits the language or not. Maybe it should 
be available in the form of module/extension, dunno ...

AdrianS: I asked Carl to resurface and provide development team with 
promissed GUI related docs. I hope Carl will be back soon, he worked 
on moving Altme services to new servers (as can be seen in his latest 
blog post)

and working on altme server improvements

we will, and as I informed you privately, Carl will hopefully resurface 
soon too ...

where is actual/latest VID 3.4 code stored? I would like to see, 
how 'attach works, and what it allows, then look into your docs, 
and try to think about it for a while ... well, I will most probably 
not come with anything anyway, but I would at least like to understand 
what we area talking about here ...

I have spoken with Carl in the past about liquid, he REALLY likes 
the concept, he was mezmerized when I did a quick demo of it at Paris 
devcon.


But at that time, I wasn't trying to convince him because I didn't 
have enough real-world experience using it, and still had a few reserves 
about it myself.

The nice thing about liquid is that its an API more than anything 
and you can model it to do alot of different things, by just changing 
a few properties and implementing one or two functions.


All the nitty gritty is already taken care of and you don't have 
to play around in that unless you really want to create special and 
ultra-optimized nodes whih I very rarely need to do myself.

the trick with adding Liquid to R3 VID is to integrate liquid INTO 
VID and not the other way around.  in the VID dialect, or as a few 
function calls which just basically create a predefined node type, 
and links it up.

in my soon to be released application, the dataflow aspect of the 
code is less than 20% of the time spent, yet it represents at least 
80% of the actual usefull software capabilities.  


most of it was fixing View and VID themselves... the styles, the 
event mechanism and bugs, AGG bugs, enhancing http, etc.

all of these guis and none of them complete ..

an example of a very complex system which was made 100% robust is 
this:

-an image is used as a background, cropped , transformed and displayed 
within AGG

-we need to overlay an text area over the canvas, but its all AGG 
and its contained within a graphic element.

-we create a face which is a text-area, LINK it to the coordinates 
of the graphic element.

-the face is then converted to an image on the fly everytime the 
coordinates change (even rebuilding the text wrapping interactively)

-this image is added at the proper position with the AGG draw block 
as an image with coordinates.

Currenlty, i try a new way.

No VID engine, just an event handler and Gobs as agents talking with 
their environment.

each gob having a lot of methods and properties

each gob having a lot of methods and properties

the opposite principle has been tested with area-tc. Cul de sac.
(i mean, having a fast engine (but huge and hard to maintain)

@ jocko on rebol.org there is a working version of liquid and a small 
demo of how it can be merged right into VID called blood.r

and i don't like the need of  a phase to construct graphical objects 
from read-only specs.
All the GUI we had so far, act such.
It's an bad...

to my mind there should not be difference of design between a style 
and a face.

A face is an instantiated style (copied and just showed) , tha't 
enough.

Maxim, I have hacked together(in fact it was lurking on my hdd for 
couple of weeks but I got to publish it here today) a test of one 
concept which IMO could solve part of your requests regarding 'access 
to DRAW elements' etc in R3. It can be also handy when you need to 
manipulate content of complex DRAW blocks...or even be a base for 
scalable vector graphics editor...or....I think there is relative 
big potential of usage :-)
Just try to run:
do http://www.rebol.cz/~cyphre/scripts/r3/tests/draw-shapes.r
in your R3 console.

BTW The demo also features pixel precise object masking and optimized 
redrawing of DRAW objects just to prove we can do lot of things even 
at the higher level.

The file contains couple of predefined objects but the main code 
is very small like 4kB so it should be easy to see my point. Hope 
this could help a bit to someone.

Gregg, hmm...just checked the CPU usage and it looks like some regression 
in R3 view timers to me.
in R3 (2.100.97.3.1):
forever [wait 0:00:00.1] eats 10% of CPU 
forever [wait 0:00:00.01] eats 100% of CPU 

while both tests in R2 eats nothing.

Pekr, not sure what you mean by two modes. I believe in Windows R3 
is using one method using the high-resolution timer using QueryPerformanceFrequency() 
-  http://msdn.microsoft.com/en-us/library/ms644905%28VS.85%29.aspx
Which should be more precise than R2 and it looks it  works OK.


The problem I see is why the CPU should be at 100% when I'm forcing 
the loop WAIT for 10ms which is plenty of free time. Isn't it?

Also I just tried to test under some prehistoric alpha prototype 
R3 versions and the 100% usage is there so I wonder noone noticed 
that so far :)

Gregg, yes in R2 it looks the resolution that can be measured under 
Windows is ~10ms and you start to burn your CPU at 100% when you 
WAIT 0.0001 which means in R2 the same as WAIT 0.

The principle is simple.

At startup, I build an event time!, the I push it in the block located 
at system/view/event-port/state.

And In my global event handler, each time I receive this event, I 
repush it immedialtly in the queue.

I receive 1000 time! events per seconds in My tests, but it mights 
depend of the speed of your UC

hmm, I pushed event into the event-port/state but nothing happened 
here. the event is still there and was not send to my global handler.

event-port: system/view/event-port: open event:// 
And then you added you handler at  port-event/awake
right  ?

Cyphre - do you understand, what Max wants? And for us dumb - would 
it be a benefit, to have "draw elements"? :-)

Maxim, with this system you can easily manage any draw element or 
group of draw elements inside draw block.

I have been thinking about this and I don't see any benefit being 
able to access the data at the level of internal AGG structure. Rather 
it looks like it would make the whole system more complex.

The only thing which could be useful is being able to 'cache' already 
parsed DRAW block. That change can be done without much complications. 
But I should also mention that the 'parsing phase' is very little 
part of the performance overhead so cahing the internal structure 
would be theoretically useful only for really big DRAW blocks with 
tens of thousands and more elements..but such big blocks would be 
still not much usable becuase of the final performance of the rasterizing/rendering 
phase in such case.

But I'm still open and I'd like to know your clarification and explanation 
of the benefits you see in your requested feature though.

AGG does a lot of computation, basically having access to this data 
in a consistent way.  also not having to use composed/reduced blocks 
all the time.


getting info like (x,y) coordinate of current bspline curve at length 
100 pixels from an end.  

getting intersections between complex shapes like splines and polygons, 
xformed.
bounding boxes of things, calculated points of displayed letters.


if there where a unified method which just keeps the persistent data 
and we can move it around/manipulate it without needing to store 
it as a block of dialect, I could build my own specific and much 
cleaned up dialects or graphic engines without needing to go through 
the draw dialect like I do know.


Myself, I have no use for most of the draw dialect, it just complicates 
my work, by getting in my way.

part of my plan... and why I haven't been to vocal about R3 view 
 ... I'm waiting to see how easy it will be to work on the new hostkit.

...also not having to use composed/reduced blocks all the time.


If you had look at the concept demo I posted above there is no sigle 
forced compose or reduce(ofcourse except the possible internal native 
parser processing) applied on the DRAW block using this method.


getting info like (x,y) coordinate of current bspline curve at length 
100 pixels from an end.  
getting intersections between complex shapes 
like splines and polygons, xformed.
bounding boxes of things, calculated 
points of displayed letters.


Agreed, being able te get calculated coordinates of bsplines was 
planned addition, though not yet implemented.

Not sure about the intersections. I think you would need to use external/third-party 
code for that.
Bounding boxes, yes that is/was also planned.

But these ale more like helper functions which doesn't need to have 
any 'draw elements' access. It's enough to provide whole/partial 
draw block to get proper results.


if there where a unified method which just keeps the persistent data...


The DRAW dialect block is the persistent data IMO. And you can build 
any other dialect/system over it.

Don't be fooled by the result you are seeing. The internal structure 
of the data is almost identical as described in the DRAW block but 
in different format.

All the calculations are done on-the-fly using diferent parts of 
the pipeline setup. For example:


coordinates(almost same as in DRAW definition)->curve_converter->trasformer->rasterizer->renderer


there is not any persistent storage between 'coordinates' and 'rasterize' 
phases (that would be memory overkill to store all the approximated 
curves etc.)..the result is directly rasterized on the fly.

So in fact there is no static 'list of vertices or whateve' of the 
resulted image, everything is dynamic from the time you pass your 
DRAW definition to the engine.


...and we can move it around/manipulate it without needing to store 
it as a block of dialect, I could build my own specific and much 
cleaned up dialects or graphic engines without needing to go through 
the draw dialect like I do know.
 

See the concept demo. I'm using one single DRAW block for all the 
objects and I can access/manipulate them without any complex code. 
There are no limits.


Myself, I have no use for most of the draw dialect, it just complicates 
my work, by getting in my way.


ok, so show me example of the form you would like to use for drawing. 
Is there any existing system which uses your expected behaviour?

Max - try to define simple usage case, and possible syntax, so that 
Cyphre can see, how your aproach differs, because it seems to me, 
that with few enhancements Cyphre outlined above, Cyphre thinks current 
implementation can already do what you are asking for ...

as I said, I will wait for the hostkit with view to be released before 
spending to much time on this... I really don't have time to go in 
depth with this... and I'm not even trying to convince anyone.  just 
replying to questions and I feel its being taken too seriously for 
now.   its possible, the better approach will be to have access to 
some of the AGG internals via the extensions and wrap these into 
generic objects, for example.


its still just an idea.  there is no point to going into details. 
 I need to see the view host kit first.

I think that Cyphre just tries to understand your aproach, nothing 
more, and that he is really open to any ideas ...

Maxim, no problem, I have not much time either now so feel free to 
clarify any time later.

I was just wondering what you are looking for to satisfy your needs.

And of course, you cannot request functionality of big complex 3D 
systems which are usually fat high-level layers over  low level graphics 
libraries.

You should think about the DRAW at the level of graphic library api, 
not application layer.

So I more awaited comparison with OpenGL, DIrectX, Cairo, Qt , Java2d 
 and so on. Anyway, I'm curious about your  examples....

Also I don't understand what is so wrong on using dialect as an interface 
when Rebol should be the case where working with blocks, dialects 
etc. should be a plus.

For example If you prefer interface based on function calls over 
dialect the I'd like to know what benefits you see in that approach 
etc.

Steeve, but were you succesfull to use this technique in real world 
case? I tried to use it for the DRAW demo but it doesn't work well.

Try: do http://www.rebol.cz/~cyphre/scripts/r3/tests/draw-shapes-2.r


-try to move mouse over the window..you should see quick 'MOVE'  
events  eing logged in the console

-if you select any object using the mouse the loop is starting to 
do something usefull and from that time I could get only about 3 
MOVE events per second which is very slow. To me it looks like the 
event port blocks during execution of the code inside the WAKE handler.

But if I use the same code inside FOREVER+WAIT cycle the events are 
comming much more frequently.

The problem with FOREVER+WAIT in R3 though is it eats up 100% of 
CPU time(as opposed in R2) and I don't know why. Probably a question 
for Carl.

if you slow done your frame rate at 10 or 15 fps and increase the 
wait duration at 0.04, it might not hang up the cpu but il will be 
too slow.

Meaning only one thing to my mind, Rebol' s drawing engine is too 
slow when drawings are huge (slow by design)

Nope, the 2 shows are necessary and in fact optimizes the whole thing 
because you don't need to refresh whle screen everytime...better 
two smaller shows than one fullscreen redraw in this case.


The problem I was refering is not about performance..it is about 
blocking when executing longer code from AWAKE handler. I think this 
method is not usable.

When I run it using the forever+wait loop it works without problem 
at constant 28 fps here even if I wait for 10 miliseconds during 
each refresh. I only don't understand why 10ms is not enough to let 
cpu service the rest of system. Imo in R3 the CPU is not knowing 
about the wait/idle state from some reeason.

Well, i didn't say to refresh the whole screen but only one composed 
gob (and to discard the callings to draw).

The demo is about  thechnique where you can manage DRAW only objects 
in one gob so if I split the content to multiple gobs and compose 
them  it would ruin the whole concept.

But are you sure your technic (of calling the draw function and then 
to show the image-gobs )is faster than letting the draw engine doing 
the whole job with one show?

so the clipping is done at rendering level and also at blitting level. 
While if you do a show on one big gob with draw you are rendering/bliting 
everything.

(Using time events)

Cyphre, By reducing the number of objets to draw (10 objects) I have 
a really smouth animation taking less than 2% of UC when an object 
is rotating, and growing to 20% maximum when the object is actually 
moving.
Meaning your clipping technic has a  low effect on perfs.

and with 50 objects, i have 30% to 50% CPU usage.
Time events are not so bad.

http://sites.google.com/site/rebolish/test-1/draw-shapes-22.r

Steeve,

clipping: I disagree here,you cannot compare the clipping effect 
by increasing/reducing number of renedered objects. The only valid 
test is to to compare rendering of same number of objects with and 
without the clipping being enabled. Note that the perfomance slowdown 
you are reporting when adding more objects doesn't have to be related 
to clipping.


regarding your new version..sorry, I'm still not convinced. It looks 
to me you just replicated the same busy loop as when I use FOREVER+WAIT 
technique. You are simulating kind of 'wait' using the tick skipping 
but the result is same when looking at the CPU usage.

I still wonder why we need to 'wait' too much in R3 unless CPU load 
starts dropping down.

When I have time,I'll try to create some test script which can be 
indentically used in R2 and R3 to see if there is really any difference.

Steeve: a busy loop means that the CPU is busy looping. That is what 
happens in your example. There is no "sleep" time between time events. 
That is not true with actual time events, which fire at a defined 
interval, and allow the CPU to sleep between them.

And, it's possible there's a bug. See last line of:
>> dt [loop 10 [wait 0.1]]
== 0:00:01.000138
>> dt [loop 100 [wait 0.01]]
== 0:00:01.000423
>> dt [loop 1000 [wait 0.001]]
== 0:00:01.003355
>> dt [loop 10000 [wait 0.0001]]
== 0:00:00.01414  <-- wrong

BTW, the relevant code is host-device.c, line 406 and below.

*/	REBINT OS_Wait(REBCNT millisec, REBCNT res)
/*
**		Check if devices need attention, and if not, then wait.
**		The wait can be interrupted by a GUI event, otherwise
**		the timeout will wake it.

Robert and I are discussing field persistence, i.e. tieing fields 
directly to database tables in a layout. Going to be a bit about 
our conclusions in the R3 GUI specs soon.

The question is: How to get from GUI to a DB and back without cluttering 
the VID code, or having to code to much. The idea is to collect the 
GUI elements belonging to one record and than auto-create tables 
and columns. So, people can concentrate on the app code and get the 
75% always necessary database code for free.

Not perfect as is, and perhaps simplistic, but I could imagine finding 
a way to add more semantic hooks to a layout and have a somewhat 
automated way to set/retrieve data from parts or all of the gui...

i think the syntax of the data block to get/set the GUI and get/set 
the DB should be the same.
>>get-face pan
== [foo: "foo" bar: "bar"]
>>set-face pan [foo: "bar" bar: "foo" ]

>> get-db [foo: "bar" bar: "foo"]

== [foo: "bar" bar: "babar"]   ;the DB can decipher the data block 
and knows well what is the requested key and what is only attribute.

>>set-db [foo: "foofoo" bar: "..."] ; update the record or create 
a new one.


Having exactling the same syntax allow to pass data between the GUI 
and the DB without pain.

Henrik: Do you also tie validation and multiple data sources to each 
binding?  I kind of like the independence of a data model co-existing 
with a layout structure, you can poke and prod data from outside 
while the view internals just get on with what they do...

Steeve, the purpose is allowing different scoping per field. According 
to Robert, he sometimes needs to use a field from a different table. 
Of course it would have to be possible to cover what you need with 
the outmost panel and then having fields inside it be covered by 
what the parent record specification gives.

Something more to consider...

dynamic: group 1 [field field field] record [table1]


For when you want to set up fields where you know the order, and 
really want to minimize the layout code.


The outer panel would be set up with an ON-EMIT actor that traverses 
the inner faces. We already have this in the prototype, so maybe 
we can map the traverse order to the table columns.

About the earlier mention of GET-FACE and SET-FACE, these are considered 
basic accessors to manipulate the fields and gather data from them. 
These aren't going away. The use of ON-EMIT specifies directly to 
use GET-FACE to obtain data from the face, so it's not some kind 
of "special accessor" that somehow replaces GET-FACE. The job of 
ON-EMIT is to copy the data, formally obtained from the field to 
the database record cell.

And one note of unexperienced coder (me) :-) - when I tried to look 
into that RoR db system, it reminded me of DOS app generator tools 
I used for Clipper language. While it was cool, it was also kind 
of limited. I mean - it always end like - if you need something more 
fancy, you have to use raw aproach. And it introduced unnecessary 
layer, which you had to learn, and which was not able to provide 
you with general enough functionality for 100% cases. This is just 
a note to keep it in mind, nothing more - simply to not introduce 
another layer, if we are not sure, it will be usable for 90% of cases 
and has some benefits ...

design is not finalized, but yes, the extension is a single actor, 
ON-EMIT (there might be more), a single reactor, RECORD and that's 
it.

In DOS era, when I coded in Clipper, MS Fox Pro introduced so called 
"scatter", "gather". Every language (Clipper, Visual Objects, Delphi) 
then copied naming and the principle ... to get and set values from 
form ...

this doesn't have anything to do with those functions. :-) if you 
didn't have an actor to handle things like EMIT, you would have to 
write special db handling code up against GET-FACE and do a lot of 
silly wiring, like is necessary with VID.

dunno how to get it into dialect, but you need all of those. And 
I forgot ... validate

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

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

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.

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.

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

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?

I used Genifer for dBase and Clipper

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.

tabs: we already are able to switch between panels and need a button 
panel for doing this.
grid: big job and cyphre has already volunteered. :-)

btw - docs are geting better and better. Draw and Shape docs were 
added recently. Gobs too ...

This is quite this kind of nonsense I thought we could avoid :-) 
You simply often might find the case, where it will not fit your 
situation, and then docs say - you can't do everything, using the 
concept. So then you are left with some usefull, but not-in-100%-cases 
usefull case, and between the raw solution. IIRC Chis has similar 
solution with his system? I don't remember the name .... however 
- this does not belong in the GUI group, and this is exactly where 
I thought your form  abstraction aproach will lead you :-)

I didn't think that it wouldn't work, since this is inside the dialect 
and so the path shouldn't be evaluated.

Does this system caches data somewhere before updating the record(s) 
or data is immediately written on the record field ?

When an user edit a file it must be checked for proper input

When multiple fields are edited they may have a relationship on consistency 
and there is a mutual validation

When you save the recordset  there could be errors on writing and 
the whole transaction need to be discarded instead of being partly 
written.

P: Validation ('import) and Active Record (RoughCut) are essential 
components of QM.  Validation (along the lines of 'import) could 
easily be part of a panel/layout's specification...

Henrik - what was last status of resizing? Carl admitted, that resizing 
is broken. But I do remember some discussions about using different 
model to Carl's choosen one. And btw - is 'max-size requirement still 
there?

So we can start using R3-GUI and expect minor changes to use and 
implimentation?


I thought there was going to be some major changes yet to come and 
present functionality might change significantly...

and the flames are dancing :)

and it takes some 3-6% CPU here ...

those gui elements are live and functioning ...

I use it like that:
>> capture gob [pen stroke-color]
which means:

if the gob has a [pen color!] in its draw block, then the var stroke-color 
is intiated with it.

And the [pen stroke-color] replace the initial sequence or if not 
found, add it in the draw block.

I use this to merge effects with existing draw blocks (it's called 
by the constructor of each animation).

It's up to you to merge the effects with inner gobs if the style 
got many.


The VID, I build, doesn't matter if the style contains several gobs.
Thanks to my propagation model of events.

I use the same idea than R2, events are propagated from inner gobs 
to outer gobs, so that i can have only one reactor on a parent gob 
(the container) which trigger the same actions on all its inner gobs.

It's the thing i don't like in the current VID and it's why styles 
can't deal easly with several children gobs to my mind.

I use this to merge effects with existing draw blocks (it's called 
by the constructor of each animation).

It's up to you to merge the effects with inner gobs if the style 
got many.


The VID, I build, doesn't matter if the style contains several gobs.
Thanks to my propagation model of events.

I use the same idea than R2, events are propagated from inner gobs 
to outer gobs, so that i can have only one reactor on a parent gob 
(the container) which trigger the same actions on all its inner gobs.

It's the thing i don't like in the current VID and it's why styles 
can't deal easly with several children gobs to my mind.

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