Again, I have not been clear.
The intent in the 'backup restore' option is that Journal objects such
as Terminal and Log activities would be saved to a log directory on the
school server
and deleted from the local Journal (and so not appear at all). This
means the statistical benefits of recording everything would be retained
(where a school server is available) but the items would not clutter the
Journal View.
Tony
On 06/02/2016 08:01 PM, Sebastian Silva wrote:
El 02/06/16 a las 12:50, Walter Bender escribió:
On Thu, Jun 2, 2016 at 1:38 PM, Sebastian Silva
<[email protected]> 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.
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.
_______________________________________________
Sugar-devel mailing list
[email protected]
http://lists.sugarlabs.org/listinfo/sugar-devel
_______________________________________________
Sugar-devel mailing list
[email protected]
http://lists.sugarlabs.org/listinfo/sugar-devel
