World: r3wp

ok, I don't know much about fonts under OSX.

cyphre, has the window-to-front fix for OSX from the blog been noticed? 
someone posted a bit of code to eliminate that problem.

I haven't noticed this. Which blog comment?

cyphre: oh, Carl is talking about a focusing problem, but it would 
be the same thing: http://www.rebol.net/cgi-bin/blog.r?view=0157

Hmm, don't know if Carl noticed it. I'll let him know to be sure.

btw font handling paths in linux is a problem for all apps... not 
just REBOL.

many apps have an explicit config telling it where the fonts are... 
so they can be auto resolved afterwards.

why not just have that extra parameter setup as a global word ?  
then it can be setup within user.r if need be.

Yes, that is also possible alternative. We need to decide the final 
solution soon. Anyway, any useful ideas from 'Linux gurus' are appreciated.

Geomol: I have found what is the problem with LINE-CAP...it works 
with ROUNDED keyword instead of ROUND. I need to check with Carl 
why he decided to use ROUND for LINE-JOIN and ROUNDED for LINE-CAP....

(looks like a typo to me)

hehe :)

Should be easy to fix, so that's good.

Script to test events:

REBOL [
	Comment: {
		Inspired by http://www.rebol.com/how-to/feel.html
	}
]

view/new layout [
	across
	tabs 120
    the-box: box 200x200 "Test Events Here" forest feel [
        engage: func [face action event] [
			ac/text: mold action show ac
			ty/text: mold event/type show ty
			of/text: mold event/offset show of
			co/data: event/control show co
			sh/data: event/shift show sh
			ke/text: mold event/key show ke
			kt/text: mold type? event/key show kt
			ti/text: mold event/time show ti
			dc/data: event/double-click show dc
        ]
    ] return
	lbl "action:" tab ac: info 100 return
	lbl "event/" return
	lbl "type:" tab ty: info 100 return
	lbl "offset:" tab of: info 100 return
	lbl "control:" tab co: led off return
	lbl "shift:" tab sh: led off return
	lbl "key:" tab ke: info 100 return
	lbl "type? key:" tab kt: info 100 return
	lbl "time:" tab ti: info 100 return
	lbl "double-click:" tab dc: led off
	key #"Q" [quit]
]
focus the-box
do-events

I seem to remember, that holding <ctrl>- or <shift>-key under Windows 
while pressing a mouse-button would be detected. Can anyone verify 
that? I can't get it to work under OSX.

yes you get an event with the /shift or /control set to true

(I didn't test in 2.7.4)

Maybe it should be the apple-key, that should work as <ctrl>!? hm

I'll post a comment about it.

I guess so. depends... we cannot handle the alt key  :-(  

do mac keyboards have the alt key?

yes

ok, so I guess the ctrl and mac keys equate.  I'd like to able to 
handle the alt keys too

well, in a way they do. there is a ctrl, alt and cmd key. on PC keyboards, 
the ctrl key handles things that normally is assigned to the cmd 
key and the ctrl key. this makes it a bit confusing to copy (ctrl-c) 
things from a terminal on a PC keyboard, whereas the mac keyboard 
uses cmd-C to copy. in rebol this means that the ctrl functionality 
in windows should be mapped to cmd on the mac, but if this was to 
be done right, we'd need a /cmd refinement as well.

Oh, the cmd-key (apple-key) will actually set event/control true, 
but only for key events. As it is now, I don't think, you can check 
for control or shift when getting a mouse event.

Under Windows, is it possible to detect both event/control and event/shift 
at the same time?

yes.

2.7.5 is out

that was a long week ;)

Did we lose our must-fix bug list? Was that in Graham's temporary 
world?

I bet 3.x is out sooner than anything 2.7 related ;-) Not that I 
would not like you guys have it, but just hopefully, R3 does not 
procrastinate as much as 2.7.x, which was supposed to be out - "soon" 
:-)

pekr, yes there is probably a little dilemma there.

Still on this world .. I can see it.

wow, nice to see the bugfixes for 2.7.6 piling up in RAMBO

basically not enough food to feed other indians.

that's my POV anyways.

the wrong bugs being fixed though... I would have preferred looking 
at hard crashes rather than bugs that can be worked around.

I have the same preference, but any sign of life is good.

corret rebcode, so that it can be included in 3.x ... forget 2.x

I'd really like if rebcode where included in 2.7 but had to be allowed 
within secure... so it would not be a security issue unless you want 
to use anything that you trust is ok.

all it would need is support for struct and arrays.

I feel like I  could really optimise a lot fo my code for it.

I generally just suffer from many deadends with hard crashes, places 
that are hard to work around.

when using rebcode?  or 2.7?  so far I've had very few real problems.... 
even within elixir which has a lot of processing going on.

(in 2.7)

My thoughts are as follows - if we request some small fixes, which 
can be workarounded, then let's spend RT's development in R3 area. 
Fix hard crashes and that's it for 2.7 release ...

I haven't used 2.7 yet.

haven't we seen enough of  "coming soon"? Why 2.7 one month before 
R3 is out?

I regarded 2.7 as kind of experimental release for R3 purposes ...

pekr, I could use stability updates. what if R3 won't be entirely 
stable until mid 2008? As far as we can see, the internal test period 
will only be 45 days. It's disheartening to tell customers that they 
have to deal with the crashes, because there's nothing to do about 
them.

yes, crashes, but my impression was, that RT tried to put some experiments 
into 2.7 ....

why 'switch change and all that discussion for 2.7? We waste valuable 
time. 2.6. was ok, it should be fixed, no new things tried ....