Mark activity as favorite when it's installed as a deb, rpm, etc

[erikos]

issue1: if we install an activity using yum the activity is not a favourite by default - and therefore does not show up in the favoritesview, but as well not in the activities list - only after a sugar restart.

issue2: we can not erase an activity from the menu, since they are placed in /usr/share/sugar/activities

[mungewell]

Issue 1: Can't the ability be set the in the activity.info file.

ie.
--
[Activity]
name = Chat
bundle_id = org.laptop.Chat
class = pippy_app.Chat
icon = activity-icon
activity_version = 60
mime_types =
show_launcher = yes <------------------- HERE
host_version = 1
update_url = ​http://dev.laptop.org/~morgan/bundles/chat
license = GPLv2+
--

Issue 2:

Having 'immutable' applications might be useful, certain things that can't be removed may be an advantage.

The question is whether they can be 'un-favourited' or cloned to provide a working/editable personal copy without removing the original from the system

Mungewell.

[bkearney]

Even if that is set, the files will not show up in this use case:

1) Start up sugar
2) Start terminal
3) Install RPM (which puts new activities into /usr/share/sugar/activities/
4) Go back to main desktop
5) Use activities as list.

I would like for 4 to work without a restart, but can live with 5. Today, I have to restart (reboot or ctrl-alt-delete) after step 3.

-- bk

[mungewell]

How does the browse activity notify the journal that a activity has downloaded? I'm guessing it sends a D.Bus message.

This could be done by a small script in the POST_INSTALL stage.

If the sugar session is not activity at the time the Journal should check for new activities on start up. We would want to ensure that the remove+install/replace process didn't override a user's choice to [un-]favourite an activity.

Mungewell.

[marcopg]

We should really split this bug. 2 is really tricky and 1 is something we should urgently address.

[tomeu]

Replying to mungewell:

How does the browse activity notify the journal that a activity has downloaded? I'm guessing it sends a D.Bus message.

No, the journal is listening for new entries in the DataStore and, among other things, install it if it's a bundle.

This could be done by a small script in the POST_INSTALL stage.

If the sugar session is not activity at the time the Journal should check for new activities on start up. We would want to ensure that the remove+install/replace process didn't override a user's choice to [un-]favourite an activity.

I would write a small python script that adds the activity to this json file: ~/.sugar/default/favorite_activities

[tomeu]

don't see much interest in fixing this in 0.86, please comment

[alsroot]

In my mind, its a downstream filed. If distro packages activities then it could use something like soas does:
​http://git.sugarlabs.org/projects/soas/repos/mainline/blobs/master/soas-sugar.ks#line63

[tomeu]

Replying to alsroot:

In my mind, its a downstream filed. If distro packages activities then it could use something like soas does:
​http://git.sugarlabs.org/projects/soas/repos/mainline/blobs/master/soas-sugar.ks#line63

But that wouldn't work while Sugar is running, so perhaps we still need to do something in Sugar before we can pass it to distros?

[dnarvaez]

If this has not been fixed in 5 years, I doubt it's useful to keep it around. The whole issue with deb/rpm vs xo is still quite undefined too.

[dnarvaez]

Milestone 0.86 deleted