#5753 HIGH Update.: A shared copyText() method should exist in the common Sugar API.

[Zarro Boogs per Child]

#5753: A shared copyText() method should exist in the common Sugar API.
------------------------+---------------------------------------------------
  Reporter:  legutierr  |       Owner:  marco    
      Type:  defect     |      Status:  new      
  Priority:  high       |   Milestone:  Update.2 
 Component:  sugar      |     Version:  Build 650
Resolution:             |    Keywords:           
  Verified:  0          |    Blocking:           
 Blockedby:             |  
------------------------+---------------------------------------------------

Comment(by tomeu):

 Replying to [comment:3 legutierr]:
 > Replying to [comment:2 tomeu]:
 > > Well, the problem is that it is not only text. We have plain text in
 different encodings plus rtf, html, etc. As activities can offer and
 accept a subset of those formats, some negotiation needs to happen. AFAIK,
 the situation is the same in other X-based desktops, win32 and osx.
 > >
 > > We certainly want the users to think that it is only text, but for
 that we need some cooperation from activity developers.
 > >
 > > In my opinion, the most we can do is to decide some standardized
 formats for each kind of data.
 >
 > tomeu-
 >
 > Well, I've never had any issues copying text out of one Mac application
 and pasting it into another, and that's not just because of Apple's QA.
 Apple does a little more than rely on its external (and internal)
 developers' adherence to standards to maintain consistency in the
 implementation.  By implementing extensive frameworks that encapsulate
 app/os interactions (including special cases like diverse text encodings)
 in a highly usable and encapsulated way, Apple gives developers tools that
 they are likely to use to implement common tasks (like clipboard
 interaction), so that they avoid trying to do those things
 (incorrectly/inconsistently) on their own.

 Sure, and although we don't have a so nice API like Cocoa, pygtk provides
 some help on that area. If all activities used the set_text(), set_uris()
 and set_pixbuf() methods, this problem would be much smaller.

 Most of these issues arise in activities derived from normal deskptop apps
 like Abiword and Mozilla, that don't use pygtk. Those apps are cross-
 platform and their unix impl have weak support for the clipboard because
 in Unix desktops it is such a big mess that few people actually use it.

 Another point of trouble is that we try to hide the formats complexity
 from the user, and that means that sugar needs to be aware of the
 different formats in order to categorize those in Text, Image, Video,
 Sound, etc.

 And one more is that in the journal we can store only one format. This
 means that, when the user adds one clipping to the journal, Sugar needs to
 choose the format that will keep everybody happy when that entry is taken
 out from the journal and pasted or opened in another activity. This is not
 an easy task. See #5389 or #5586 for two instances of this.

 > In other words, I believe that there is a design-oriented solution to
 this problem.

 You mean adding something to the python sugar API in the lines of what
 cocoa has? If so, can you give an example of what you propose? But take in
 mind that we really need to support the X selection mechanism in which is
 based copy&paste and dnd, as we cannot force all activities to be written
 in python and use our APIs (other than the strictly necessary).

 Some links that could be useful:

 http://www.freedesktop.org/wiki/Draganddropwarts
 http://www.newmobilecomputing.com/story.php/5215/The-Big-freedesktop.org-
 Interview/
 http://www.freedesktop.org/wiki/Specifications/clipboards-spec
 http://www.newplanetsoftware.com/xdnd/
 http://www.pps.jussieu.fr/~jch/software/UTF8_STRING/

 > I'm trying to think of ways to contribute to this project (thanks for
 that API link BTW), and I would love to spend some time working on a way
 to make it easier for developers to obey the standards set by sugar (like
 providing more extensive tools in the API).  Contributing anything in that
 area would require some close coordination with the core design team,
 however, so I don't know.  What do you recommend?

 Almost all communication between the sugar and design teams happens in the
 sugar mailing list, trac and #sugar, you are welcome to jump and ask
 anything you want.

-- 
Ticket URL: <http://dev.laptop.org/ticket/5753#comment:4>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system