Patches welcome! :)

Created attachment 1471 [details]
SDL2-2.0.1-x11-clipboard.patch

Created attachment 1472 [details]
SDL2-2.0.1-android-clipboard.patch

Hopefully deals with API version differences (Android < 3.0 etc) and deals with outside clipboard changes for Android >= 3.0 using SQL_CLIPBOARDCHANGE event.

Great, thanks!
Gabriel, can you take a look at these?

Created attachment 1478 [details]
SDL 2.0.1 cutbuffer type

There's another problem on X11. According to Xlib documentation CUTBUFFER_0 must be of type XA_STRING. If SDL changes this to UFT8_STRING other X11 programs may break. I've observed this with Emacs 23.x which goes in an endless loop on CentOS6.

The X11 patches look sane to me, assuming they work ;)

The Android patch as it is, is a no go, right at the top you are using "android.content.ClipboardManager" which isn't defined in API 10, and is not protected by a android.os.Build.VERSION.SDK_INT conditional, so I guess that will error out if you run it on an API 10 device. Also, the Android_JNI_SetClipboardText seems to be the same as in your previous patch, where I think the changes made by Philipp should make those modifications obsolete (I think!).

For this to work, you need to abstract the clipboard functionality behind two classes, SDLClipboardManager and SDLClipboardManager_API11 or whatever, inheriting from SDLClipboardManager and extending it with the listener and anything else new is available, in a similar fashion as the joystick code works.

Marking a large number of bugs with the "triage-2.0.4" keyword at once. Sorry if you got a lot of email from this. This is to help me sort through some bugs in regards to a 2.0.4 release. We may or may not fix this bug for 2.0.4, though!

(In reply to chw from comment #5)
> There's another problem on X11. According to Xlib documentation CUTBUFFER_0
> must be of type XA_STRING. If SDL changes this to UFT8_STRING other X11
> programs may break. I've observed this with Emacs 23.x which goes in an
> endless loop on CentOS6.

We had caught the second part of this patch in another bug report already, but I've applied the first piece of it in https://hg.libsdl.org/SDL/rev/12d477422f47, thanks!

--ryan.

(In reply to chw from comment #2)
> Created attachment 1471 [details]
> SDL2-2.0.1-x11-clipboard.patch

This is now https://hg.libsdl.org/SDL/rev/b5a26bd8b0e7, thanks!

I can't commit the Android pieces until Gabriel's concerns are resolved, but I think this resolves all the X11 issues for now.

--ryan.

(In reply to Ryan C. Gordon from comment #8)
> (In reply to chw from comment #5)
> > There's another problem on X11. According to Xlib documentation CUTBUFFER_0
> > must be of type XA_STRING. If SDL changes this to UFT8_STRING other X11
> > programs may break. I've observed this with Emacs 23.x which goes in an
> > endless loop on CentOS6.
> 
> We had caught the second part of this patch in another bug report already,
> but I've applied the first piece of it in
> https://hg.libsdl.org/SDL/rev/12d477422f47, thanks!

Whoops, this doesn't do what I thought it did, I've backed it out.

The other bug report I mentioned addressed this specific concern, though, and _should_ fix the problem properly (the above patch predated it). Namely, it doesn't use CUTBUFFER_0 anymore. I haven't tested emacs, but I believe the latest in SDL revision control should work with it.

--ryan.

Comment on attachment 1478 [details]
SDL 2.0.1 cutbuffer type


> There's another problem on X11. According to Xlib documentation CUTBUFFER_0
> must be of type XA_STRING. If SDL changes this to UFT8_STRING other X11
> programs may break. I've observed this with Emacs 23.x which goes in an
> endless loop on CentOS6.

I think we have a proper fix for this now, if you could sync up to the latest and retest Emacs:

     https://hg.libsdl.org/SDL/rev/92472fcca43f

This fixed Google Chrome freezing up when you try to paste into it from an SDL clipboard (and even works with Unicode characters), so I assume it will fix Emacs too.

If Emacs just goes into an infinite loop if it sees Unicode characters, that's an Emacs bug and they should fix it, but the problem in this particular case was very likely SDL.

(Marking the cutbuffer patch attachment as Obsolete so we don't apply it by accident again.)

--ryan.

Sylvain, when you get a chance can you take a crack at rewriting this with the multiple API level support that Gabriel was suggesting here?

Created attachment 2896 [details]
Android patch for notifcation clipboard, with multiple API level

Hi! here's a patch for that with two class loaded regarding API level.
Test both case : before API 11 and after.

I also remove now unused GetSystemServiceFromUIThread() and minor clean-up (haptic warning prototype).

This is in, thanks!
https://hg.libsdl.org/SDL/rev/6185fb86f046