World: r3wp

Was the 'vectorial argument for text in the draw dialect removed, 
or broken?

It works fine in 2.7.6, but in 2.7.7 it causes rebol to segfault. 
 (linux)

Also, I thought there was a Draw group, but no longer see it.  If 
it was made private, can I be re-added?

There is no private grouop for Draw (unless it has an obscure name 
that I do not recognise).
Perhaps time to start a Draw group?

file a bug report for linux

Um, where?

it works on windows for me.

R2 bugs are still filed on rebol.net

i think that 2.7.7 crashes for most DRAW commands on Linux. at this 
point we have enough reports, it's worth making a ticket.

is there a programmtically solution to 're-center' the toplevel-face 
on the os-desktop after a face reseize?

you can add an event function to the window and trigger it on event/type 
= 'resize and then move the window according to its current size 
versus system/view/screen-size (or some such)

yes, nice idea henrik. this way I don't have to take care for every 
resize. thx... (so the path 'system/view/screen-size' looks don't 
exists, will check)

just found it -> system/view/screen-face/size

couldn't remember, so was betting you could find it yourself :-)

thx henrik ;-)

remember to use remove-event-func with the function again, when the 
window closes, otherwise amusing (depending on your mood) things 
happen.

There is an AGG group, but there may be cause for a new "Draw dialect" 
group.

how to detect  - which face - is envoking an event within a global 
insert-event-func?

do you want the face or the window?

window

so I have to filter the correct event (resize) and object (the window/face) 
to calculate the new pos on the desktop.

something like this...

insert-event-func 	[
    switch event/type [
        key         	[]  
        time        	[]
        close       	[]  
        offset      	[]  
        resize      	[
		switch event/face [
			X [recalculate pos for face x]
			...
			...
		]
	]  
             scroll-line 	[]  
             scroll-page 	[]  
	up 		[]  
	move 		[] 
	down 		[]  
	active 		[]  
	inactive 	[]  
	alt-down	[]  
	alt-up		[]   
	minimize	[]  
	maximize	[]  
    ]
    event
]

the window face name usually works, if you differentiate the names 
of the windows.

??

try probing face/text and see if it matches the window name

resize events only occur for windows... no?

don't know sure but is there no event/object message?

event/face perhaps

windows are passed in the event/face, that is sure... so if resize 
events occur only for windows, you should be pretty safe in assuming 
that in this case the event/face is always a window.

one thing though.  I've discovered that at low-level (view port wake 
event) resizing generates one event per mouse move.   


it sends all of them AFTER you finished resizing (pretty dumb) so 
you may end up with up to a 100 resizing events which are all, basically 
useless except for the last one.


I do not know if they are filtered out within the do-events (and 
thus within the event-func) but you should print out something to 
see if this is the case.

event/face is dumping all.

not sure I get what you mean...

hmmm...face/size too.

dumping?

event/face is holding the whole objects not only the face specs...at 
least if I see rthe amount of data.

yes it always does.  its the face object!

yes, a probe looks like a data dump here. not like a standard face 
spec.

which includes all the subfaces tree in pane

yes but thjis is looking like much more than only the subfaces / 
panes etc.

well if I can intercept an eventtype, I should also be able to detect 
the face from where these events are coming from or not?

ahhh.. this works -> probe event/face/size

yes the face triggering the event is in event/face... sorry, I thought 
it was obvious  ;-)

I just checked and the resize event is only triggered once within 
the event-func.

/text seems like another identifier. 0is there a unique identifier 
I can set for each face? (e.g. a hidden tag field)

I just checked and it as I remembered it, the event func only receives 
the top-level events for the window.

maxim, yes I think you are so deep in lowlevel view ;-))

so up/down events aren't triggered for subfaces, only the window.


so you can assume that the event/face is ALWAYS the window in which 
the event is being generated, NOT the face is could eventually be 
assigned to.

so at least I can use the /text so make a simple switch identifier...

(that's within the event-func)

ahh...ok. just found /data wihich is user-defined. will use this 
to store a simple windows-indicator there.

you don't have to.   the event/face IS a window... everytime.

the actual window face object.