World: r3wp

could it be a compatibility issue? I'm not sure if binaries are supported 
in the XFree86 clipboard

WHy not saving as strings? with binaries you need type-information 
too i guess.

what I want to is right click on an image, copy to clipboard, and 
then paste it into a rebol application.

Yes, that would be nice.

Is there a way with an external app? save clipboard to file?

some apps support it... Directory Opus can paste an image directly 
to a file

depending on app you can also paste the filename/url instead? as 
workaround? But image-clipboard and drag/drop ae so comfortable.

paste .. I guess I mean that the rebol application would then read 
it from the clipboard

I am currently pasting urls in .. but I was hoping for a better solution.

So, is the lack of binary support a cross platform implementation 
issue rather than a technical one in windows ?

Cross platform I guess.

My guess as well. I have some win-clip stuff for images. Nothing 
fancy, but might save you a little effort. Let me know if you're 
interested.

sure ... I thought you had, but I think it was on another world.

load-thru/update http://www.lexicon.net/antonr/rebol/gui/scroll-panel.r

load-thru/update http://www.lexicon.net/antonr/rebol/gui/demo-scroll-panel.r

(bug fixes)

what is it exactly that 'WITH does in LAYOUT? I can assign variables 
to face data, but apparently not face data to variables... I'd like 
to bind the state of a toggle to an external variable in a toggle

oops... erase the "in a toggle" at the end

ok, it seems to be possible with text, using the first option, but 
not state:

f: "REBOL"

view layout [field with [text: f]] ; displays field with "REBOL" 
in it. If I edit the field, the contents of f is changed

g: true

view layout [toggle with [data: state: g]] ; displays a toggle that 
is set true. If I click it to false, the contents of g is _not_ changed

oh... it's because text is bound to a string, where you can't bind 
to TRUE and FALSE...

nitpicking: referenced, not bound :) 'with is simply a make of the 
face, before anything else.

grargh! this reminds me of Niels Bohr's statement on understanding 
quantum mechanics... I guess this can be applied to REBOL as well

:-)

You're dealing with objects. A face is an object. The WITH block 
assign values to the attributes within the object, or extend the 
object with new attributes. Just like:
o1: make object! [a: 0]

o2: make o1 [a: 1 b: 2]	; the attribute a gets the value 1, and a 
new attribute b is created and gets the value 2.


Some data types in REBOL are references, when used in objects, some 
are not. (Remember that data types are grouped as scalars, series, 
etc.)

If you wanna export some face attributes outside, you could do that 
with the action attribute (the action block following many styles 
in VID for example) or in the feel functions.
a: false
view layout [toggle [a: face/data]]

This will change a according to the state of the toggle.

that's also the solution I found...

Then you're not lost at all! It's not as complicated as quantum mechanics! 
;-)

it _would_ have been nice to be able to do the other thing, but the 
code is almost as streamlined as I wanted it to be now. I guess I 
need to study more on datatypes...

The data types in REBOL are one major cornerstone and reason, why 
so much functionality can be written with such little code.
(As I see it.)

Maybe new release is near :-) I just noticed there is few of nice 
bugfixes with comment like: Fixed in Core/SDK 2.6.2 and View 1.3.2 
....

I mean - rambo entries ...

interesting ... maybe in time for Xmas ?

maybe :-)

I could really use a method for slowing down mouse events globally. 
I have a rather complex GUI with about 50 buttons, 2 listviews, fields 
and whatnot. If I accidentally click'n'drag above an empty area of 
the GUI, the interface stops responding for several seconds. I wonder 
how this could be done...

event filtering, or romano's eat function.

does not work anymore with new event handling of 1.3

shouldn't be hard to fix.

Event is still a "drak area" for me ;-)

drak=dark

I have a frustration about the View editor that I don't see in RAMBO. 
 When no text is selected and one hit's ctrl-C, then ctrl-V  it pasts 
the entire document wherever the caret is.  I'm not sure if this 
is supposed to be a feature, but does anyone else find it annoying?

I'm adding it to RAMBO though

The editor code is available at http://www.rebol.com/view/editor.r.
Shouldn't we try to fix this ourselves? The editor has so many bugs 
that should be relatively easy to fix.

Sure, I will try to look at it when I get home

This is not an issue of the editor, but of the way text is copied 
to the clipboard from (at least) an area

I will hunt around for a while, but I'm not sure where the clipboard 
code actually is.

It seems to be the behavior of text editable faces

interesting.... meanwhile, I'm cooking up a replace requester for 
the editor. maybe I'll have something ready by the weekend. (a bit 
busy right now)

The RAMBO ticket is outdated now.   Can anyone point me in the right 
direction as to whether this is just part of VID or something deeper 
than that?

The problem is here:
probe get in ctx-text 'copy-text
func [face][
    if not copy-selected-text face [
        hilight-all face
        copy-selected-text face
    ]
]

And this fixes it:

>> use [body][body: second get in ctx-text 'copy-text remove remove 
body remove back tail body]
== []
>> probe get in ctx-text 'copy-text
func [face][copy-selected-text face]
>> view layout [area "hello"]
>> view layout [field "hello"]

I thought COPY-TEXT might be used by  svv/vid-styles/field/access 
 or  area/access  but it is not (thus, it looks safe).

I think COPY-TEXT is trying to be too smart. I think probably that 
function should not exist. So it might be better to replace calls 
to COPY-TEXT with calls to COPY-SELECTED-TEXT, whose claimed functionality 
is more specific.