AltME groups: search

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.

well i've done some smouth functions to interpolates coordinates, 
but i don't know if it's your need.
What is your input and what output are you expecting ?

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

all the algorythms are available on the web via siggraph and other 
sources, but coding that stuff usually isn't very fun.

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

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?

ok, so I should bother john for his function... he probably profiled 
it and such... I'm just lazy.

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?

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.

some graphic app I'm writting ;-) does the ellipse dragging in real 
time, but uses x-radius and y-radius which is snapped to the edge 
of the ellipse... 


I just prefer single point editing... but for that to be intuitive, 
the point really has to be exactly on the ellipse... and since ellipse 
have 2 center points... ellipse seem to be very complex challenge, 
by what I've read, there isn't even today an exact method to calculate 
the arclen of an ellipse... only very close approximations!

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.

and just hovering over the line (the arc) the cvs appear, so they 
don't clutter the drawing while you're editing other parts of it.

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?

Isn't there an infinite number of ways, you can do that?

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.

In DPaint (and Canvas RPaint), you specify center and corner of ellipse. 
It's then not rotated. After specifying size this way with two points, 
you can rotate it.

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

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

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

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.

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

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?

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?

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

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
]

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

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

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.

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.

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

Henrik: "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?"

-- Yes it does. It is called new-face, and is created right near 
the top of layout, and returned (of course) at the bottom.

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.

it works well, it just doesn't have some of the latest features and 
very specific layout fixes.

if you download the glayout demo, it will download the glayout and 
slim, for you..

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.

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.

amacleod: unfortunately life has been throwing fast balls at me for 
the last several weeks ... things like recurring water problems on 
my home, making all of my life really complicated and time consuming. 
 

I also tried something with remark which hasn't lead to useable code 
yet... so I am about backtrack to earlier versions and use that while 
I work on the next generation stuff.  


the next gen stuff is closer to Research than Development than I 
had predicted.  I thought it was much easier to leverage the technology 
within the web site/page cycle... but efficiency and elegence principles 
(in form and function) are hard to get right when merging persistent 
and volatile systems.

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.

I think we put it out on one of the IOS servers, Developer maybe, 
but not sure where else.  

I can dust it off and send it to you if you want.

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.

No, as I scan the filesystem, I build the dir/file structure and 
an "associated info" object alongside each one, so it looks like 
this:


 dir-attrs: context [...]  ; <-- All associated directory info goes 
 here.

 file-attrs: context [...] ; <-- All associated file info goes here.
	file-structure: [
		(make dir-attrs [...]) %subdir/ [
			(make file-attrs [...]) %bfile
			(make file-attrs [...]) %cfile
		]
		(make file-attrs [...]) %afile
	]

So we can see the top level has one subdirectory and one file, and 
the subdirectory contains two more files.

I store info in the dir-attrs and file-attrs objects like collapse/expanded.

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.

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.

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

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.

Finally found it.  For anyone else that would like to know where 
this key is located:  It  is HKEY_CURRENT_USER / SOFTWARE / REBOL 
/ VIEW / SANDBOX   There are two keys 'Home' and 'Sandbox'  I found 
for now the best setting for my environment is to set them both to 
C:\rebol\bin

I think that forces everything to run out of the bin and lower directories. 
 The 'home' key I believe tells rebol where to find the 'desktop' 
parameters.

Pekr, if you use DRAW to resize it, the result will be anti-aliased, 
just using view and it won't.

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.

How much work is involved in getting linux view to work on the ARM 
processor?


I see core running on ARM, Dec-Alfa, Sparc etc and even linux view 
runs on X86 and PPC.


Does the graphics side of view need to deal with teh processor or 
does the OS its riding on take care of that part?


I see some cheap UMPC's with touch screens that I would love to put 
my app on but they are ARM base and run CE or Linux....

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

I look in the style and not the documentation, when finding out these 
things. Like:
>> ? tl
Then I notice picked.

Geomol, thanks. It must be some weird user error because I thought 
I tried that and it didn't work. Thanks.

Next question (sorry). I need to make a requestor a little more sophisticated 
than the default ones. I already have a main window opened. I need 
to open this requestor on top but wait for user input. I've fooled 
around with do-events and show-popup but not getting the needed behavior.

