Re: interapplication communication



Hi Owen!

> 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.

Actually, I wasn't expecting any updates during X-mas but this
discussion has been on the mailing list in different threads for quite a
long time. And this discussion doesn't result in anything unless people
doing the work will lead it in some direction.

> 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.)

Sure, user feedback is probably the most important point. (One of the
reasons that I didn't post here before having used gnome-shell for a
while).
Regarding the task list I am all against a button panel but I still
thinnk there needs to be a fast way to change the window (not
essentially the same as the task) using mouse only without the overlay.
If you read the archive you will see a lot of post dicussion various
ideas because people are very used to it, even those power-user
keyboards freaks.

Just another idea that poped into my mind: What about having the alt-tab
chooser as kind of dock that pops up when you move the mouse to the
buttom of the screen?

Thanks and regards,
Johannes


> 
> 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
> 
> 




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]