[sugar] alt-tabbing to the Journal

[Robert Myers]

Erik,

> On Thu, Sep 25, 2008 at 11:43:57AM -0400, Robert Myers wrote:
>> Tomeu,
>>
>>> On Wed, Sep 24, 2008 at 10:26 PM, Erik Garrison <erik at laptop.org> wrote:
>>>> A thought which has come up a few times in my exploration of activity
>>>> switching performance, and a few times in conversations on the sugar
>>>> list, is that the Journal shouldn't be included in the set of activities
>>>> which can be alt+tab'ed to.
>>>>
>>>> The most compelling rationale is that there is already a dedicated
>>>> button on the keyboard for it (F1).
>>> This comes up regularly and I think we have a ticket where people are
>>> voting. I believe you can find the ticket if you search in this month
>>> archives.
>> Is this #6251? That's the only trac that I see that makes sense here.
>>
>> My 2c. Leave the Journal in the alt-tab ring. It's an activity. It
>> just happens to be an activity that's always running. Think of the
>> Finder on MacOS as a parallel example. 
> 
> The journal cannot be closed or saved.  It cannot be opened.  It's not
> an activity, but part of the shell, both in aspect and in
> implementation.
> 
>> Making it a special case that you have to use a special key to get to
>> is more confusing than leaving it on the ring.
> 
> An access path is also in the frame.
> 
> Every time you alt+tab unintentionally to the Journal you waste time and
> keyboard interaction.  This is why there is a dedicated key, to expedite
> the process of finding the Journal without necessitating that users see
> it when they don't want to.
> 
Task switching by alt-tab seems pretty quick to me. Thinking about and 
finding a different key to get Journal when you want it seems harder 
than tabbing past it when you don't.

>> Continuing down that path, I think that the launcher pane should be
>> treated more as just another activity, and also be on the alt-tab
>> ring. Maybe it should also have an icon on the frame.
> 
> Further still, every single view/window in the window manager---
> neighborhood view, launcher, and group view included--- could be on the
> alt+tab stack.  This would be conceptually very simple.  But because
> such windows can't be closed, users who aren't using them would have no
> choice but to navigate through them on their way to what they want.

I steered clear of the neighborhood and group view in this discussion 
because I don't have enough experience with using the XO in massively 
collaborative environments. The one time I had a significant friends 
lists was blown away several clean installs ago. I use the neighborhood 
view mainly to scan for WAPs. Someone who has more of a feel for XO 
workflows in collaborative environments can speak to this better. Maybe 
these windows stay out of alt-tab until they are accessed, and join the 
list once they have been.

The fact that they can't be closed doesn't make them inherently special. 
any of these functions could be implemented differently -- as an 
activity, and maybe sometime the user will have the option of how they 
want them to be exposed to them. We already have three different home views.

My basic view is that the frame, dedicated keys and alt-tabbing are all 
designed to give the same sort of functionality that we have in 
multi-window systems of easily cutting and pasting between activities, 
rolling through the running activities, and starting new ones when 
needed. As such, I think that the more capability that's exposed with 
alt-tabbing the better. If someone thinks point and click they can 
select the frame and the virtual buttons there. If someone thinks more 
with the keyboard they can use alt-tab. If someone thinks in discrete 
actions, maybe the dedicated keys are the best fit.

Bob