[Sugar-devel] Stateless activties (was Re: Fw: #3013 UNSP: toolbar error)
Walter Bender
walter.bender at gmail.com
Fri Aug 5 18:37:37 EDT 2011
On Fri, Aug 5, 2011 at 6:16 PM, James Simmons <nicestep at gmail.com> wrote:
> Gary,
>
> You have given me something to think about. The idea of every Activity of
> the child leaving behind a record of what the child has done is fine. The
> problem is, the user interface of the Journal does not really support it.
> When an Activity finishes it might prompt the child to record some
> description of what he did. After that, the child may not see that
> description again. If you don't know where to look for it, it might as well
> not be there at all. Nor is there any indication in the Journal design that
> there is something to look for.
>
> One thing Sugar Commander does is make all the metadata for a Journal entry
> visible. Anyone using that Activity knows that there is a screen grab for
> the Activity as well as a Description, Keywords, etc.
>
> I've been thinking about what to do with this Journal entry if Sugar
> Commander starts leaving one behind. My though is to make a human-readable
> log of what the child did with the Activity with time stamps. Copied this
> file to the Journal. Deleted this Journal entry. Changed the title of an
> entry from "a" to "b". I would put this log in the Description metadata
> where it can be read in the Journal entry, rather than in the file for the
> Journal entry.
>
> I could do something similar for Get Internet Archive Books.
>
> I'll try and find time this weekend.
>
> James Simmons
Not to keep beating the same drum, but...
(1) it has been several years since Sugar has switched to the
reopen-by-default mode on the home page, so the issue of Journal spam
from activities that have nothing to write to the Journal is almost
moot.
(2) we have several activities, including the Portfolio activity, that
are designed to draw upon the Journal entries to make presentations of
the learner's work, so in fact, the entries they are creating are not
for nothing.
-walter
>
> On Fri, Aug 5, 2011 at 4:49 PM, Gary Martin <garycmartin at googlemail.com>
> wrote:
>>
>> On 4 Aug 2011, at 15:23, James Simmons <nicestep at gmail.com> wrote:
>>
>> I am in favor of supporting stateless Activities.
>>
>> -1
>> Journal entries are not just old school save files. They are a log/journal
>> of what the child has been doing, even if that didn't lead to explicit state
>> storage. Activities that do not stave state often generate upstream bug
>> reports and confusion, "I've run this activity before, why is the home
>> activity icon still grey?" "Why is there no record of my previous uses of
>> it." type thing.
>>
>> There are too many good use cases for them to not support having them.
>>
>> I'm not convinced. I think it's just that some activity developers haven't
>> though about this Sugar feature enough, or haven't implemented planned
>> features/enhancements (my Moon activity is a good example, it does save
>> state, but is very limited currently). I'm always disappointed when I find
>> an activity not trying to store some useful state.
>>
>> The Log Activity is a good example. There is no much point in having a
>> Journal entry for Log. Old Journal entries do not point to old logs. (If
>> they did there might be some point to having them, I suppose).
>>
>> Activity authors should be thinking about keeping useful state as part of
>> their design process. It would be great if Log journal entries kept the log
>> state so I could easily look back at previous errors after rebooting. Even
>> as it is now I occasionally write some testing notes in the description
>> field for later reference (often I copy/paste a traceback out of one of the
>> actual log files so I can find it later), if the Log entries are now
>> disabled in the next release I'll have to start copying and pasting into
>> Write to keep a record :(
>> Regards,
>> --Gary
>>
>> Games might do better to save state information in the data directory
>> rather than create a Journal entry, if the state is nothing more than high
>> scores.
>>
>> The parameter in the __init__() method looks like it has been there from
>> the beginning of Sugar.
>>
>> I don't mind changing the book if that is what needs to be done, but I
>> think the trick documented in the book is worth preserving.
>>
>> James Simmons
>>
>>
>> On Thu, Aug 4, 2011 at 1:07 AM, James Cameron <quozl at laptop.org> wrote:
>>>
>>> On Thu, Aug 04, 2011 at 10:27:09AM +0500, Sebastian Silva wrote:
>>> > I just tried Log activity, it does create a Journal entry by default.
>>>
>>> This has since changed. As I said, look at the Log activity source ...
>>> sorry I wasn't explicit enough ... in the git repository.
>>>
>>> Specifically,
>>> http://git.sugarlabs.org/log/mainline/blobs/master/logviewer.py#line329
>>> is where the activity instructs Sugar not to create a Journal entry by
>>> default.
>>>
>>> And,
>>> http://git.sugarlabs.org/log/mainline/blobs/master/logviewer.py#line511
>>> is where a Journal entry is created as a result of user action.
>>>
>>> Sorry nobody has released a new version of Log yet. That might be a
>>> good idea.
>>>
>>> > So I wonder, is the workaround described in the book supported?
>>>
>>> Well, I don't know about supported, but it clearly doesn't work. Let's
>>> find out why and get it fixed, or changed. That is, in Sugar or the
>>> book. Books are code too, but they are slightly harder to change.
>>>
>>> --
>>> James Cameron
>>> http://quozl.linux.org.au/
>>> _______________________________________________
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
More information about the Sugar-devel
mailing list