World: r3wp

Actually, I only set system/options/home in my user.r because I'm 
on linux which doesn't have a registry.

On Windows, you can find the registry key which sets system/options/home 
by searching for "rebol" in the registry. (I don't remember what 
it is exactly, but it's easy to find.)

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.

Is there an easy way of how to resize an image? I tried:

i1: load %my-img.png
i2: make image! 82x63 i1

but the image is black :-)

DRAW or use effect [fit] in view

Untested, but should work :

i1: load %my-img.png
i2: make image! 82x63
draw i2 [image i1 0x0 82x63]

thanks, will test ...

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

works, thanks. I just wanted to test, how does REBOL resize. It is 
the same catastrophe as IE. Kudoz to FF ...

Geomol - how do I do it using View?

i2: to-image layout [image i1 82x63 effect [fit]]

DRAW allows upward bilinear filtering, but not downward. VIEW simply 
uses nearest neighbor.

What I need is smaller PNG, because SharePoint just sends original 
image to browser, instructing it to resize. IE is pretty much ugly, 
FF is OK. I tried in xnView, my friend in IrfanView, no matter what 
we do, we can't save so that it preserves transparent color ...

Forget using REBOL for that, if you want to preserve quality.

I'm not sure, if view preserves transparent!?

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.

(If it's a problem otherwize.)

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?

Does anyone know how to set the selected rows programatically within 
a text-list?

>> main: layout [tl: text-list data ["line 1" "line 2" "line 3"]]
>> insert tl/picked "line 2"
>> view main

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.

try inform...its modal

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

Use hide-popup to close inform window

Perfect. Thanks.

My only beef with inform is that It is not so easy to impliment a 
window without border or title bar...I'm sure its possible but I 
have not looked into it too deep...

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.

just discovered a nasty bug in view event handling...  anyone found 
a way to solve the following:


if you remove a face from a layout within the action of that face, 
its "away" engage feel gets stuck until you click on something... 


everytime you hover over something else, its away function is called 
even though its not even displayed in the view anymore!

I suppose one would ask in the away function about visibility, but 
I guess that doesn't stop the away function from being run.

exactly.

I remember something like that. When you click down, the View system 
has to remember which face you clicked down on. In my DO-EVENT simulation, 
I called this face the "down-face". It remembers this face so that 
it can send subsequent "drag" (away/over) events to it, until the 
up event. Obviously it takes no account of whether the down-face 
is still in the layout or not. Pity, isn't it?

so why does it "unstick" when you click something? can that "unsticking" 
be simulated?

Simple, a new "down-face" is set when you click down (so the old 
one is forgotten).

I don't think it can be simulated. (You can try sending a fake 'down 
event to the engage, but I think I probably tried that.) The setting 
of the "down-face" happens in native code in DO EVENT somewhere.

Thankyou, closed source.

I was about to try fiddling around in the vid sdk code to see if 
some context holds the face expecting the away events.. but your 
post sort of confirms that I won't find it  :-(

anyhow, it should be RAMBO'ed, so others can see it as a known bug.

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?

yes but not in the event system.

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.

A down event does not create an up event. You letting go of the mouse 
button creates the up event.

there is always an up event corresponding to the down event for a 
face you clicked on, even if the face is removed from you or you 
aren't releasing the mouse over it.

  there is also a move event triggered each time for some obscure reason.

The reference to the "down-face" is probably stored by View in a 
single variable. When you click down again on another face, that 
reference is changed, so (I assume) there should be no problem.

exactly.

If you don't release the mouse button, you don't get an up event.

What you're saying is when the up event comes, it is sent to the 
engage of the face that was clicked down on, no matter where the 
mouse is now.

But anyway, just nitpicking.

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