Possible solution to copy and paste no longer working in CPTextField

[Saikat Chakrabarti]

Diff - http://github.com/saikat/cappuccino/commit/2c3c7a974910f2f983187d9a2e6441d651b100e0

After Ross' changes in the jake branch to make CPTextFields work more
natively (using keyDown/keyUp events passed through the CPApp event
handler), copy and paste within a CPTextField stopped working. The
problem was twofold:

1) CPApplication stops DOM events from propagating when there is a
keyEquivalent. My application has copy and paste key equivalents, so
the native copy/paste was just never getting through. This wasn't a
problem before since the events weren't going through CPApplication
for text field copy and pasting.

2) Even after removing the code in CPApplication that does this, doing
a paste within a CPTextField was causing the focus to be taken away
from the text field to a _DOMPasteboardElement. I fiddled around with
trying to get things working using the _DOMPasteboardElement for a
short while. I'm not entirely sure, but I THINK this
DOMPasteboardElement might rely on my application specifically giving
it the pasteboard data to put into the browser's pasteboard? This
seems way too hard (I'd need to find the focused text field and copy
the selected text manually inside my app), though I'm probably
misunderstanding. In the end I just removed the entire thing because
I can't really find a use case where this pasteboard element is
necessary (I've tried copy and pasting in text from outside apps, copy
and pasting text into outside apps, and the normal copy and paste
functionality inside my app).

Caveats - not sure if I've inadvertently removed some functionality by
getting rid of this DOMPasteboardElement, and also, I'm not sure if my
added check in CPApplication is really ok (seems hacky).

-Saikat

[Saikat Chakrabarti]

Forgot to mention - tested on OS X 10.6 on Safari 4 and Firefox 3.5.3

[Saikat Chakrabarti]

I realized that in most of my test cases, the text field i was pasting
into was a different window than the main window of the app. So if I
copy an object in the app into my pasteboard, then try to paste into a
text field that's in the main window of the app, the text doesn't
paste and instead the application pastes the object in the app's
pasteboard. This is a problem, but it is still no worse i think than
the current Jake behavior. But definitely a bit more needs to be
done.

On Thu, Nov 19, 2009 at 12:11 PM, Saikat Chakrabarti

[Ross Boucher]

You simply can't take out the pasteboard element. Try as you might,
it's necessary.

> --
>
> You received this message because you are subscribed to the Google
> Groups "Cappuccino & Objective-J Development List" group.
> To post to this group, send email to objecti...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/objectivej-dev?hl=
> .
>
>

[Saikat Chakrabarti]

Meant to send to group, oops.

On Thu, Nov 19, 2009 at 7:40 PM, Saikat Chakrabarti
<sai...@gomockingbird.com> wrote:
> Maybe - even with the pasteboard element in there, I'm not entirely sure how
> this would work.  Is the pasteboard relying on the application to provide it
> with the string that is copied?  This stuff seems to imply so:
>
> if (isNativeCopyOrCutEvent)
> 0
> -        {
> 0
> -            var pasteboard = [CPPasteboard generalPasteboard],
> 0
> -                types = [pasteboard types];
> 0
> -
> 0
> -            // If this is a native copy event, then check if the pasteboard has anything in it.
> 0
> -            if (types.length)
> 0
> -            {
> 0
> -                if ([types indexOfObjectIdenticalTo:CPStringPboardType] != CPNotFound)
> 0
> -                    _DOMPasteboardElement.value = [pasteboard stringForType:CPStringPboardType];
> 0
> -                else
> 0
> -                    _DOMPasteboardElement.value = [pasteboard _generateStateUID];
> 0
> -
> 0
> -                _DOMPasteboardElement.select();
>
> The way the pasteboard is setup, it doesn't seem to ever check the browser's
> clipboard.  And the code above won't actually copy into the browser's
> clipboard - the dom event gets suppressed at the CPApplication stage.  And
> even if it isn't suppressed at CPApplication, any paste would trigger the
> CPApplication's paste anyway (since the event is getting sent to
> CPApplication regardless of if it is a native copy or paste), which seems
> undesirable (and the problem I'm having right now).  The only reason this
> pasteboard stuff was working before was that copy and paste within a
> CPTextField wasn't being handled at all by the CPApplication event handler.
>  I don't know if this pasteboard code ever worked or what it worked for, but
> whatever needs to replace it needs to look fairly different.  What actually
> needs to happen is a suppression of the cappuccino copy/paste functionality
> if a native copy/paste occurs.  I haven't thought much about it, but I'm not
> entirely sure how to do this without specifically checking what the first
> responder is currently (and if it is something that can accept a native
> paste).

[Saikat Chakrabarti]

Though something I just noticed - in 280Slides, copying a slide and
then pasting - pasting only works if the slides panel has focus. Is
the paste operation there doing a check on the first responder? If
this is just expected in the application's copy/paste function, then
that takes care of it - I just do a check to see if my copied objects
can be pasted to the current first responder.

On Thu, Nov 19, 2009 at 7:41 PM, Saikat Chakrabarti