AltME groups: search

Gabriele, that was my question too.  Currently If you have 'busy 
loop', no matter what technique you are using, you need to 'idle' 
at some point to give CPU some free time. Currently I don't know 
of a way how to do it in R3 as the CPU is getting high even on very 
long(in terms of CPU time) idle delays.

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

Steeve: what you are doing there is called a "busy loop".

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.

but within REBOL, so you can create a bspline by adding some some 
sort of object in a list of visible graphic elements which have properties.

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

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.

Gabriele, i don't think so. (regarding the definition on wikipedia).
Actually, I used a technic very similar to what's done in R2.

In R2 the event engine throw tons of time events aswell. But the 
filtering (regarding which face as a rate property) is automatic 
(more or less).

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.

Henrik, in your last try, if you skip some time events  then the 
animation slow down but it's eating only 50% of my cpu (a small celeron).

tick: 0
...
handler: func [event] [
	switch event/type [
		time [
			++ tick
			if all [picked-obj tick > 30] [ 
				tick: 0
...

Rebol is slow for such animations

Moreover, you're using the graphic engine quite intensivly.
For each refresh:
-  2 calls to the draw the function + 2 shows


Maybe only one show of a composed gob (without the need to call draw 
seperatly) would increase the perfs.

but it's true that time events will not be faster than a forever 
loop.
It was already true with R2

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.

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.

replacing a wait with a counter... oh well... :)

Gabriele, you can't be more wrong. There is obviously sleep times 
in my example.

I reported that the CPU usage is variyng a lot depending what time 
events are triggering. There's no need to argue again facts. Obviously, 
less CPU usage means the CPU is sleeping somewhere.

Henrik, same argument, It's not a busy loop. Have you Guys tested 
or not ?

It is still a very silly way to do what Cyphre is doing, more consistently, 
by just using a FOREVER loop with WAIT.

It looks like this discussion evolved a lot.  Let me know if there 
is a question I can answer about it.

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

This might be related to the timing resolution change we made a few 
versions ago.

In other words, there's no reason it should't be.  Also, we know 
the code has a few problems on non-windows boxes.

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.

If you have any ideas, hints let us know.


We have a first prototype running, but we want to make it more elegant.

The way that accessors on panels work in R2 is a good start (almost):

	>> lay: layout [pan: panel [foo: field "Foo" bar: field "Bar"]]
	>> set-face pan ["Bar" "Foo"]
	>> get-face foo
	== "Bar"
	>> get-face pan
	== [foo: "Foobar" bar: "Barfoo"]

Tie that to validation, eg:

	import get-face pan [foo: string! [some char] bar: opt string!]

Or an active record:

	record/update get-face pan

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

Especially recognising that the layout structure may not represent 
the application data structures.  I've toyed with the idea of a 'ref 
keyword - ui: layout [field ref 'user/name] - ui/get 'user/name, 
ui/set 'user/name, ui/get 'user == [name ...]

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.

Hmm... Ok

Henik, I'm not sure of the interest to add record specifications 
on each field. a simple record tied with the panel should be enough.

E.g with your example:

 name-panel: group 2 [
   label "ID"   id: field 
   label "Name"   name: field
   label "Address" address: field 
   label "Post Code"  postcode: field 
   label "Comment" comment: area 

 ] record name-table [name: key Address:  postocode: comment: data]

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.

Henrik i see, but there should be the less possible specifications 
of the DB inside the styles themself.


Each panel should only (see) a flat VIEW of its tied tables (more 
easy to manage). 

Then each VIEW (like in SQL) could have a shema specification (somewhere 
else in the code) which desrcibes all the referential constraints 
between tables of the DB.

A bare-bones version would be something like:

group 1 [
	value1: field
	value2: field
	value3: field
] record [table1]


which could serve most needs. Wouldn't that be the same as tying 
fields directly to a flat table?

Chris, the storage would require a "save to table" action. It wouldn't 
save as soon as you tab out of the field, so validation is fully 
possible.

It may not be a great idea. There are some possiblitiies for screwing 
the emit process up.

We'll be building another prototype. The current one works against 
SQLite, but the next one should be built so that we can demonstrate 
that the layout shouldn't care about which db it's connected to, 
so we'll also make a flat file database version.

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.

well, the concept is not clean anyway, just dunno. We have get-face, 
set-face. For me, panel is a face too, it just contain subfaces. 
I really don't know, why panels are treated in specific way - we 
already got get-panel, set-panel, clear-panel.

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.

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.

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.

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

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

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

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

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.

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.

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.

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.

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.

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

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.

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?

You still use a single draw block, although you can switch between 
different draw blocks for one GOB. One thing I don't want, as a style 
writer, is also to have to manage the GOBs as well. That makes it 
significantly more difficult to write styles, but I suppose there 
will be special styles coming around where you can use dialects like 
MAKE-GOB to freely define what's inside that style.

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

Has anyone taken a look at Active Records? It looks quite interesting.

http://ar.rubyonrails.org/

To carl concerning the timing problems noticed on my computer i got 
those result (windows seven; CPU core i 5 750, DRR3 1333 Mhz; R3 
a 97)

>> dt [loop 10 [wait 0.0001]]
== 0:00:00.000016

>> dt [loop 100 [wait 0.0001]]
== 0:00:00.000084

>> dt [loop 1000 [wait 0.0001]]
== 0:00:00.000783

>> dt [loop 10000 [wait 0.0001]]
== 0:00:00.007763


As you can see on my coputer my timings are lower than expected so 
sthis issue is related to CPU horse power.

I'll go with Carl's conclusion: It's a bug.

hmm... when writing a reactor, you can specify any-type! as an argument, 
but GUI parsing halts when encountering a path! for that argument. 
Does anyone know if this is a DELECT thing?

Henrik, I admit I have not read the whole discussion but I have a 
question:

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.

validation is not a part of the UI yet, but it will be.

the idea is simply not to submit the data until the form is validated. 
I've not decided yet, but validation could be a reactor, the way 
things are shaping up right now.

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

Ok Henrik, please do not forget a "record modified" trigger for the 
UI. In multiuser enviromnent it is really useful to know if the record 
has been modified by someone else.

screenshots: not really anything interesting. it's the same as before, 
only I'm working on how to error handle reactors. some reactors, 
I think, should be handled in a more friendly way than currently 
(simply crash).

we change one thing at a time.

last I read them a couple of days ago there were some inaccuracies 
compared to Carl's version, so I don't know if he's doing any of 
his own changes.

but general concepts like actors, reactors, faces, styles, etc. shouldn't 
change. it's smaller details that are a little different, like function 
names.

i optimized it a litlle bit (removed the "change copy/part image" 
that eats memory)

instead of just hard coding those, I'd rather build a scheme to perform 
automatic shape/size/color/transparency transitions.

as you can see at the end of presentation.r script, Jeff Kreiss built 
a nice dialect. Reminds me of Scala script ...

i try something like this in my VID, i have a scheme named animator 
(basically a collection of animations, plugable in styles)

so i created a function CAPTURE

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.

A small question: I am reading the GUI documentation. Are concepts 
exposed going to change since the resuming of developments ?

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.

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

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.

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?

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

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

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.

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

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.

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.

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