Allow adding and removing activities to the bottom frame

[tomeu]

Eben, how should this work?

[Eben]

We want to have a secondary rollover for all of the activities in the frame. The options on this list should include "start" and "remove" (possibly among others). This allows one to remove anything they want from the frame. We can also interact with these items via drag'n'drop. Our initial proposal is to treat this drag positively, so that dropping the activity on an XO would send it to them, dropping it in the ring would start a new instance, and dropping it on the clipboard would create a reference copy there. Another, mutually exclusive option is to treat the drag negatively, so that dragging an item out of the frame has the effect of removing its reference. This is the method used, for instance, in the Mac OSX Dock. Still, I think that the positive approach is a better one, since it's consistent with the way that all other frame edges and trays function.

Of course, the positive drag will work for adding to the frame. Dragging an activity from the Journal to the activities edge of the frame should add a reference there. Furthermore, dragging items around within the frame should reposition them. Once we have paging arrows within the frame, hovering over a paging arrow for a short delay (.5 sec?) should page once in the appropriate direction, allowing dragging across pages.

We don't yet have a solution for adding activities to the frame without dragging. One ideal option is to include a checkbox or toggle button within the journal entry for an activity which can toggle its presence in the frame on and off. Of course, this requires either a special casing of the activity entries or a generalized system for extending entries. Since we have thoughts about the possibilities of text entries, calendar entries, and clipping entries, among others, some specialized entry types might be acceptable. It would certainly solve the problem.

Tomeu, what do you think as far as integration with the Journal goes?

[tomeu]

I don't see any problem in doing what you described in the Journal.

What worries me more is the work in Sugar. Right now we have a very simple approach that consists in loading all activities that can be found in /usr/share/activities or ~/Activities. When you "resume" a journal entry that is a bundle, the Journal unpacks the bundle in ~/Activities and then notifies the Shell that a new activity has been added.

What I need to clarify is:

• All activities exist as journal entries? Even the ones we shipped by default?
• All activities can be removed from the frame? How we add them back?

[Eben]

Your comment about Sugar integration is a little bit confusing to me. When you say that you "load in" all activities in ~/Activities, do you mean that you put every one there into the frame directly? If that's the case, we really need to have the "loader" check the state to be sure the activity reference should be put there at all. Also, note that the stored state should actually be kept as an array, and not a bunch of booleans. We want to remember relative position, so that they can be arranged as the child wishes.

Regarding your questions:

We either need all activities to exist as Journal entries, or we need to lock those that are shipped so that they can't ever be removed. I think the former solution is the better one, although it does force things into the Journal that the child didn't create themselves. Still, for management purposes, I feel it's best to treat them equally. In order to put an activity back into the frame, the child could drag it in from the Journal, or check the checkbox/toggle within the Journal entry which represents its presence there; it would just be appended to the end of the list when checked.

[tomeu]

Replying to Eben:

Your comment about Sugar integration is a little bit confusing to me. When you say that you "load in" all activities in ~/Activities, do you mean that you put every one there into the frame directly?

Yup, all activities except those that have show_launcher=no in their activity.info (Read, right now).

If that's the case, we really need to have the "loader" check the state to be sure the activity reference should be put there at all. Also, note that the stored state should actually be kept as an array, and not a bunch of booleans. We want to remember relative position, so that they can be arranged as the child wishes.

Ok, we could use a config file similar to the one we use for remembering friends or access points.

Regarding your questions: We either need all activities to exist as Journal entries, or we need to lock those that are shipped so that they can't ever be removed. I think the former solution is the better one, although it does force things into the Journal that the child didn't create themselves. Still, for management purposes, I feel it's best to treat them equally. In order to put an activity back into the frame, the child could drag it in from the Journal, or check the checkbox/toggle within the Journal entry which represents its presence there; it would just be appended to the end of the list when checked.

Yes, but what happens if the children deletes the journal entry for Browse? He needs to get a new Browse activity from some other laptop? And what about the Journal? It's an even more special activity.

What if we have a basic set of activities that appear on the frame, cannot be removed from there, and don't appear in the Journal? They could be Browse, Paint, Write, Record, Chat, ... the ones we consider are part of Sugar. Perhaps we could lock them on the left side of the frame and leave the right side for adding shortcuts to activities in the Journal. Some of the shipped activities won't be so integral to the Sugar experience.

[Eben]

Yes, but what happens if the children deletes the journal entry for Browse? He needs to get a new Browse activity from some other laptop? And what about the Journal? It's an even more special activity.

Journal is special; it doesn't belong in the Journal (We can spare the kids the lesson on recursion), nor the frame. As the only filesystem, the Journal is treated more like part of Sugar and less like an activity. As for the rest of them, I say let them do what they want. If someone else comes out with a web browser activity that's far superior to ours, who are we to force ours to remain in the frame? These are obviously the basic activities you mention, and I find it unlikely that a kid will want to get rid of these. If they do by accident, then it should be easy to get them back, either from anyone else in their class, or from whatever content repository we provide for downloading new activities.

What if we have a basic set of activities that appear on the frame, cannot be removed from there, and don't appear in the Journal? They could be Browse, Paint, Write, Record, Chat, ... the ones we consider are part of Sugar. Perhaps we could lock them on the left side of the frame and leave the right side for adding shortcuts to activities in the Journal. Some of the shipped activities won't be so integral to the Sugar experience.

While I agree these are the most important, I still think it defeats the idea if we special case our own activities. Maybe there are better versions available. Maybe they created a new version of a base activity themselves with custom features. Maybe, even though we think these are basic, some kids would rather have other activities in the first page of their tray. I think we need to trust the kids to manage this on their own, with the only backup being the ability to re-download the core activities from the school server if needed.

[Eben]

I think this spec is reasonably well defined. We can refine the interaction model once we have a basic implementation.

[marco]

Moving to FRS, we discussed this with Kim some weeks ago and decide it's not necessary for Trial-3.

[marco]

This is not complicated to implement but it's some work. Suggest keeping for 1.0 only if it's strictly necessary.

[Eben]

I think we can hold off until 1.1.

[marco]

Let's keep the Untriaged status until everyone had a chance to read and comment on these.

[Eben]

Obsoleted by the new Home view implementation (and favorites system).

[gregorio]

Milestone FutureFeatures deleted