Re: [Sugar-devel] [DESIGN] not uninstall when a .xo bundle is deleted from the journal (was Re: Journal and Updating Software Process)
Hi Daniel, On 2 Aug 2010, at 05:05, Daniel Drake d...@laptop.org wrote: On 1 August 2010 08:20, Tomeu Vizoso to...@sugarlabs.org wrote: long time ago we decided that when an activity bundle was removed from the journal, it should also be uninstalled. There's a report from Uruguay about teachers not expecting this and considering it a bug. Regardless of user experience it is a bug because it forces you to have the .xo zip file in your journal as well as uncompressed on the disk. It is a design mistake rather than bug (regression?), but yes having to hold onto a downloaded .xo to keep the activity installed is pretty critical mistake, especially when we have a few ported monster activities kicking around out there that were never designed to be used on such resource limited devices. What are people's opinions on requiring two separate steps to delete an activity bundle from the journal and uninstalling it? I think this separation makes sense within the current design (the journal has the downloaded file and the history, but the activity is a separate entity on the disk which does not necessarily appear in the journal), is currently the less confusing option, and solves the disk space bug. So I think we should apply the simple fix for now, remaining open to new implementations for activity management as and when they appear. +1, given our current resources, I can't imaging making the major progress that's needed here, in the short term at least. Regards, --Gary Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] not uninstall when a .xo bundle is deleted from the journal (was Re: Journal and Updating Software Process)
Re: [Sugar-devel] [DESIGN] not uninstall when a .xo bundle is deleted from the journal (was Re: Journal and Updating Software Process) When renaming discussion threads, it is sometimes appropriate to provide a link to the earlier thread so that previous discussion is more readily available. Here, for example, http://lists.sugarlabs.org/archive/sugar-devel/2010-July/025678.html or here, http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg15220.html, where some (but not always all) of the thread tree is revealed at the bottom. On Sun, Aug 1, 2010 at 10:20 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Hi, long time ago we decided that when an activity bundle was removed from the journal, it should also be uninstalled. There's a report from Uruguay about teachers not expecting this and considering it a bug. What are people's opinions on requiring two separate steps to delete an activity bundle from the journal and uninstalling it? Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] not uninstall when a .xo bundle is deleted from the journal (was Re: Journal and Updating Software Process)
On 1 Aug 2010, at 15:20, Tomeu Vizoso to...@sugarlabs.org wrote: Hi, long time ago we decided that when an activity bundle was removed from the journal, it should also be uninstalled. There's a report from Uruguay about teachers not expecting this and considering it a bug. What are people's opinions on requiring two separate steps to delete an activity bundle from the journal and uninstalling it? Unless we can agree on the Journal becomes the place to manage bundles — something I thought was a future desire/hope — I'd vote for separating Journal bundle deletion from the activity uninstall step. However, we have UX reports from deployer/deployments that home list view is confusing users (they think they are in the Journal; they are expecting the home ring and are now lost). One obvious solution (Walter already raised this) would be to remove list view and manage activities from the Journal. All installed activities would need to show up in the Journal for management, we'd need an obvious way to quickly filter for them, favourite/un-favourite them, and add the various safeguards to prevent their unintentional/unwanted erasure. There's at least one deployer who seems strongly against this use of the Journal each time it is raised (argument is if the user didn't create it, it shouldn't be in their Journal). Regards, --Gary Thanks, Tomeu On Wed, Jul 28, 2010 at 16:02, Daniel Castelo dcast...@plan.ceibal.edu.uy wrote: On Tue, Jul 27, 2010 at 11:51 PM, Frederick Grose fgr...@gmail.com wrote: On Tue, Jul 27, 2010 at 9:37 PM, James Cameron qu...@laptop.org wrote: On Tue, Jul 27, 2010 at 06:37:18PM -0300, Daniel Castelo wrote: * The activities are updated With Software update or manually using Browse? * The user delete the journal entry with the activity bundle downloaded for this updating process. The result of this is that the activity is deleted from sugar I've seen this on Sugar 0.84 if the activity was updated using Browse, but not if the activity was updated using Software update. This behavour is normal? Should I reported this as a bug? If you think it is a bug, then check for it in bugs.sugarlabs.org See https://bugs.sugarlabs.org/ticket/1512 Great. Thanks! The trac ticket suggest a new behavour: 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. Which is the next step that I should follow to solve this issue? I suposse that is to discuss in this email list which could be the best solution. or report it there. I'm not sure what the behaviour should be. I'd be happy to see it fixed though, so that a user would have to both remove the download and remove the activity. -- James Cameron -- Ing. Daniel Castelo Plan Ceibal - Área Técnica Avda. Italia 6201 Montevideo - Uruguay. Tel.: 601.57.73 Interno 2228 E-mail : dcast...@plan.ceibal.edu.uy ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] not uninstall when a .xo bundle is deleted from the journal (was Re: Journal and Updating Software Process)
If you download a big activity (like Wikipedia), you have a lot of space used in the journal and you can't delete without uninstalling the activity. Gonzalo On Sun, Aug 1, 2010 at 11:20 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Hi, long time ago we decided that when an activity bundle was removed from the journal, it should also be uninstalled. There's a report from Uruguay about teachers not expecting this and considering it a bug. What are people's opinions on requiring two separate steps to delete an activity bundle from the journal and uninstalling it? Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] not uninstall when a .xo bundle is deleted from the journal (was Re: Journal and Updating Software Process)
On 1 August 2010 08:20, Tomeu Vizoso to...@sugarlabs.org wrote: long time ago we decided that when an activity bundle was removed from the journal, it should also be uninstalled. There's a report from Uruguay about teachers not expecting this and considering it a bug. Regardless of user experience it is a bug because it forces you to have the .xo zip file in your journal as well as uncompressed on the disk. What are people's opinions on requiring two separate steps to delete an activity bundle from the journal and uninstalling it? I think this separation makes sense within the current design (the journal has the downloaded file and the history, but the activity is a separate entity on the disk which does not necessarily appear in the journal), is currently the less confusing option, and solves the disk space bug. So I think we should apply the simple fix for now, remaining open to new implementations for activity management as and when they appear. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
