World: r3wp

but if x and y axis aren't = 0  then the angle of the point, can 
let you calculate the two foci, which are relation to x/y.

yep.

And you don't want the ellipse rotated at first?

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

yep. rotation I can deal separately, using an actual separate rotation 
value

(after)

re-reading... my answer is ambiguous....  


I mean that I don't need rotation as part of the arc on point algorythm.

do you think you can pull it off?

I'm still not convinced, it can be done. That there is only one solution. 
Try Canvas RPaint:

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


And draw two points. Then start an ellipse in one point. Can you 
see, you can make infinite many ellipses going through the other 
point?

Even if they're not rotated. You need to put some restrictions on 
your ellipse to only have one solution.

its funny, yep... now that I try doing it interactively, I realise, 
that you must know 2 out of 3 values to resolve an ellipse...

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

btw, rpaint is really nice.

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

LOL "workbench" in the menu...

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

it really is perfect. probably some of the most polished rebol GUI 
work I've seen so far.

Thanks! :-)

I agree, that's very good and high quality work. Nice tribute to 
the Amiga.

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

Switch out 'feel objects and visual facets, unfocus, then 'show? 
 (trying to recall if that's right...)

should be easier!

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
]

Very nice Max

you can easily adapt this for rebgui by simply replacing the feel 
related code above by whatever rebgui uses.

thanks.

wrote this in 5 minutes... I always wonder why people complain about 
VID . its very easy to manipulate and control.

sure :)

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.

I think I remember being able to change the order of faces in system/view/screen-face/pane 
to do that

not certain, though

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.

aaahhh found it... when you open the window... you specify the activate-on-show 
option   :-D

thanks for that one

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.

anyone know how to prevent view from corrupting the window face when 
I use 

window/offset: new-offset
window/changes: 'offset
show window

did you try without setting changes?

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.

I want to use parent-face correctly during INIT, instead of having 
it set during VIEW. I know that INIT is run during layout, but there 
may not be enough information available to correctly specify parent-face 
at that point. Has anyone worked on this?

My first retort is "of course there is!" (enough information for 
layout to set parent-face). Layout first makes the panel face it 
will return, referred to by 'new-face, near the beginning of its 
code body. It subsequently populates the pane of new-face with new 
subfaces built from the spec block. At this time, layout has the 
great opportunity to set parent-face for each one, but it doesn't. 
So, there exists the possibility for us to patch layout to do so.

The patch will be small, but of course, complicated to figure out.

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.

you can include it within the with block facet if you know it at 
that time.  init is called after the layout is done (all calls to 
facet words and multi are done).

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 solves all of that  ;-) and its all running over VID and 
does very few hacks...

really, you should look into glayout, you are the kind of user which 
would "get" it very quickly and you'd be very happy about it.

your advanced styles work in glayout... I've converted the toolbar 
in 15 minutes last time I tried...

I'll see what can be used, thanks.