#43 closed defect (wontfix)
Mark activity as favorite when it's installed as a deb, rpm, etc
Reported by: | erikos | Owned by: | erikos |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Sugar | Version: | 0.82.x |
Severity: | Critical | Keywords: | |
Cc: | bkearney@… | Distribution/OS: | Fedora |
Bug Status: | New |
Description
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
Change History (14)
comment:1 Changed 15 years ago by bkearney
- Cc bkearney@… added
comment:2 Changed 15 years ago by mungewell
comment:3 Changed 15 years ago by 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
comment:4 follow-up: ↓ 6 Changed 15 years ago by 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.
comment:5 Changed 15 years ago by marcopg
We should really split this bug. 2 is really tricky and 1 is something we should urgently address.
comment:6 in reply to: ↑ 4 Changed 15 years ago by 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
comment:7 Changed 15 years ago by tomeu
- Bug Status set to Unconfimed
- Distribution/OS set to Unspecified
- Milestone set to 0.84
- Severity set to Blocker
- Summary changed from handle installation/uninstall of activities on systems where we use rpms/deps to Mark activity as favorite when it's installed as a deb, rpm, etc
comment:8 Changed 15 years ago by marcopg
- Bug Status changed from Unconfimed to New
- Distribution/OS changed from Unspecified to Fedora
- Version set to 0.82.x
comment:9 Changed 15 years ago by erikos
- Milestone changed from 0.84 to 0.86
- Owner changed from marcopg to erikos
- Status changed from new to assigned
comment:10 Changed 14 years ago by tomeu
- Severity changed from Blocker to Critical
don't see much interest in fixing this in 0.86, please comment
comment:11 follow-up: ↓ 12 Changed 14 years ago by 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
comment:12 in reply to: ↑ 11 Changed 14 years ago by 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?
comment:13 Changed 10 years ago by dnarvaez
- Resolution set to wontfix
- Status changed from assigned to closed
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.
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.