Re: [Gtk-osx-devs] Not notified on clipboard clear
- From: John Ralls <jralls ceridwen us>
- To: Richard Procter <richard n procter gmail com>
- Cc: GTK+-2 OSX Devs <gtk-osx-devs lists sourceforge net>
- Subject: Re: [Gtk-osx-devs] Not notified on clipboard clear
- Date: Fri, 6 Aug 2010 12:57:05 -0700
On Aug 4, 2010, at 1:05 AM, Richard Procter wrote:
> Hi John,
>
> I've hit a snag with copy/paste and would like to know if you recognise it?
>
> The symptoms are that the 'clipboard cleared' callback registered via gtk_clipboard_set_with_data() is not being called.
>
> I tried to narrow the problem down to a test case (attached) but, strangely, although it worked as expected in win32, under OS X it is more broken than my python application. Neither request callback or clear callbacks are invoked, nor does gtk_clipboard_set_with_data result in the targets being advertised (as vertified by the xcode clipboard viewer utility).
>
> My application, on the other hand, successfully advertises targets and satisfies requests, but does not receive any clipboard clear calls.
>
> I am using gtk+-2.18.2, and I have also tried this with your clipboard patch in bug #571582 without effect.
>
> If there's nothing obviously wrong with what I'm doing, I'll raise a GTK bug.
>
> thanks + regards,
> Richard.
>
> <cliptest.c>
>
Richard,
Sorry this took so long to bubble through my queue.
I tried your test program and got the following output:
Existing targets:
6 targets available:
0: CorePasteboardFlavorType 0x54455854
1: com.apple.traditional-mac-plain-text
2: UTF8_STRING
3: public.utf8-plain-text
4: CorePasteboardFlavorType 0x75747874
5: public.utf16-plain-text
Posting 1 targets...
Available targets are now:
2 targets available:
0: VendorTag/Foo
1: dyn.ah62d4rv4gu8zq3psqv11ezdbq61yq55t
ClipboardViewer (once I had built it) displayed VendorTag/Foo and dyn...
When I click on one of the targets in ClipboardViewer, it crashes, with the following output:
get_clip_cb called!
2010-08-06 12:29:16.429 cliptest[99043:903] An uncaught exception was raised
2010-08-06 12:29:16.432 cliptest[99043:903] *** -[NSConcreteData initWithBytes:length:copy:freeWhenDone:bytesAreVM:]: absurd length: 4294967295, maximum size: 2147483648 bytes
2010-08-06 12:29:16.669 cliptest[99043:903] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSConcreteData initWithBytes:length:copy:freeWhenDone:bytesAreVM:]: absurd length: 4294967295, maximum size: 2147483648 bytes'
*** Call stack at first throw:
(
0 CoreFoundation 0x97722bba __raiseError + 410
1 libobjc.A.dylib 0x948bf509 objc_exception_throw + 56
2 CoreFoundation 0x977228e8 +[NSException raise:format:arguments:] + 136
3 CoreFoundation 0x9772285a +[NSException raise:format:] + 58
4 Foundation 0x958849f2 -[NSConcreteData initWithBytes:length:copy:freeWhenDone:bytesAreVM:] + 135
5 Foundation 0x958b39d6 -[NSData(NSData) initWithBytesNoCopy:length:freeWhenDone:] + 72
6 Foundation 0x958c4db1 +[NSData(NSData) dataWithBytesNoCopy:length:freeWhenDone:] + 96
7 libgtk-quartz-3.0.0.dylib 0x002b15d7 _gtk_quartz_set_selection_data_for_pasteboard + 1073
8 libgtk-quartz-3.0.0.dylib 0x002aa706 -[GtkClipboardOwner pasteboard:provideDataForType:] + 199
...
Which is more-or-less what I would expect from your code. (Interestingly, if I kill your program and *then* examine the clipboard item, I see the program's console output in ClipboardViewer.)
Here's the catch: I tested against an SVN build from June 25. 2.18 is a year old, and Kris Reitveld has done a lot of really good work in cleaning things up in the meantime.
Regards,
John Ralls
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]