RE: interapplication communication

[Owen Taylor <otaylor redhat com>]

On Mon, 2010-01-04 at 16:27 -0500, Mark Curtis wrote:
> > > One thing I will say though - Owen, you say you're dead set
> against
> > > having a static list of the existing windows
> > 
> > I did not say that. I said:
> > 
> > - Adding a task list to the current design does not make sense
> > *in isolation*.
> > 
> > - We want to do user testing with the current design (including the
> > message tray) and are unlikely to make any big changes without
> > reference to that.
> 
> What do you mean by the caveat "in isolation"?

That was described in considerable detail in my original mail:

| In terms of a task list - I think *not having a task list* is one  the
| defining characteristics of the current design. Once you add something
| like a task list or a dock, many other aspects of the design have to
| change:
|
| - If the task list or dock goes at the bottom of the screen, where
|   does the message tray go?
|
| - What happens to the favorites well? It's essentially a dock, so
|   does it go away? (to avoid confusion and duplication)|
|
| - If the favorites well goes away, then the overview is no longer
|   the central destination to "switch to doing something else".
|   Does that mean that we should try to move recent documents to
|   the main screen as well? (An item on the dock?)

>  Also when/where/how is this user testing I keep seeing mentioned?
> 
Jon has already done some early testing with (non-programmer) users
around the Red Hat office here; he expects to do more of this this
month, likely in conjunction with Maírín Duffy. If you want to help
out, find Jon on IRC (nick 'mccann')
> 
> > > but I for one need a visual reminder of what windows I've got open
> > > for the current activity - it helps focus my mind on what I'm
> doing,
> > > what information I have available to me, what I need to do next,
> etc. 
> > 
> > One of our big problems with the task list going in was that we
> didn't
> > feel it did that; window titles get abbreviated beyond
> > comprehensibility, titles for tabbed windows aren't meaningful, it
> > doesn't scale beyond 5-6 windows, and so forth. These are some of
> the
> > reasons that Windows 7 moved from a window list to an application
> list,
> > and are things that we are trying to address with the overview.
> 
> But the main problem with the overview as opposed to Windows 7 or OS X
> is that it requires user interaction.
> By default, without user interaction, a person can see what programs
> are running in Windows 7, OS X, GNOME 2.X, KDE, etc

In OS X, the indication of what programs are running is normally very
subtle - if the program is already on the dock, a shiny blue dot is
added under it the dock. (And running apps might not have windows open,
so it's even less of an indication of what you are doing.)

I forget the exact feedback mechanism for running apps in Windows 7,
but it's on the same order.

> This is currently not the case with GNOME Shell.  Also no matter what
> sort of changes are done to the overlay the point is that it needs to
> be activated in the first place.
> 
It's meant to be very fast to activate the overview - you just slap
your pointer into the corner, then back to select the window.

> I do find it interesting you mention "window titles get  abbreviated
> beyond comprehensibility..." and yet in the applications menu of the
> overlay there are STILL truncated applications names (which also
> obscure the blue dots)

Clearly the ellipsized application name problem is an issue, which we
need to fix; the main mechanism for that requires distribution help - we
need to say "Firefox" not "Firefox Web Browser", and so forth.
But how is that related here?

The "glow" is intentionally under the application name.

- Owen