You can create basically any type of layout you need and it stays 
on top until user reacts to it...

That's true. Congratulations on your FDNY project. and speaking of 
window titles, Nick A wrote a nice script for changing titles in 
a windows environment: http://www.rebol.org/view-script.r?script=title-bar.r
(unless you really like having "Rebol" in the title bar.

new down-face is set when you click down

 - just curious. What if you would like to do multi-selection? I mean 
 - holding shift down, and selecting e.g. some list elements? You 
 have to remember all down faces, no?

what happens here is that a down event always expects (and creates) 
an up event ... but since the face is removed while in the handling 
of the down event it gets mixed up and this face gets stuck somewhere 
deep  in the view core and it ends up with a reference to a face 
which isn't displayed anymore... so it tries to get that (away)  
event  to trigger over and over .


what I fear most is that the face will end up leaking RAM. but tests 
have not shown it to be the case so far.

yes and it continues to send it away events every time you cross 
the boundry of a face !

I need some clairfication in reading the syntax/specs for Rebol2.x 
stuff.
I'm sure there is a pattern, but I havn't seen it yet.

Example: taken from rebol.net/wiki/VID:_Styles#Derived_styles_2

TEXT-LIST
   size: pair!
   rows: block!

   selected: block! ; this way set-face will not work. need to solve 
   this.
   action: block!
   background: tuple!
   background-draw: block!

how do I know when to assign a value to a [word] i.e. 

lo: [text-list size: 300x200]		;;does not work 
view layout lo

and when not to use the [word] such as 

lo: [text-list 300x200] 	;; works
view layout lo


Question 2. Could someone give a one line (short as possible) example 
of setting all the values for this text-list keyword using this format 
lo: [text-list ......]
view layout lo

thanks in advance.

thanks for the links.  I do have that list-view, I was trying to 
find a smaller way out.  It was missing one or two features I was 
wanting last I checked, and didn't feel like pouring over the source 
code.  about 100 pages.  My brain would take quite a few months to 
understand it.   Excellent software though.  I'll give it some more 
thought, and thanks again for the vid-notes link.  It looks very 
clean.

That is an excellent example.  Answered many questions I had (and 
raised a few more).  Thank you for taking the time to show me this 
Dockimbel.

In case you're wondering about the block after SUPPLY, it's used 
internally by the LIST style to build an iterating function defining 
a local context where COUNT refers to the current row and INDEX to 
the current column. Each horizontally positionned face (purpose of 
the ACROSS keyword) defined in the LIST layout block, is counted 
as a column, so: txt 100 txt 100 => 2 columns.

I'm need to get the name I assigned a face when I alt-click on it. 
I can get its style, offset, size etc but I do not see a way to get 
the face's name. More specificly I have multiple scroll-panels and 
I need to know the one I'm clicking in...

I reckon you did know this,. Maxim, but you just forgot about because 
it's not needed so much.

What I do, which is more simple and direct, is just compare face 
with the word I previously set it to, eg:

	my-scroll-panel: scroll-panel

and later in the event handler just

	if face = my-scroll-panel [...]


This is just comparing two object references for equality, which 
is more fundamental and doesn't need any facility of VID.

Eh? You really ought not to have to modify the scroll-panel.r file. 
That's just going to cause problems for you down the line, because 
you are forking. You should be able to override the default scroll-panel 
feel in your user code. Just let me know what you're trying to do 
with that and I'll show how.

Anton, Your method is not working for me:

alt-event: func [face event] [
	if event/type = 'alt-down [ print "alt-click"
		if face = my-scroll-panel [print "face name = my-scroll-panel"]
		]
	event
]
insert-event-func :alt-event


I get "alt-click" but I do not get true for 'if face = my-scroll-panel'


I tried 'my-scroll-panel (word) and "my-scroll-panel" (quotes") also....

