World: r3wp

yes but the corner is not *ON* the line, its equal to the major and 
minor axis of the elipse.

if I where to drag one of those points to an angle of 30 degres, 
I still want the arc to touch my point.

Yup, but you can't make just one ellipse with center and point on 
the ellipse.

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.

:-) Think of my example with center and point horizontal out from 
the center. What height should your ellipse  be?

The problem is not, that it's hard. It's impossible.

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)

Ah, I now think, I understand, what you want. It's like the arc drawing 
routine, where you want the point to be on the line. Same thing with 
ellipse.

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.