AltME groups: search

a long time ago. the problems where that it was missing some things 
like opt support in show-popup and some other thing.  and the show-popup 
selection of feels didn't make it very predictable.


with my custom wake-event/window-feel pair, it just went haywire. 
 so I rewrote both so that they would work better within glayout's 
revised management of view layer.


for example in glayout... the view function has a /modal   and a 
 /center  refinements... these make many things much simpler to use... 
I rarely use show-popup within the app, cause the glayout's view 
command supports it directly.

start a desktop, go to Sites/Cyphre ... there is vconsole script 
...

anyone know a way to trigger event code at a rate faster than 15 
times a second within a view wait?... the view rate is REALLY imprecise 
and doesn't go above 15 ticks a second in my tests. 


strangely  this has nothing to do with possible refresh rate which 
can bo well beyond 15 frames a second.

right now I'm testing a forever loop ...

right now asking for a rate is always about 66-75% off, even using 
wait 1 / 30 or 1/100 will consistently be off by a window of 66% 
to 75%

its funny cause if I do a timed wait 0, I go up to over 100000 iterations 
a second.

he can but it's a design limit.

the rate you enter on a face is not taken in account. 
Time events are always throwed at the same rate.

Then there is some internal counter for each face which have a rate 
value, to know when the time events must be dispatched to them.
I don't know if i'm clear...

but beyond 5 / second, is progressively gets off by the above percentages. 
 up to a maximum of 15/s when you put it at 24

but I am now building a precise timed function which is taking 1% 
cpu and can go up to  60 frames/second consistently.

wrong, it can be, but you must do a refresh on the face, after changing 
his rate

What i mean, is that, there is 2 rates.

One for the inner event handler which is always the same (the limit 
you pointed 15 ev/sec)
And the rate of the face, wich is basically a counter

this might have been fixed in a later view, cause it didn't update 
before.

So even if you fix a low rate 1 ev/minutes on a face, The time events 
continue to be send at a rate of 15 ev/sec in the inner event handler.
It can be the reason why it consumes so much time

seems the lack of resolution from the /precise flag is the source 
of the offset in what you ask and what you get.  I bet on a linux 
box, it would be much more precise.

Max rate of 15/s sounds a bit low to me. When I was on WinXP it was 
48/s maximum rate.

if I put rate at or anything above 30 I only ever get 15, and when 
I do tests with my more precise timing function it seems that by 
using wait 0.001 I can go  at 65 frames / second.  


ironicaly, rounding and IEEE math errors give me the same 66% - 75% 
offset between desired rate and actual rate... seems I'm using the 
same algorythm than REBOL internally.

this is on a winxp with 1.5GHz core2 duo.

I have a strange reaction in some AGG code...  calling show on the 
face is actually appending the new AGG drawing to previous such that 
the image is the result of all prior draws... but the draw stroke 
(verified) isn't growing!


anyone know what is causing this... AFAFIK I am not using the draw 
command, but setting the face/effect and calling to-image on the 
face.

how do I get the x,y coordinate on the curve from a spline I draw 
with AGG?

you're starting from some points i guess, and you want to construct 
a smouth curve with them...

ok, i give you a hint

i download a script wait...

the most common know function (i guess) to interpolate 2 points is 
to use this cosine function.

(1 - cosine a * 180) / 2

a is a value between 0,1

I was asking, cause I saw a demo once of someone rebuilding the AGG 
spline manually right over the AGG one.. so some code definitely 
exists.

Giving 2 points as input , i can write it if you want, but give me 
the paremeters you want and the result expected (an image, a block 
of coordinates ?).
Give the specs

We wrote our own spline (arc function for a Paint program we did). 
 

DPaint had this, which implies John's RPaint has this code too, no?

ho i see, your input is a length and you want the coordinates in 
return ?

The nice thing is that it works backwards, which is, you give it 
XY, and a control point, and it draws thorugh the control point.

Of note, if you want another way to think of an arc.

Think of drawing 3 points A B C (C is the "pull")

Now, you have what looks like a triangle.


If you make a tic halfway between A and C, and B and C, and draw 
a line been these tics, then keep doing this, you will eventually 
make an Arc.

The last tic is where your Mouse cursor would end up.

That is why Arc in RPaint is "backwards".

Cool, eh?

now I have a real math problem... I didn't even find a direct solution 
on wolfram mathematica site.


do you know of an algorythm (expressed in code, not in math) that 
can give me the ellipse with two supplied coordinates.
center and one point which touches the ellipse?

Maxim, probably not, since you need to first find an example in a 
real program that uses that UI.  Perhaps GIMP though?

