World: r3wp

Yes, if you don't have phone with some OS(ie. Symbian, Linux, Pocket 
PC etc.)  then you are out of luck.

that's why R4J could be a solution :-) OTOH - R3 will be imo reality 
in deep 2007 (I mean some more stable releases), so by 2008, maybe 
we will see next new generation phones ...

java compatibility: yes, it depends on the luck which phone you have. 
It is also possible that the ICQ app is mature enough so it contains 
patches for different phones. Anyway, try to read official Nokia 
dev forum to see really angry developers flaming Nokia for bug XY 
:)

so - can you imagine R3 being ported to certain OSes? How could it 
happen? Would we have to buy some Symbian dev licence, or so, to 
get development tools, allowing us to port R3 open-sourced components, 
and then ask RT to port Rebol library? How would/could user install 
such app onto his/her phone? Well, my questions are probably very 
preliminary anyway :-)

AFAIK you can create any SymbianOS app just with their SDK(free) 
and C/C++ so if RT decide to support Sybian then Rebol SDK would 
contain Symbian version of  Rebol lib which could be used for creating 
Symbian encapped apps. But as you said these are really very preliminary 
thoughts :)

Between View beta 1.3.61.3.1 and 1.3.2.3.1 the draw dialect parameter 
format for FILL-PEN changed.

The following code produces different output (and no longer matches 
my older labels from < 1.3.2):
[

 fill-pen ("style" 0) ("offset" 225x225) ("start" 0) ("end" 220) ("angle" 
 0) ("scalex" 1.0) ("scaley" 1.0) 
	black gray white 
	circle ("centre" 225x225) ("radius" 200)
]
What is the new format and where can I look that up ?

AFAIK there exist some AGG fixes. Are they part of new View and when 
not, when they will be?

Never mind, I figured it out:

; new FILL-PEN parameters since View 1.3.2.3.1 ("style" changed from 
integer! -> word!)
	[

  fill-pen ("offset" 225x225) ("start" 1) ("end" 10) ("angle" 15) ("scalex" 
  12.0) ("scaley" 8.0) ("style" 'radial) 
		black gray white 
		circle ("centre" 225x225) ("radius" 200)
	]

yes, we have changed most of the integer based parameters to word!s 
from View1.3.2

strange glayout has not suffered and uses linear and radial fills... 
is that possible?  are integers still supported?

Looking for an example of a pop up notification window similar to 
those used in MSN Live messenger.  I know I've seen something like 
that done in REBOL.  Know of something?

alert, flash, inform, request come to mind

One that appears in the lower right corner of the screen, raises 
out of the system tray area and then fades

Or something similar

we don't have one in REBOL as standard, but Graham made one for his 
chat program

It was written by Gabriele/Allen .. and coopted by myself.  Source 
is in the script.

Looked through the library a few times already.  I am probably just 
missing it

I was missing it.  Thanks

Josh - Cyphre was supposed to release systray support last week. 
Hopefully it is soon. Dunno about features though ... (it will be 
.dll based)

Thanks, I will keep my ears open

http://anton.wildit.net.au/rebol/view/notify-window.r

I tripped over that PEN with two colours crash bug again #4040 #4086
Hoping these might be fixed this round.

Thanks Anton, that helped me a ton.

No worries.

anyone have a fast  recipe to convert an integer into a tupple?

the complement to:
>> to-integer to-binary 0.2.1
== 513

(sorry that's tuple!)

almost:
>> to-tuple third make struct! [int [int]][513]
== 1.2.0.0

>> to-tuple next reverse third make struct! [int [int]][513]
== 0.2.1

not very REBOLish though  :-(

thanks... I'll wrap that in a func.

rebolish, but I don't know if pretty

to-tuple debase/base skip to-hex 513 2 16

I am trying to make a component which accepts key events and draws 
something on the its face, such as musical notes and  phonetic symbol. 
To accept the key events, the system/view/focal-face has to point 
to the component and system/view/caret has to point to the text in 
the component. The problem is ... I don't want to show the caret. 
It's useless and weird in this case. Is there any way that I can 
hide the caret and still keep my component key-aware. Thank you.

focus/no-show ?

i think there was a hack to do that, iirc you can set the caret to 
a string different than face/text or something like that.

otherwise, you need to intercept keys with detect and "simulate" 
focus on your own.

setting the caret to none works.

after focussing.

Thank you, Henrik, Gabriele, and Volker

Since REBOL/View doesn't support Unicode or Big-5, I am trying to 
make an Input Method Editor (IME) by myself. For typing in Chinese/Japanese/Korean 
text, you need a IME to detect the key inputs and combine them into 
C/J/K characters. I've collected more then 50,000 Chinese characters, 
their bitmap and combination. This only thing I have not done yet 
is the key mapping. For that, I did a little experience, and realized 
that there are some keys REBOL/View cannot detect.


1. F10. REBOL/view detects F1 to F9, even F11 and F12, ... but not 
F10. Why?

2. DELETE as a word!, not char!. Because INSERT is detected as a 
word!, maybe DELETE should be of the same type.

3. CapsLock and NumLock. I whish we could not only detect them when 
pressed, but also query their status anytime we want to know.
4. Shift-down, Shift-Up, Ctrl-down, Ctrl-Up, Alt-down, Alt-up

insert is a word because there is no char for it in ascii; there 
is a char for delete, so it's a char :)

you should be able to decect shift-up etc, by checking event/shift 
and event/ctrl. if not, maybe there's a bug.

I think F10 isprobably because that maps to WM_MENU, so WIndows is 
eating it. For cap/num-lock, you should be able to do that with the 
GetKeyState and GetAsyncKeyState APIs. It is a bit of a shortcoming 
that we only get keypress events, not keyup/keydown as well (if we 
want them anyway).  I can understand the logic, that you won't need 
them in most simple apps, but a lot of people are doing stuff with 
REBOL where they would definitely help.

What's the GetKeyState and GetAsyncKeyState Api ?

From MSDN: 


The GetKeyState function retrieves the status of the specified virtual 
key. The status specifies whether the key is up, down, or toggled 
(on, off—alternating each time the key is pressed). 


The key status returned from this function changes as a thread reads 
key messages from its message queue. The status does not reflect 
the interrupt-level state associated with the hardware. Use the GetAsyncKeyState 
function to retrieve that information. 


An application calls GetKeyState in response to a keyboard-input 
message. This function retrieves the state of the key when the input 
message was generated. 


To retrieve state information for all the virtual keys, use the GetKeyboardState 
function. 


An application can use the virtual-key code constants VK_SHIFT, VK_CONTROL, 
and VK_MENU as values for the nVirtKey parameter. This gives the 
status of the SHIFT, CTRL, or ALT keys without distinguishing between 
left and right. An application can also use the following virtual-key 
code constants as values for nVirtKey to distinguish between the 
left and right instances of those keys.

Gregg, I cannot use the Windows Native APIs. I hope the script is 
portable. I hope that it can run on MacOS, too.

Thank you Gabriele. the event/control and event/shift work.

For portability APIs aren't the easiest way to go. I'm not a *nix 
guy, so I don't know what the solution would be there.