Hi.
First of all: thanks for the feedback.
Most of your points are design questions, so I am not the most qualified
person to answer them.
El sáb, 19-06-2010 a las 13:18 +0200, Niels L. Ellegaard escribió:
> It would be nice to have a simple and visible way to disable
> gnome-shell animations. Perhaps the animations should be disabled by
> default.
Animations are generally considered helpful clues to indicate what's
going on - nothing pops out of nowhere in real life, "effects" like
moving or fading or dimming on the other hand are very common. I don't
think we are overdoing it in the shell, but then I'm hardly objective on
the matter. It might make sense to give users the possibility to tweak
the animation speed (slow, normal, fast), but I doubt there will be an
off switch.
But if you want to play around a little, most animations can be tweaked
with a debug variable (it's intended use is to slow down animations for
debug purposes, but there's no reason you can't use it to accelerate
them):
1. Use Alt-F2 to launch the run dialog
2. Enter 'lg'
3. In the window which slides down, enter 'Tweener.slowDownFactor=x',
with x being a positive float, e.g. x=0.5 will double the animation
speed
> It would be nice to have more meta data describing each program. If
> I search for a string such as "calendar", "schedule" or "appointment"
> or "date" then I would like to find evolution-calendar. If I search for
> a part of a mime-type such as "ogg" and "excel", then I would like to
> find the programs that can handle the given mime-type.
Yes, definitively. The problem here is that we need the right data to
search in - desktop entries don't contain keywords, which would probably
come closest to what we want. Mime types have the problem that there are
a lot of them, and many are not at all obvious: "zoo" matches
file-roller, because there happens to be an obscure format of that name,
"star" matches Open Office, because it still supports formats from more
than a decade ago when it was owned by a company named StarDivision, ...
> I like the idea of having 6 visible application icons in the
> activities menu, but it is confusing that these 6 icons are a mixture
> between a favorite list and a kind of windows list. The icons
> corresponding to running programs disappear when I close the program,
> but the favorites do not disappear when I close the program. That leaves
> an impression that gnome-shell is somewhat unpredictable.
It doesn't appear to be that much of a problem on other platforms - the
dock in OS X and Windows7 (though the latter probably calls it something
else) behave pretty much the same way.
> If I right click on one of the 6 application icons then I get a menu that mixes up
> configuration behavior (changing favorites) with navigation behavior
> (find a running instance of a given program). I find that confusing.
Mmmh - does "perform an action on the application (pin it to the app
well, switch to a specific window, ...)" make more sense? Can the
current menu be refined to make this more clear?
> I am afraid of pressing a menu entry that adds
> or removes a favorite.
You should try it though - seriously ;-)
> If you train new users to use the 6 icons in the activities menu as a
> windows switcher then they may run in to problems as soon as their
> browser creates two windows. The problem is that new users will not
> automatically guess that they have to use the right click menu to find
> the hidden browser window.
Oh my, there isn't actually a limit on six icons - apparently there's
some weird bug here.
But back on topic - the app well is an application switcher rather than
a window switcher. Again, the concept is hardly new, it is very close to
a dock - and users seem to be able to deal with other docks just fine.
There are certainly users who have trouble with right-click menus - but
most of the actions it offers can be performed equally well without the
menu - windows can be selected in the window selector, and favorites can
be added with DND.
> Of course some vision imparted users will find fit
> distinguish be between the windows in the window selector, but perhaps
> you can solve this by placing icons on top of the programs on top of the
> windows in the workspace selector. (Place a firefox icon on to of the
> firefix window... etc.)
We actually did this - it was removed at a later point[1] on designers'
request; I only remember vaguely what their arguments were, so it's
probably best to ask them instead. Apparently you are not the first one
to be unhappy with the decision[2], so maybe the design needs some
further refinement here.
> If the activities menu is open then I cannot press an icon to open
> a minimized program such as empathy, gnotes, or
> gnome-xchat. Ideally pressing an icon on the menu bar should close the
> activities dialog. (Omar suggested that this was a gtk issue)
It's not really a gtk issue (e.g. qt won't help us here), but it is
indeed a technical limitation. The planned behavior is to have the icons
work normally, not to leave the overview (though it is also planned to
reserve that space to system status icons[3] - network, battery,
volume, ... - so all those icons you mention as examples will eventually
move elsewhere).
> I don't think that users should be allowed to use the workspace selector
> to close a running program. I think that the danger of closing a
> program by mistake is too high. If a user makes this mistake once, he
> may gain a lasting mistrust to the workspace selector.
I find it hard to believe that you can hit this button by accident
(although it supposedly has happened [4]). Doesn't the same argument
apply to the "normal" close button outside the overview as well? Is
there anything we can do to make it less likely to click the button by
accident?
> Between the activities menu and the clock I found a widget displaying
> the name of the window that is presently open. Maybe this widget work in
> progress, but right now it is not so useful.
True, it's not too useful right now - eventually it will contain options
which apply to the application as a whole (not a single window). This
cannot be achieved without support in the applications themselves - the
necessary API is in the process of being integrated into GTK right now.
> Maybe it would be better to place a window list or a list of active
> programs here. If you are afraid of using too much space, then you can
> remove the text and just put the icons corresponding to the active
> windows.
There won't be a window list/dock in GNOME Shell. Sorry to be grumpy
here, but the whole topic has been beaten to death already - repeatedly.
> I would like the calendar dialog to contain information from
> evolution calendar and evolution tasks.
Everyone seems to agree, but no one has stepped in to do the work -
first step probably being adding introspection support to
evolution-data-server ...
> The menu in the upper right corner has an IM-icon and it allows me
> to set my IM-status, but it doesn't allow me to send an IM-message. I
> find that confusing.
The icon is meant to represent the user's status, which is not limited
to IM (e.g. setting the status to "busy" should[5] block non-urgent
notifications from popping up). While the shell has some chat
integration, it is not meant to be a full-blown client. However, as we
expect applications like empathy to not show a status icon when running
in the shell (because it should follow the user status of the session),
your question about _initiating_ a chat is pretty valid. There may be a
design answer to this already, I don't know.
> The workspace selector applet of gnome 2.28 provides graphical
> information telling which program is opened in which workspace. This
> information is always visible, so I do not have to press any buttons to
> get it, and that allows me to use ctrl-alt-left/right very
> effectively.
Well, unless you are a one-application-per-workspace kind of person, the
switcher will only tell you about the active window. It doesn't help
much either if an application is opened on more than one workspace.
Don't get me wrong - the switcher applet is not bad. It's just that
there's only so much you can do within a height constraint of 16px. The
overview is much more powerful, at the "cost" of being hidden most of
the time - I don't think that's actually a problem for most users, but
it shouldn't be too hard to code some kind of workspace indicator
extension. It doesn't make much sense for the core shell though.
> I hope that this mail was not too much of a rant.
Not at all - I'd say it was rather civilized and constructive, even by
non-internet terms :-)
Back hacking now ...
[1] https://bugzilla.gnome.org/show_bug.cgi?id=598324
[2] https://bugzilla.gnome.org/show_bug.cgi?id=615361
[3] http://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus
[4] https://bugzilla.gnome.org/show_bug.cgi?id=608955
[5] "should" as in "not implemented yet"
Attachment:
signature.asc
Description: This is a digitally signed message part