My paint program let you draw a start point, and drag a line in some 
direction, then show an ellipse on that "angle".

Then, you could size the width and length, in real time, then when 
you released the mouse it snapped perfect....it was VERY fast, and 
very cool.

We too had to correct "to a pixel"

basically, two points reside on the major and minor axis and a reference 
center is used.  if rotation is needed, I can easily calculate the 
vector from any of the axis to the center.

but right now the rotation is locked, cause I'm not sure its a good 
thing to rotate the ellipse for this specific application.

A REBOL Bezier algorithm:

do http://www.fys.ku.dk/~niclasen/rebol/fysik/bezier.r

Move the points around with the mouse.

first use will be to build a keyframe editor, which will be distributed 
with liquid-paint, with MIT license.

thanks! for the spline code, with a few changes, one in three points 
should pass directly through the point and the two other points will 
be used as tangeants.

its not really obvious... I'm not a math expert, even if I've done 
some pretty cool 3D engines (crowd simulation, for example) it takes 
me a lot of time to get the math part of things done when its question 
of doing math mix and match.

Let's say, you have center and a point with same y-coordinate as 
center. So it's just horizontal out from the center. Now the ellipse 
can be any height, so you can make infinite many ellipses with those 
two points.

I did whole evening of research on the ellipse and didn't find a 
single exact procedure to do it... some math dr have done their thesis 
just on finding ways to calculate its arc len ! 


though I think its possible to resolve the two foci based on the 
angle and distance of the point we want to pass through the arc, 
all the math needed to get to the proper major and minor axis (eventually 
equating to what people call the x and y radius) is pretty intensive.

there is definitely a way to calculate it mathematically, but there 
are so many steps, I get lost in the procedure to get to it.

in that case, its can be treated as a special case... like a like 
since one of the axis is = 0  just like the up vector of a 3d object 
cannot be (0,0,0)

for an arc drawing its a bit simpler, since by using three points, 
you actually get points directly on the line.

the funny part is that my vectorial app lets me try it out just like 
yours, but I didn't get to that point in my head.  well, it was a 
nice dream while it lasted  ;-)

I really like the look of the tool selection is it just a button 
rotated 180 degres?

The selection effect is not just a button rotated 180, but took some 
drawing. :-)

Is there a way to dynamically turn a field into info and back again 
... so to prevent users from editing various fields on an as required 
basis?

Hope VID+ has a way to dynamically disable/ghost out widgets ....

Oldes/graham


here is a complete application which shows you how to build and affect 
a face with a ghost effect.

----------------------------------
rebol []

ghost-blk: [
	ghost-data: none
	
	ghost: func [][
		self/ghost-data: make self []
		self/image: img: to-image self
		effect: [ merge grayscale contrast -50 ]
		;size: img/size
		edge: text: feel: pane: none
		show self
	]
	
	regenerate: func [/local attr][
		foreach attr [image effect feel edge text feel pane][
			set in self attr get in ghost-data attr
		]
		ghost-data: none
		show self
	]
]

stylize/master compose/only [
	field: field with ghost-blk
	button: button with ghost-blk
	btn: btn with ghost-blk
	scroller: scroller with  ghost-blk
]

view layout [
	across

 toggle "btn" [either face/data [my-btn/ghost][my-btn/regenerate]]	

 toggle "button" [either face/data [my-button/ghost][my-button/regenerate]]	

 toggle "field" [either face/data [my-field/ghost][my-field/regenerate]]

 toggle "scroller" [either face/data [my-scroller/ghost][my-scroller/regenerate]]
	return
	my-btn: btn "yippe"
	my-button: button "ka"
	my-field: field "yay"
	my-scroller: scroller 100x20
]

anyone know of an official way to push a rebol view window back on 
top of all windows on the display?

right now I am closing windows and reopening them... but if a pop-up 
is displayed, I'm getting strange results.

but I can't seem to get the rebol window's in front of other application 
windows...  I'll try using hide/show...


 I'm thinking there was a view option that allowed us to tell the 
 engine that any show on a window would force it back to the top.. 
 but its sooo far away in my memory, I might be in error.

this is an advanced question for View master:

as very few know, there is an easy way to get pretty fast face scrolling 
in View, and that is by using the changes attribute of a face.


this works fine in my scrollpanes and such.. but when I use it on 
a window face, it corrupts the window content.
I have to use show twice, which actually is pointless.

yes biut then it redraws the gui so its really slow.


I finally cornered it unfortunately this is a work around to a bug, 
and it slows down the process.


