Re: Baking with BreadCrumbs

[Jon Nettleton <jon nettleton gmail com>]

On Mon, 2009-07-06 at 08:19 -0400, Dan Winship wrote:
> On 07/06/2009 05:11 AM, Jon Nettleton wrote:
> >> Can I still switch between windows (in a fixed order, not order of
> >> last use) by pointing and scrolling, as is possible with Gnome 2's
> >> window list?
> > 
> > Not yet, but it is something I plan on implementing for both windows and
> > workspaces.
> 
> FWIW, this "feature" confuses a lot of people ("I was scrolling in
> firefox and suddenly my windows switched around" [because they moved the
> pointer off the bottom of the window without noticing]) and there's some
> push to get rid of it in the normal taskbar.

I understand how it could be confusing in the current implementation.
With a large overlay showing up on the screen I believe that it will be
quite obvious what has happened.  I think the graphical feedback will
help solve the confusion in this case.

> 
> > I am also trying to integrate the same view for both alt+Tab and alt+ctl
> > +Tab.  alt+ctl+Tab is not a problem because it is a static linear path.
> > The behavior of alt+Tab is difficult because it mimics the window
> > stacking and is constantly changing.
> 
> Look at how Alt+Tab is currently implemented (mostly in
> src/shell-alttab.c and js/ui/altTab.js). You just need to rewrite
> altTab.js to use your UI rather than the standard one; the shell tells
> it the right order to put the windows in.
> 

Thanks for the tips, and I understand the implementation.  My confusion
is rather in the consistency of the actions.  Should I just use the same
"Drawer" to pop down and re-order the previews on alt+tab to reflect the
stacking order, or should I leave the previews stacked as they currently
are ( ordered as added to the workspace ) and make the alt+tab action
jump around in the order the windows are stacked?

The first option seems like the best to me with one draw back.  When you
alt+tab the drawer will look differently than when you click on the
window breadcrumb.  This could possibly be cleaned up by animating the
windows moving around into the stack order at the beginning of alt+tab.

The second option keeps the interface consistent, however there is no
indication as to the next window in the alt+tab order making it hard to
know how many tabs to hit to quickly get to your desired window via the
keyboard.  

I guess I am leaning to option 1 and adding the animations.  This should
give proper visual feedback of what is going on and still keep alt+tab
intact and useful.

Of course option 3 is to just leave alt+tab how it is. :-)

Jon