Erasure of downloaded Activity entries in Journal permanently removes the code bundle

[FGrose]

This behavior in the Journal is inconsistent with other 'installed' Activities, which are erased (un-installed) with a warning dialog from the Home list view.

Additionally, when one erases an updated Activity from the Home list view, it is not permanently erased as the code bundle referenced in the Journal download entry is still available.

These peculiarities in this design lead to confusion and might better be hidden or reconciled.

The download event record, as a system event, might have a 'hide event' option or not be erasable. The code bundle behind the event should, perhaps, only be erased from the Home list view (installed-Activity-code-bundle management), while system or Activity events and their associated object instances are managed from the Journal of Activity event instances.

The value of the gray/colored Activity icon distinction is made evident in this situation. The colored icons in the GCompris suite should have another dimension or element to distinguish the two object types. Perhaps the gear icon could be used as a small decoration for all code bundles icons in Sugar.

[FGrose]

Confirmed in Sugar 0.88.x

See this discussion thread,  http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg15220.html

[garycmartin]

I vaguely remember Aleksey fixing something in this area due to some other issue/bug. Part of the confusion is that at one point it was hoped that bundles could be left compressed, and run without expanding their content, thus making the Journal entry and 'installed' activity the one and the same entity. I think currentlt if possible, the delete Journal entry and de-install activity hook should be removed to prevent accidental deletions while removing Journal entries. Users could then keep downloaded bundles if they wanted to re-install at a later date (I.e. they want to play with the code and have a way to recover); or keep the bundle if they wanted to share it with others (I.e a teacher downloads a bundle to their Journal while on the internet and then shares the Journal entry locally with the class); or if short of space they could delete the bundle without fear of de-installing the working activity.

[garycmartin]

Replying to FGrose:

The value of the gray/colored Activity icon distinction is made evident in this situation. The colored icons in the GCompris suite should have another dimension or element to distinguish the two object types. Perhaps the gear icon could be used as a small decoration for all code bundles icons in Sugar.

These GC activity icons really need to be fixed... Having just one incorrectly coloured sugar icon breaks the design metaphor pretty seriously and I've seen many confused comments/emails about it. One long term Sugar tester (for over a year) completely missed the meaning of the Sugar coloured icons due to having jus one such activity installed.

[tch]

Replying to FGrose:

This behavior in the Journal is inconsistent with other 'installed' Activities, which are erased (un-installed) with a warning dialog from the Home list view.

I agree with this. In the practice it gets very confusing for everyone, mostly because there is no warning at all.

I really do not share the idea of bounding the installed activity with the bundle that it was used for "installing". In the practice (again) the current behavior just produces an unnecessary storage space waste (mostly because there could be many bundles in the journal for the same activity).

The solution I found for this issue is jut not to delete de installed version. Please see the attachment.

[alsroot]

Replying to FGrose:

This behavior in the Journal is inconsistent with other 'installed' Activities, which are erased (un-installed) with a warning dialog from the Home list view.

Additionally, when one erases an updated Activity from the Home list view, it is not permanently erased as the code bundle referenced in the Journal download entry is still available.

These peculiarities in this design lead to confusion and might better be hidden or reconciled.

The download event record, as a system event, might have a 'hide event' option or not be erasable. The code bundle behind the event should, perhaps, only be erased from the Home list view (installed-Activity-code-bundle management), while system or Activity events and their associated object instances are managed from the Journal of Activity event instances.

The Zero Sugar tries to reconcile this from scratch, i.e., every activity will be identified by http url, there will be no need to download .xo if user wants to have activity launcher in F3 list (activity code will be downloaded on the first launch). Activity implementations will not be stored in journal. imo, trying to reuse journal for not trivial cases like packaging is overkill.

The value of the gray/colored Activity icon distinction is made evident in this situation.

In Zero Sugar case, it will mean that some activities are downloaded, some not yet.

The colored icons in the GCompris suite should have another dimension or element to distinguish the two object types. Perhaps the gear icon could be used as a small decoration for all code bundles icons in Sugar.

In case of GC, looks like it was not not good idea to have all 100+ GC components as activities. There is already single GC bundle on ASLO and maybe we just need to remove per-component activities later.

[alsroot]

Replying to alsroot:

Replying to FGrose:

This behavior in the Journal is inconsistent with other 'installed' Activities, which are erased (un-installed) with a warning dialog from the Home list view.

Additionally, when one erases an updated Activity from the Home list view, it is not permanently erased as the code bundle referenced in the Journal download entry is still available.

These peculiarities in this design lead to confusion and might better be hidden or reconciled.

The download event record, as a system event, might have a 'hide event' option or not be erasable. The code bundle behind the event should, perhaps, only be erased from the Home list view (installed-Activity-code-bundle management), while system or Activity events and their associated object instances are managed from the Journal of Activity event instances.

The Zero Sugar tries to reconcile this from scratch, i.e., every activity will be identified by http url, there will be no need to download .xo if user wants to have activity launcher in F3 list (activity code will be downloaded on the first launch). Activity implementations will not be stored in journal. imo, trying to reuse journal for not trivial cases like packaging is overkill.

I.e. there will be only one place where activities live, in F3 view (or in its analog). For now, we have natively installed activities (represented in F3 but w/o chances to remove), installed from .xo (also represented in F3 view), .xo in journal.

[tch]

Maybe the maintainer could consider my patch as a temporal fix until all those features are fully complete and working? :)

Please also review:
Protected activities patch;  http://bugs.sugarlabs.org/ticket/2087
Delete profile data when removing activities:  http://bugs.sugarlabs.org/ticket/2074

[tomeu]

This patch has been pushed, please close this ticket if nothing else remains to be done.

[erikos]

Can the commit be referenced and the ticket be closed?

[erikos]

Ping?

[tch]

The patch has been already pushed, but I attach the patch with the ticket reference just for the record.