-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for XG_MIME_PNG and NSPasteboardTypePNG in both copy&paste directions. #47
Conversation
PNG support needs to be conditional. How can it done be best? I think a run-time feature check from base (NSImage? NSImageRep?) is best. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm afraid I already made conflicting changes while adding support for text/plain;charset=utf8 (which seems to be a commonly used type) and clearer debug output.
The only actual bug I can see is that the line:
xTypes[numTypes++] = XG_MIME_PNG;
should be paired with an increase in the size of the xTypes buffer, to avoid any possibility of a buffer overrun.
In case you missed by response to this idea elsewhere; in gpbs support for every type should be unconditional (I want to add all the pasteboard types publicly declared in the GUI library). That's because gpbs only deals with declaring types and moving the data around, so unless it's going to do format conversion itself (which it mostly shouldn't, though admittedly it does for strings) the data is opaque and the code doesn't need to be concerned about whether other parts of the system support it or not: if other part of the system don't support a type, they just won't copy items of that type to the pasteboard and they won't try to paste in items of that type form the pasteboard. This probably means that the issue is a lot simpler than you have been thinking, and you are worrying unnecessarily. |
Here is a full list of the pasteboard types I found in the GUI headers. Some of them are duplicates (because Apple changed the type names, eg NSTIFFPboardType is the same as NSPasteboardTypeTIFF), and some of them are unlikely to have an equivalent in X, but we should be able to support things like PDF, URL, HTML, VCard, perhaps Color, Font Ruler GSMovableToolbarItemPboardType |
Well; I found it cleaner to work on a branch, after we hacked deep into the night and I continued... I did some test this morning. Told you I would push a branch. My changes are now stale, I think this branch is now useless. I think you missed a bit, but I will look twice and just push to master in case. |
Yes, you are probably correct. the pastboard server is just a "messenger" there. As we have seen in Price, both available types in copy and in paste are decided by the application and it can be made dynamic from available types. It is true for Image Reps, for other types I don't know, but there even more it may be app-specific? (e.g. RTF, HTML... different text formats, who could transform UTF8 to e.g. latin1 in the copy?) |
@@ -1376,6 +1390,11 @@ - (BOOL) xProvideSelection: (XSelectionRequestEvent*)xEvent | |||
xTypes[numTypes++] = XG_MIME_TIFF; | |||
} | |||
|
|||
if ([types containsObject: NSPasteboardTypePNG]) | |||
{ | |||
xTypes[numTypes++] = XG_MIME_PNG; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You also need to increase the size of xTypes in line 1353.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change won't work when guy was build without PNG support. I am not sure what will happen then.
I did read the comments from Richard only after I commented myself. I agree with his considerations on PNG and other types. In the end it is the application that decides what it offers or what it wants to consume. The pasteboard server should not interfere with that. |
No description provided.