basically, you need to set the old-offset so its totally beyond the 
size of your window at current offset, this way, the redraw func 
doesn't try to reuse the saved area (it should have to since its 
a window, and its offset isnt affecting the display).  the draw back 
is that it has to reblit all the window, but it still doesn't have 
to redraw it, so its still faster than not using changes at all, 
the bigger the more complex the window, the bigger the gain.  but 
large windows will be affected by the slowness of view blitting.

the parent-face is set on a call to show.  AFAIK.  the reason is 
simple, when you build your layout, you can potentially change the 
face you put the layout into before showing it.

I normally have a different solution for setting parent-face on any 
layout before SHOW, but it still happens some time after LAYOUT. 
I wanted it to be set earlier here, as an inspiration from VID3.4, 
where you can find a previous face during initialization, such as 
to attach a scroller to a panel without having the user needing to 
specify it directly in the layout.


I made some changes to LAYOUT, added a refinement to specify which 
parent-face exists for the pane. This is possible, because LAYOUT 
is not recursive and is called whenever one pane needs to be laid 
out. The idea was then to set parent-face before INIT.


This worked well for faces that are not at the base level for the 
window, but how do you specify the parent-face for base level faces, 
as the window face does not yet exist? I have dropped the idea again, 
because the solution is too convoluted. Besides it wouldn't be possible 
to attach to faces that come after the scroller, so you have exceptions, 
which is not good.


Scroller attachment now happens on first use of the scroller instead.

Glayout is a complete system though... its hard to take things out 
since its takes charge of VID and expects all of it to be there. 
 the layout depends on the api, which depends on the few patches, 
etc.

but it still use the normal VID stylesheet for example for changing 
your styles... I like to see it like an invisible drop-in for VId 
which replace the layout engine and adds A LOT of needed functionality.

Glayout has been updated a few times... I really should update the 
version on rebol.org.   a few little layout tweaks and many new features 
added since that version...

good idea. I have a hard time finding it via google.

but my current version has a display bug in the button looks when 
pressed... I keep changing the looks for every application, so it 
doesn't get fixed in the main lib.

A quick search on "rebol glayout" reveals the rebol.org version, 
the docs for REBOL's own LAYOUT and some mailing list posts about 
glayout.

There is a single link to STEEL which gives me a 404.

which is why it hasn't  been updated for a while.  the one on rebol.org 
is the last official release.

Anton, I think I tried that, but that screws up other things: Parent-face 
in LAYOUT is set to none for some reason, and I'm betting it's because 
VIEW does something here. Anyhow, setting parent-face separately 
works perfectly, so I'm keeping that for a while.

Maxim, does glayout.r contain a complete style set or is it separate?

it includes many of the basic VID styles as default...   near the 
end of the file, you will will see a big style block.  which basically 
adds the glayout framework on top of the previous master VID stylesheet.

Henrik, oh well. But I figured out a clever hack you can place in 
init to set parent-face.

Henrik, what strategy are you using?

I was thinking you could redefine layout, since you have collected 
a fair few GUI functions and styles together. When it comes down 
to it, it layout doesn't do what you want, redefine it. (And I am 
guilty of not doing this for so many years too.)

Anton, I've not had the energy to take a look at what can be changed 
with LAYOUT, so what I do is try to stay within reasonable limits 
of what it can do and stay away from radical changes.


One thing to change, if it were, would be that INIT would be less 
limited, if it was run as a separate pass after initial layout instead 
of right when the face is created, but this may cause problems for 
styles that use INIT to alter the size and offset for the face, as 
well as produce subfaces that need to be initialized first. Also 
LAYOUT is not recursive and INIT may be run at very different times. 
At this time, INIT is limited, but you have a pretty good idea of 
when it's run.


In VID3.4 this is not a problem, since there is both an init and 
post-init action possible, so if I were to get rid of this problem 
in the right way, I might end up rewriting over 100 kb of well-functioning 
code.

Hmm.. well why not add a post-init to layout ? This would not affect 
any existing code, so you could migrate to it at your leisure.

well why not add a post-init to layout

 you can't add it to layout. it has to be done after all layout is 
 done.

Has anyone written a tree based object browser ?  Anamonitor is the 
only object browser I know of ...

I was actually thinking about writing an object browser, but not 
directly a tree-based one.

is there a way around having to focus a face in order to use the 
scroll wheel above it?

Graham, a generic object browser should not be limited to hierarchic 
tree structure. Will you have any circular references?

