#2159 NORM Trial-3: Journal should be the active activity at boot

[Zarro Boogs per Child]

#2159: Journal should be the active activity at boot
---------------------+------------------------------------------------------
  Reporter:  Eben    |       Owner:  marco  
      Type:  defect  |      Status:  new    
  Priority:  normal  |   Milestone:  Trial-3
 Component:  sugar   |     Version:         
Resolution:          |    Keywords:  review-
  Verified:  0       |  
---------------------+------------------------------------------------------
Comment (by danw):

 Replying to [comment:3 marco]:
 > Why we are not notifying the activity here? To avoid a double
 notification for activities which doesn't startup iconified? Though
 ideally the Journal would get the set_active too.

 > Same question as above. Are we trying to avoid double set_active when
 zooming out to Home? In the activity close case we want to do a set_active
 though.

 I was trying to distinguish between the cases of "the user is currently
 doing something in this activity" and "the user is currently in the shell,
 but if he clicked the Activity View button, he *would* end up in this
 activity". The activity only gets notified when the user actually switches
 to it. So the journal doesn't get notified at startup, because the shell
 is in front of it. When you click on it or switch to Activity view, *then*
 it gets notified. And if you quit an activity and the UI switches to the
 Home view, we don't notify the next activity in the stack right away,
 because it's not active, the Home view is.

 The patch doesn't quite get this right though, and it keeps the
 distinction between would-be-active and actually-active activities
 internal to HomeModel. But looking at the code that currently uses
 get_current_activity() and/or active-activity-changed, it looks like half
 want it one way and half want it the other:

  * ActivitiesDonut and BuddyMenu need to know the would-be-active
 activity, since they're only used in the shell views, when there is no
 actually-active activity
  * FriendsBox needs to know the actually-active activity, because you only
 want to see an activity's partipants in the frame when you're actually in
 that activity, not when you're in the Home view.
  * ShellService needs to know the actually-active activity, because that's
 what gets exposed to the presence service, and you want the user's
 position in the Neighborhood view to reflect what he's *actually* doing,
 not merely what he might be about to do

 (In fact, it's possible that we need to track *three* different cases, not
 just two: BuddyMenu might only want to work if the would-be-active
 activity is also the most-recently-active activity, and not, say, if you
 just quit an activity and the would-be-active activity is now something
 you haven't touched in a while.)

 > {{{
 > +    def _set_current_activity(self, new_activity, notify_activity):
 > }}}
 >
 > While we are at it, can you please rename this and the property to
 set_active_activity?

 So as suggested above, I think we want get_topmost_activity() and
 "topmost-activity-changed" (for the would-be-active case) and
 get_active_activity() and "active-activity-changed" (for the actually-
 active case). Sound good?

-- 
Ticket URL: <https://dev.laptop.org/ticket/2159#comment:5>
One Laptop Per Child <http://laptop.org/>