[sugar] Journal view "flips" topmost entries

[Eben Eliason]

On Tue, Aug 12, 2008 at 4:52 AM, Morgan Collett
<morgan.collett at gmail.com> wrote:
> On Tue, Aug 12, 2008 at 00:12, Eben Eliason <eben.eliason at gmail.com> wrote:
>> On Mon, Aug 11, 2008 at 4:51 PM, Mikus Grinbergs <mikus at bga.com> wrote:
>>> My guess is that "flipping" of the topmost entries in Journal has to
>>> do with "scheduling" rather than with "communications".  Though in
>>
>> I'm sure that what you are seeing results from the fact that the
>> Journal defers updating itself until its window is shown, to prevent
>> needless updates from occurring in the background and taking extra CPU
>> cycles.  It's unfortunate that the single update that occurs when the
>> Journal is focused has so much latency...this should really be
>> happening so quickly as to be unnoticeable.  There are a lot of pieces
>> of the Journal that could use some optimiation, among them the actual
>> rendering of the entries themselves when a change occurs (try
>> starring/unstarring and see how long it takes it to redraw to reflect
>> the change! (http://dev.laptop.org/ticket/7151)).
>>
>> That said, the circumstance you describe is truly not good; in fact,
>> without a confirmation alert upon deletion, this could might even be
>> considered a blocker.  Could you open a ticket describing the problem,
>> and note that adding a confirmation might be a valid short term
>> workaround to prevent accidental deletions? (Actually, just found
>> this: http://dev.laptop.org/ticket/3778.  Could you update this ticket
>> with your experience and perhaps add a blocks?:8.2.0 tag so it's
>> considered?)
>>
>> Clearly we need to this and also plenty of optimization in the future.
>>
>> - Eben
>>
>> PS.  If you truly are seeing the flip apart from the first time the
>> Journal is shown, there is something else amiss.  Please keep an eye
>> out and confirm one way or the other if you actually experience such
>> behavior.  Thanks!
>
> I see the flipping - it's easy to reproduce. With two open terminals
> (named differently) if I just hit alt-tab from the Journal, to the
> first terminal, and without releasing alt I hit tab again to the
> second terminal, and then tab again to the Journal, I get a momentary
> flip.

This sounds wrong (well, over-aggressive) to me.  While the Journal
does maintain recent-on-top ordering of entries, this shouldn't be
reflected at the granularity of activity switches.  Instead, it should
be at the granularity of saves.  It's quite possible that this is in
fact the case, and that these activities are saving every time they
lose focus; if that's the case, we need to implement a dirty bit
paradigm ASAP which prevents activities from needlessly saving
themselves all the time.

Better still, we might implement logic which brings an entry to the
top of the list when it is resumed (or started), and then mostly
ignoring its ordering until it is stopped again, at which point it is
brought to "the top" just beneath the entries for activities which are
still running.  In this manner, we can be satisfied by maintaining an
ordering in which all running activities are in somewhat arbitrary
order on the top, and all non-running entries are ordering by
stop-time below them.

- Eben