Il giorno gio, 25/11/2010 alle 19.44 +0530, dE . ha scritto: > Finally the doc is complete, the devs/designers might like to have a look.
Ok, first of all, despite the tag on my bugzilla account, I'm not a gnome-shell developer, rather a contributor, I have no official stance on what will/will not be part of gnome-shell, now or in the future. So the following is all IMHO: Let's start with the problems: 1) Ok, we have a problem with fast window switching. I reported that as gnomebug 635527. It goes a long way detailing why and when a user needs, or should need, to change a window, and is pending input from designers on what UI is the best to achieve this. (Similarly, there are bugs for changing the alt-tab behavior and make it more intuitive) 2) There is no better than the Shell in maximizing the space available for windows: the only panel taking space is the top one, whereas in GNOME 2 you have a top one and a bottom one. That's 24px more space, in gnome-shell. 3) Previews of what is happening on all workspaces will be back soon, with the second iteration of the overview-relayout introducing the workspace sidebar on the right. Of course, this kind of "summary" belongs logically to the Overview, because when you're inside the workspace, all the attention should be on the current task, not on the background. Also, you should expect asynchronous notifications of background tasks to come through the notification area, so that nothing requires you to interrupt your workflow. 4) The application picker is not finished, I suppose. The mockups in gnome-shell-design show application categories on the right, which would make this moot. 5) This is not possible. After all, we did learn how to use our computers when we started, and we did learn the differences between GNOME, KDE, Mac or Windows. If the user is not open to the change, it will not change, and keep GNOME 2, no matter how clean, efficient, polished, ergonomic and working is GNOME Shell. On the other hand, it is possible to make the shell more intuitive. But then, the top panel is intuitive: it is a menu bar, a concept the user knows, with two main buttons (beyond user menu, status icons and the clock). One is the application menu, and the user will learn this as soon as it clicks it (and yes, it is the first instinct you have with that), and be no more concerned. The other opens the Activity Overview, which is also very intuitive: on the left you find launchers and open applications, clearly distinguished; in the center you find your desktop, recognizable by the background, or if you want applications, just click exactly "Applications". Nothing else is required to use the shell (advanced features like the hot corner, the alt-tab, the message tray, etc. are discovered while using). 6) Clicking in window thumbnails is instantaneous (providing for rendering bugs...), same is clicking in active apps. For inactive apps, of course you need to wait for the app to launch. So, no problem here. Now on to the proposals. Note though that similar problems call for different solutions in different situations. If gnome didn't want to be different than competition, it would have kept gnome-panel; instead, they are trying innovative answers to the same questions. 1) Widgets and docking: Please no! This is not KDE, and neither this is Enlightment. We don't need exaggerate flexibility, we want reasonable and workable defaults. I don't want to accidentally resize my top panel, and then not be able to find the right size and get my status icon forever scaled. I don't want widgets on my desktops, I want windows (widgets, if needed, go on the overview or in the message tray). I don't want floating, isolated, bluetooth or battery indicators. I don't want to lose the clock just because I clicked with the wrong button (or the right? :D ). I don't want resolution changes to completely mess my carefully crafted widget layout. 2) Ignoring dockability and resizability, why is this necessary? Why is this better than any other solution for problem 1)? 3) How is this to be implemented? You don't describe it much, rather praise its qualities for addressing problems 1 and 3. Also, note that the same qualities are exposed by the shell activity overview (it has windows with titles, it has app icons). Also also, you describe automatic opening of some UI that is "almost full screen". Isn't that prone to accidental opening, with consequent distraction? 4) Same for solution 3, mostly (except that it addresses only problem 3). 5) Why is this better than current application view, possibly with categories? 6) How is this different from the Application view in the overview-relayout? How would you deal with the user accidentally hovering out and then having to start off again the quest for the app? 7) Same for solution 4 (except that there is no Places view in current gnome-shell, but don't worry, I am sure there will be) 8) How this relates to nautilus? Isn't that a better place for file management? Aren't individual apps expected to do archiving and tagging (like, say, Shotwell), possibly with a shared system like tracker? Are we expecting the user to handle such a difficult concept like file systems? Our minds are not trees, they're more like graphs and networks, with loose generic connections among the nodes. 9) We have a notification area. No actually we have two: a system status area and a message tray. 10) We have that, it is called "dash" 11) You're not expected to zoom in / out 12) Is there enough space for all that stuff in a single panel? I mean, the average is still 1024x768 out there. 13) Uhm... did you know that Alt+<letter> selects the menu with that letter underlined, in all Gtk+ apps, with no changes to shell or panel? 14) Yes, alt-tab can be improved. There are many bugs discussing that: gnomebug 606867, gnomebug 634173, gnomebug 621287, gnomebug 625457. Pick the one you find the most appropriate, and comment there. 15) Is the second iceweasel instance relevant to your current task? Go to gnomebug 635527 (or use tabbed browsing :) ). Else, go to activities overview. 16) Animation time is no issue here, it is less that your mental reaction time (and GNOME 2 has animations, if running with compositing). Also, if you're switching workspace, you're switching task, in which case the answer is always Activities Overview. 17) Better because...? 18) Why do you have two instances of the same application for one task? File a bug on that app, so that is implements some tabbed interface. 19) Autohiding is a problem as moving the mouse too near will show the panel instead of the underlying widget you were aiming. 20) If you are searching for the app (and you're not using the search bar), an overall view of all the applications is better, as you can quickly scan them to find the most useful. If you already know what app you want, either use the search bar (<super>firefox<enter>, for example, works if you ignore rendering problems) or make it a preferred app. Also, you can launch multiple applications by dragging all of them to a workspace. 21) No, it will be the second, the first one is Unity. And it is supposed to work with all the Intel cards from i915 (i845 would be enough, but the drivers are broken). Not at all like an nVidia GeForce, you see. Rendering bugs are rendering bugs, report them to gnome-shell, mutter, clutter, Xorg, mesa or linux. 22) Sticky (utility) windows should be handled as such (they should be hidden behind the main window). If this does not happen, file a bug against mutter. 23) 3 applications? You can actually have many more in the dash. 24) Dragging is definitely easier and more intuitive than a context menu. Beyond that, right-click on the window title, the menu is still there. 25) You want an overview, go to the "overview". You want to see if you have running downloads, look at the message tray. 26) GNOME 2 has a panel there as well... (and ctrl-w is not difficult to learn) Hope this addresses all of your concerns, I'll be happy to clarify further. > _______________________________________________ > gnome-shell-list mailing list > gnome-shell-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-shell-list Giovanni _______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
