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 > > _______________________________________________ gnome-shell-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-shell-list