Aha, I know what's probably happening. The scroll-panel contains 
a number of subfaces in a face hierarchy. You are probably not clicking 
on the scroll-panel face, but on one of its subfaces (which are laid 
on top of it, event-wise). If you look at scroll-panel.r, near the 
bottom of the rebol header, you will see the face hierarchy, with 
the two scrollers, the CROP-BOX and the SUBFACE inside the crop-box. 
The SUBFACE covers most of the area of the scroll-panel, and the 
two scrollers take some from the sides.

You can test this idea by giving the scroll-panel an edge, then alt-clicking 
on the edge. You should get a positive identification then. But of 
course, this is probably not very useful to you. What (I assume) 
you will need to do is, given a face, find out if it is inside a 
scroll-panel (or inside a particular scroll-panel of yours). This 
is a little bit complicated, but I have done most of that coding 
already for  mouse roll-wheel scrolling. (See scroll-wheel-handler.r, 
and demo-scroll-wheel-handler.r for how to use it.)

Basically, you will want to make your own "right-click-handler.r", 
just copying scroll-wheel-handler.r's code and modifying the event 
type that is checked for to 'alt-down. Scroll-wheel-handler checks 
for an Anton-extended VID flag, SCROLL-WHEEL, to determine which 
face should handle the event. So I might also advise you define your 
own VID flag to indicate that a face handles alt-click, maybe call 
it simply ALT-DOWN like the event that triggers it, or CONTEXT-MENU-ACTIVE, 
or whatever you're doing. Then make sure that the faces you want 
to respond to your "right-click-handler.r" are flagged with this 
new flag.
That's all, simple!

why not just follow the face up to its parent until you hit the scroll 
panel and then compare then?

amacleod, I thought all that complication would make you pause. And 
fair enough. I should say though that I've done the scroll-wheel-handler 
in the most proper way I can. It seems a pity not to take advantage 
of its structure. Anyway, it would be nice if you could say what 
you want to handle alt-click for. I'm still not sure why you want 
it. If that's clear to me, then I could probably make the new handler 
for you pretty quickly, as I'm more familiar with my code, obviously.

because the lo block you constructed contains a dialect, not rebol 
code.

When you call the layout function, the dialect is processed and the 
values [edge [...]] are translated to code [face/edge: make face/edge 
[...]]

Then is something like this possible? or does the layout function 
always take input either at that location or the 'edge word as dialect? 
 I guess the question could be... how do we know if we are creating 
code or dialect and does it matter?


view layout [text 100x100 "Hello" edge: make/edge [size: 25x25 color: 
0.0.255 effect: 'bevel]]

Thanks. That opens my eyes to what I refer to as Rebol Voodoo. One 
can easily forget the relationship between a dialect and Rebol. Good 
stuff.

It's the central point with Rebol, when a function is accepting a 
block as input, you can't  guess if it will be processed as pure 
rebol code, list of data, or as a dialect (mixed data and commands).
Data is code, Code is data. Never forget.

i meant you can't guess until you read the documentation of a specific 
function.
'help and 'source are they magic keys.

Oh, I like the feeling when I can say "Oh, that's how it works." 
And then there's anamonitor. I can't tell you how many times I've 
gone back and forth with that tool. :-)

you should clear the original block you supplied to the drop down 
list, and then append new items to it.  that should work.

Does the command switch -v and -c does not prevent that?

and fisrt trying to make some hello in ssh

that should mean no install, no window, no viewtop and trace

And it is pitty that on win it works, but not on Linux.
:(

Any one have a "disapearing scroller bar problem?  i've tracked the 
bug down to the various redraw funcs in the scrollpane... but can't 
seem to fix it...


the ridiculous thing is that the bar disapears when you active the 
window the scrollbar is in!  go to/from another window and "sometimes" 
the scroller knob offset gets set to some improper value, and it 
disapears.

Has anyone written a to-do list manager?  There was one on IOS but 
I don't have the client for that anymore, and my recall is that it 
was fairly basic.

When last I heard, the guy got a job doing .NET stuff or some such 
and stopped developing AGG two years ago. Afaik he changed the license 
from BSD for 2.4 to GPL for 2.5, saying that "all future development" 
would be to the GPL version. However, the license change was the 
only difference between 2.4 and 2.5, and there was no future development. 
All afaik. So, abandoned, but BSD-licensed so who cares?