Re: interapplication communication

[Owen Taylor <otaylor redhat com>]

[ Reordering back into chronological order to reply ]

> Johannes Schmid wrote:
> > > Hi!
> > >
> > > I think you can/could even configure such a bottom panel in gnome-shell
> > > but it's kind of annoying because it takes up lot's of screen space.
> > >
> > > I am currently using gnome-shell on my netbook and it is really cool to
> > > have no second panel. Anyway, the top panel is mostly empty and that's
> > > annoying. I was proposing a task list like Ubuntu Netbook Remix is
> > > offering with icons only for the inactive application and the
> > > application name for the active.
> > >
> > > Anyway, I have the strange feeling that this list is more a discussion
> > > between users than between users and developers which is a bit sad. I
> > > would be really great if the core developers (Owen, Marina, etc.) would
> > > join this discussion more often especially in the way if and how they
> > > think some kind of task list could be useful. It seems that lots of
> > > people are really proposing it.

In terms of this week and last week, most of the full time GNOME shell
developers are on vacation, and in some cases entirely away from
computers. Yes, we don't post enough here even at other times.

Design is mostly Jon McCann's area. He's pretty swamped, but I prod him
to post more here fairly regularly; once he's back in January, he'll
hopefully have the chance to add in some more replies as he did earlier
this month.

In terms of a task list - I think *not having a task list* is one of 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?)

Once you are done working through that exercise, the result doesn't look
much like the current GNOME Shell; you've lost most of the things that
are distinctive about the current GNOME Shell design, and the result, it
seems to me, would look pretty much like other current desktops.

Now, the goal of GNOME Shell isn't to be something radically new and
different, it's to be a great user interface for GNOME 3, so maybe we'll
need to go ahead and make a big switch to something more conventional;
maybe the current ideas just aren't right. But we definitely want to
finish our current design ideas and get some experience with users
before we make such a move. (The message tray is probably the last large
remaining piece; we're hoping to get that landed next week.)

On Sat, 2009-12-26 Reiner Jung wrote:

> > I guess these discussions can become somewhat cumbersome for developers,
> > because they are largely on the same topics. I think it would be helpful
> > to distill a set of use-cases and a set of solutions for these use cases
> > on the basis of gnome-shell.
> >
> > I suggest that we collect ideas on this list for problems we have 
> > determined and send them our proposals. But to get features into the
> > shell we should not only propose them, but try to convince the
> > developers to like them (so they implement them).

Two things I'd encourage:

 - When documenting problems, be exceedingly specific; don't say
   "the new Alt-Tab makes it hard to switch between windows of 
   an application" rather say "When I'm writing an email in an
   Evolution composer window and want to switch back to the
   main Evolution window to look at another message for reference,
   I often find myself ending up in a different application"
   (or even more detail)
   
   Generalization from a specific problem to a generic problem often
   involves making an assumption about how the situation is best
   resolved.

 - The most interesting thing at the current time are incremental
   ideas - how could the ideas of the shell be extended or reworked
   to make them better? Such ideas are more interesting than
   complaints about how the shell isn't working. And they are
   more interesting than ideas that are massive changes in direction.

   If these ideas can be expressed in a few words that's better.
   IF they can be expressed visually, even better.

On Sun, 2009-12-27 at 00:33 +0100, Johannes Schmid wrote:

> OK, I created a page in the wiki, it lacks the solutions currently and
> has to be filled with more data of course:
> http://live.gnome.org/GnomeShell/UseCases

This page doesn't seem helpful in the current form; "Netbook" and
"Desktop Computer" are exceedingly general. Depending on how I'm using
my desktop computer, there are likely hundreds of pros to the current
GNOME Shell design and hundreds of cons.

I'd like to have a way of documenting "points of frustration" - what the
user was doing (very specifically) and how the shell was failing. But
I'm not really sure the best place to do that.

 - They might get lost in the noise in the mailing list

 - Wikis aren't very good for discussion

 - Bugzilla might be the best fit, but I'm reluctant to have bugs in
   Bugzilla that don't correspond to clear tasks - a patch to review,
   a specific change to make to match up with a mockup, a crash, etc.

I'll discuss this some with Jon when we are both back from vacation and
we'll see if we can come up with a good procedure.

- Owen