Opened 14 years ago

Closed 14 years ago

Last modified 11 years ago

#1512 closed defect (fixed)

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

Reported by: FGrose Owned by: alsroot
Priority: Unspecified by Maintainer Milestone:
Component: journal Version:
Severity: Unspecified Keywords: Usability design r+ dextrose
Cc: alsroot, tch Distribution/OS:
Bug Status: New

Description

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.

Change History (16)

comment:1 Changed 14 years ago by FGrose

  • Bug Status changed from Unconfirmed to New
  • Distribution/OS Trisquel deleted
  • Version 0.86.x deleted

Confirmed in Sugar 0.88.x

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

comment:2 Changed 14 years ago by garycmartin

  • Cc alsroot added

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.

comment:3 in reply to: ↑ description Changed 14 years ago by 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.

comment:4 in reply to: ↑ description Changed 14 years ago by tch

  • Cc tch added

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.

comment:5 in reply to: ↑ description ; follow-up: Changed 14 years ago by 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.

comment:6 in reply to: ↑ 5 Changed 14 years ago by 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.

comment:7 Changed 14 years ago by tch

  • Keywords r? dextrose added

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

comment:8 Changed 14 years ago by tomeu

  • Component changed from sugar to journal
  • Owner changed from tomeu to alsroot

comment:9 Changed 14 years ago by tomeu

  • Keywords r+ added; r? removed

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

comment:10 Changed 14 years ago by erikos

Can the commit be referenced and the ticket be closed?

comment:11 Changed 14 years ago by erikos

Ping?

comment:12 Changed 14 years ago by erikos

  • Milestone changed from Unspecified by Release Team to 0.90

comment:13 Changed 14 years ago by tch

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:14 Changed 11 years ago by dnarvaez

  • Milestone 0.90 deleted

Milestone 0.90 deleted

Note: See TracTickets for help on using tickets.