If you cut some HTML I expect HTML to be pasted. Code that removes the markup just breaks things like pasting into an HTML compose box on a web page.
The user can delete the HTML if they don't want it. Excessive worrying about data types is why cut & paste is not working right. The text is UTF8, and '<' is a legal character in UTF8 so it should be preserved. If you want a complex object, put it in a file and send the URL as UTF8. On 12/11/2011 03:12 PM, Ian MacArthur wrote: > > On 11 Dec 2011, at 20:09, Domingo Alvarez Duarte wrote: > >> Talking about copy/paste on windows at least apparently the clipboard can >> hold a reference for the original source and in case the receiver can't >> handle the original code it's converted somehow to plain text sometimes. > > In general (this is a generalisation over what Win32 and X11 do, I don't > actually have any idea how cut/paste is implemented on OSX) it's the app's > responsibility to convert the payload into the format that the receiver says > it can handle, though the source and destination can exchange atoms to agree > on a format they both know, it still falls to the source app to do the actual > conversion into the destination format. > > That said, I don't think the fltk core actually exposes enough of this > mechanism to actually allow the app to know what "discussion" was had, and > what conversion is required. > > I think the fltk core just basically says (whether acting as a sender or as a > receiver) that it can handle UTF8 plain text, and nothing else, so ideally > the app would convert whatever it has into plain text before the clipboard > was loaded. > > Though there are subtleties to this I am glossing over and there may well be > bits of this I simply do not understand... > > > > > _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
