[Sugar-devel] [DESIGN] Name object on Activity exit revisited

Walter Bender walter.bender at gmail.com
Thu Jun 2 14:14:53 EDT 2016


On Thu, Jun 2, 2016 at 2:01 PM, Sebastian Silva <sebastian at fuentelibre.org>
wrote:

> El 02/06/16 a las 12:50, Walter Bender escribió:
>
>
>
> On Thu, Jun 2, 2016 at 1:38 PM, Sebastian Silva <
> <sebastian at fuentelibre.org>sebastian at fuentelibre.org> wrote:
>
>> Not every time you do an activity are you doing work worth committing.
>> For instance I work with a lot of terminals, that I reuse and there's no
>> point in committing terminal sessions.
>>
>> So imho Sugar should not force you to commit if you don't want to.
>>
>
> We had long ago talked about letting some activities opt out. Regardless,
> adding the commit message back with an opt-out button is fine with me, but
> I still don't understand what problem we are solving.
>
> Good question. I hope Tony can answer that. If I understood him correctly
> he's trying to avoid having many journal objects currently having exactly
> the same name thus being indistinguishable from each other.
>

As I mentioned in a separate thread, I think we need to think more w
holistically about multiple users on a single Sugar instance. There are
many solutions that come to mind. Why not have a way of selecting which
user is active and making Journal entries that way?


>
> If I understand it, Tony also wants to circumvent the relaunch last
> instance by default as well. In the case of your Terminal example, it would
> mean you'd have Terminal instances in your Journal for each time you used
> the Terminal unless you too the time to go to the Journal and search for a
> previous instance. I think that makes the spam problem worse, not better.
>
> I tend to agree with you on that one. Tony makes a valid point that Sugar,
> more often than not, is used by many learners who may not expect to open
> somebody else's work by default.
>
> Just a detail in your conclusion, is that, by having a `don't commit`
> option, I would have probably no journal objects at all for Terminal.
>

So you would want to let the user explicitly not save the state of the
Terminal, e.g. history, CWD, etc.? Not sure why, but in any case, this will
probably require deleting the entry somehow on exit, since the entry is
created long before the exit dialog.

-walter

-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
<http://www.sugarlabs.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160602/5759f50e/attachment.html>


More information about the Sugar-devel mailing list