#5860 NORM Never A: Screenshots and downloaded files do not save activity_id and activity in metadata

[Zarro Boogs per Child]

#5860: Screenshots and downloaded files do not save activity_id and activity in
metadata
-----------------------+----------------------------------------------------
  Reporter:  tamichan  |       Owner:  tomeu         
      Type:  defect    |      Status:  new           
  Priority:  normal    |   Milestone:  Never Assigned
 Component:  sugar     |     Version:  Build 653     
Resolution:            |    Keywords:                
  Verified:  0         |    Blocking:                
 Blockedby:            |  
-----------------------+----------------------------------------------------

Comment(by tomeu):

 Replying to [comment:2 tamichan]:
 > Thank you for taking care of this ticket.
 >
 > Although I do not know much about the internals of Sugar, according to
 thee Low-level Activity API description at http://wiki.laptop.org/go/Low-
 level_Activity_API , each activity instance needs to set some properties
 on its top-level window and I thought when Alt-1 key sequence is being
 processed, the code would be able to obtain activity or activity_id from
 those properties.
 >
 > I think there would be no technical problem to obtain activity or
 activity_id in the case of downloaded filed in the Web activity.

 The problem here is not to obtain the bundle_id or the activity_id. What
 happens is that these objects don't make sense to be associated to any
 existing bundle or activity_id.

 The "activity" property means that this entry represents the state of an
 activity of that bundle id. The "activity_id" property means that, when
 resumed, that entry needs to be identified by that id, so it can be
 reshared in the mesh, for example.

 Journal entries that represent the state of an activity when it was
 stopped need to have those properties. This entries can be resumed, and
 the user would be confronted with the activity as it was when stopped for
 the last time.

 Single objects that never were part of a running activity (downloads,
 screenshots, files from usb sticks, etc) shouldn't have those attributes
 as they aren't "frozen activities", but are just data that could be used
 as the starting point of an activity. Once they have been started like
 that in Read or Paint, they would gain those properties as at that point
 became part of an activity's state.

 > I understand that files found in a usb stick cannot have activity or
 activity_id.

 Right, but that's not because of the impossibility of finding sensible
 values for those, but because it doesn't make sense.

 Hope I explained a bit better. Please see
 http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines and
 http://wiki.laptop.org/go/Journal for more information about the journal.
 For more information than the available there, you'll have to play with
 the journal and/or read the code (is relatively simple).

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