Basically, I make an event handling function, called 'scroll-wheel-handler, 
open a window, then

	insert-event-func :scroll-wheel-handler
	do-events
	remove-event-func :scroll-wheel-handler

The event handler captures scroll-wheel events, looks where the mouse 
is, finds the face which it is over (a recursive function), determines 
if it is scrollable, and sends the scroll-wheel events to the that 
face's engage, just as if it had been focused.

Graham, I worked on one a long time ago, with Ammon Johnson. We did 
it like Smalltalk, or the OS X Finder, rather than a tree.

I made something quite similar recently; an expanding/collapsing 
dir-tree viewer, like the dir panel of a file browser. Each directory/file 
has to be an object, because I store some state along with it, like 
collapsed/expanded, and other interesting attributes can be stored 
in there in future, when I get around to collecting the info. The 
purpose of the app is basically to create an image of a directory 
structure, which can be saved to disk, viewed magnified etc. to give 
an overview of directory structure.

Actually, I think the real answer to your question is "yes", because 
I build a block/object structure, and I modify parts of it (the objects) 
to manage my additional states.

I think what you have in your situation, with objects built from 
XML, is different than mine. I take advantage of being able to use 
blocks in my structure which allows me to insert my additional associated 
info. With your object hierarchy, it's problematic to add your own 
extra fields for state because the XML, of course, might already 
have those field names as part of its data, so there's possibility 
for collision there.

However, (as I see in my notes,) I was strongly considering for my 
purposes a structure like this:
		file-structure: [
			%OHS/ [
				%adir/ [
				]
				%afile
			]
		]
		associated-file-info: [
			%OHS/ make object! [...]
			%OHS/adir/ make object! [...]
			%OHS/afile make object! [...]
		]

(with duplication of all the paths as a negative consequence), but 
this idea could work better with XML objects.

Anton, have you studied what POP-DETECT in SYSTEM/VIEW/WAKE-EVENT 
is about? The function for it exists in SYSTEM/VIEW/POP-FACE/FEEL. 
To me it looks like a workaround to get DETECT to work in INFORMs.

ah, that's right. I wonder then if that's what is causing problems 
with SIZE-TEXT for a specific face I'm making. SIZE-TEXT consistently 
returns pixel sizes that only fit if the font size is around 10 or 
11.

When reading through the View Reference, it's not clear what happens, 
when you return an integer from the iteration function. I can see 
the iteration function is run again with that value as input, but 
I can't tell where it's run. I had hoped to redraw single lines in 
a list with a simple mouse over, but I guess you need to do something 
unknown to provoke the redraw.
Using SHOW in the function causes an infinite loop.

The answer to all these kinds of questions/problems with iterated 
pane functions, I, and beforehand others like Romano and Gabriele, 
discovered, after much investigation, is not to use a pane function 
at all, but instead, make real faces in your window and manage them 
yourself. It turns out to be simpler and easier to code, and with 
events, it is more powerful, reliable and has fewer limitations etc.

So... the pane function may be interesting to investigate, but you 
may also just waste a lot of your time.

Anton, yeah, I might drop it, although I figured out a solution to 
that problem there are many other problems. However right now I'm 
investigating SHOW-POPUP and HIDE-POPUP, trying to see if I can control 
many popups for a menu system.

trying to figure out now when exactly it is that View displays a 
button for the window in the task bar and when it doesn't.

I purchased the Rebol-Command and am trying to integrate it with 
my existing work.  The 'Local' folder is pointing to 'c:\documents 
and settings\blah\blah....   My old version was pointing to c:\rebol\local 
 thats where I want it to point.  Is there a way to force it there? 
 TIA

Analyse:
Put this in your  user.r  file:

	print ["system/options/home:" mold system/options/home]

A probable fix for you (insert into user.r):

	system/options/home: %/c/rebol/

Thank you.  After a rest and some more digging I found a few ways 
to fix.  The most obvious - which I overlooked - was a prompt during 
the installation.   I like everything in one root folder.  Much easier 
to sync between home/work/laptop etc.  Just to be extra safe, I added 
the code you proposed.  Thanks again.

Actually, I only set system/options/home in my user.r because I'm 
on linux which doesn't have a registry.

On Windows, you can find the registry key which sets system/options/home 
by searching for "rebol" in the registry. (I don't remember what 
it is exactly, but it's easy to find.)

I think, you can preseve transparent by making a separate image from 
the alpha channel, resizing rgb and alpha separately and combine 
them in the end to a final image.

(If it's a problem otherwize.)

It it just a matter of a recompile for that processor and OS?

Does anyone know how to set the selected rows programatically within 
a text-list?