So I'm doing the scrap implementation for mac without pyobjc now, and it's passing unit tests and working fine as far as I can tell, but I am having trouble seeing how the scrap API for images would be useful to me in practice, and I'm wondering if I "get it" at all... meaning the whole SCRAP_PBM/SCRAP_PPM/SCRAP_BMP/tiff stuff. Also, having the small list of additional types that windows & X11 specific things feels very not cross-platform of pygame, so I want to make mac support them, but I can't see how to make that support useful either. To summarize, some parts of the api for scrap are feeling rather hacky, very not pythonic, and not like something I'd even try to utilize. So can the list help me understand how it's not, or help me make it useful?
...So I think the purpose of this scrap stuff is to communicate stuff between pygame and other apps, right? like say copying a screenshot from pygame so it can be pasted into photoshop, right? or making it so you can copy/paste strings from your python windowing toolkits to other apps, right? Well my big confusion is that as the API user, is that I'd be specifying what I want with mime-types, and I don't know what that is supposed to mean. If I'm trying to get stuff from the scrap module, then I want to work with python/pygame objects, right? When I say "image/bmp", am I saying give me the image as an image/bmp, or am I saying only give me images if they are image/bmp? Also, why would it be an advantage to me as a pygame user to say I want SCRAP_PBM vs. SCRAP_BMP? do I really care at all? Isn't it true that I really just want a surface, and any PBM/tiff/BMP string intermediate step is just extra work I have to do? Likewise for putting stuff into the scrap - I would think that as a pygame user I just want to put my surface on the clipboard in whatever way is best for the platform, right? meaning paste it so it can go into ms paint/photoshop on windows, and paste it so it can go into gimp/icon composer/photoshop on the mac, and it can go into gimp on linux, right? Does a pygame user really want to specify the precise clipboard type, here? Isn't this just an opportunity to get the clipboard format "wrong" (meaning it can't be pasted into common apps) for a particular platform? For strings/text, I have minor but similar confusions - I'm a bit confused by some minor string stuff as well - what is it supposed to mean in I specify "text/plain" vs. "text/plain;charset=utf-8"? Am I specifying the format that I'd like things returned or am I saying I only want this text if it adheres to utf-8? Also, what encoding is text/plain supposed to mean? Why not instead just have pygame have a defined encoding for text copy/pasted and make it the pygame lib's responsibility to adhere to it? (for instance, why not just say it's always utf-8 in and out, until python 3.0 where we say it's always unicode?) some other little questions: * the selection thing - what's it actually used for? what does it mean to copy and paste a selection? is there anybody anywhere who copies and pastes "selections" in/out of a pygame app? does it make sense for "selections" to be portable between pygame apps and other apps? If this is not something useful to pygame apps, but instead is an idiosyncrosy of X11 that just has to be handled, can we just make it handled automatically instead of being part of the API? * so what does pygame.scrap.lost mean? in what cases will the scrap be lost? when it is lost, what is the action a pygame script would take to fix it? why not just have each specific platform check for "lostness" if the platform requires it, and automatically fix the problem if it occurs? When and why would I care if it's "lost" in a pygame app? * the unit test for scrap puts image.tostring into the scrap as a SCRAP_BMP and gets it out as the same - however the windows code for scrap put appears to strip off a BMP image header for SCRAP_BMP, and adds a BMP header back in when getting things. So in that case, the unit test and windows source appear to be rather at odds - so which is right?
