#2328 BLOC Update.: Bitfrost requires that the 'File New' and 'Share' features be initiated through Sugar itself, not through the activities.

[Zarro Boogs per Child]

#2328: Bitfrost requires that the 'File New' and 'Share' features be initiated
through Sugar itself, not through the activities.
----------------------+-----------------------------------------------------
  Reporter:  mstone   |       Owner:  marco          
      Type:  defect   |      Status:  new            
  Priority:  blocker  |   Milestone:  Update.2       
 Component:  sugar    |     Version:                 
Resolution:           |    Keywords:  security, sugar
  Verified:  0        |    Blocking:                 
 Blockedby:           |  
----------------------+-----------------------------------------------------

Comment(by homunq):

 I would like to vote especially for gnu's parenthetical comment above. A
 broader analysis follows.

 Functions affected: close/exit, share, keep/save (and set saved name),
 ?/export, add/import. (By export and import, I am talking about everything
 file-related that non-sugar activities do that is neither file-open, file-
 save(as), nor preferences. That covers a lot - export, import, compare
 (diff), use plugin ... For some of these uses, the natural solution is to
 use cut/paste instead of open, especially if it is easy to keep clipboard
 items in the journal; but this solution will just not result in the right
 UI in many cases.)

 As I see it the options are:
 1. Put all of this functionality into the frame somehow. In the new frame,
 with running activities at the top, this probably means dropdowns from the
 running activities.
 Pros: Easier sugarization (possibility of a sugarizing wrapper on existing
 X apps greatly improved). There is a real logic to including the functions
 here anyway. Reduces toolbar clutter. Better security. More clarity to the
 user of what UI is secure.
 Cons: Less discoverable. Less accessible. Harder to create an API/UI guide
 so that an app can add new functions to this group. Breaks with existing
 UI.
 2. Do the embed-a-toolbar or other trick as described above.
 Pros + cons: pretty much the converse of above.
 3. Do both, let some applications do only #1.
 Pros: In many of the pros/cons mentioned above, as good as the better
 option; in the rest, as good as the average.
 Cons: more work, more complication.

 I vote that the long-term plan should be 3.

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