#2328 BLOC Trial-3: 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:  Eben           
      Type:  defect            |      Status:  new            
  Priority:  blocker           |   Milestone:  Trial-3        
 Component:  interface-design  |     Version:                 
Resolution:                    |    Keywords:  security, sugar
  Verified:  0                 |  
-------------------------------+--------------------------------------------
Comment (by danw):

 OK, following up on the discussion on irc:

 We talked about 4 different levels of embedding:
  1. embed individual widgets into the activity's toolbar (as I first
 suggested above)
  2. embed the entire standard "Activity" toolbar into the activity's
 toolbox
  3. embed the whole "toolbox" (all toolbars plus the selector) into the
 activity's main window
  4. reverse everything, and have the trusted process create the main top-
 level window, with the toolbox, and then embed the activity window inside
 that.

 One consideration was preventing a malicious activity from playing tricks
 with embedding trusted widgets in unexpected locations in the UI, using
 shaped windows, etc, to get the user to click on the trusted widget
 without realizing it. But eventually we realized that unless we do lots of
 hacking up X, they'd be able to do this with any of the solutions. (Any
 app can grab and embed any other window anywhere.) Also, Eben pointed out
 that for both save and share, you'd have to trick the user into making an
 improbable *series* of clicks. And we might be able to prevent this anyway
 by tracking XVisibilityEvents, and having the widgets only work when
 they're completely visible...

 So anyway, if we ignore the don't-let-the-activity-embed-the-trusted-ui-
 in-the-wrong-place consideration, the best solutions are 2 and 3, and 3
 works best for the "force quit" bug (because you want to ensure that the
 user can always switch to the "Activity" toolbar so he can click the Stop
 button). So my proposal for doing that is:

 sugar.activity.ActivityToolbox becomes a subclass of gtk.Socket; when you
 create it (or a subclass of it), it uses dbus to call out to Rainbow (or
 something), which creates something much like the current ActivityToolbox,
 wraps it in a gtk.Plug, and hands that back to the activity, which will
 then presumably put it into the correct place in its UI, although we don't
 enforce that. When the user interacts with the 'Activity' toolbar, the
 toolbox process would handle it and send dbus messages back to the
 activity as needed.

 When the activity calls toolbox.add_toolbar(), the toolbox wraps the
 provided toolbar in a gtk.Plug, and makes a dbus call to the toolbox
 process, which adds a new tab to the toolbox with the right name, creates
 a gtk.Socket, and sticks the plug into it.

 toolbox.get_activity_toolbar() would go away. If activities need to be
 able to make changes to things in the main toolbar, we'd add specific API
 for those things.

 From the user's perspective, nothing would change except that the main
 Activity toolbar (including specifically the close button) and the toolbar
 selector would always work, even if the rest of the activity was hung.
 (Toolbars other than the Activity toolbar would hang when the rest of the
 app hung.)

 From the activity author's perspective, nothing would change except that
 you can no longer directly access the widgets in the 'Activity' toolbar.
 Actions invoked in the 'Activity' toolbar would be handled by
 sugar.activity.Activity itself (just like now), so the embedding/dbus
 changes there wouldn't affect anyone. Actions invoked in other toolbars
 would behave just like they always did, because they'd still be happening
 in-process (the only difference being that there'd be a foreign window
 between them and the top-level in the window hierarchy).

-- 
Ticket URL: <http://dev.laptop.org/ticket/2328#comment:6>
One Laptop Per Child <http://laptop.org/>