Mockup for design team
Hello, to help the team design, I worked on a mock up. I hope I post in right place? The purpose of my proposal is to replace the categories on the right, with icons on top of icons of programs. Here is a link to the mockup: http://www.informalibre.fr/shell/gnome-shell-applications.png Further, I ask if it is really necessary to bring up the favorite programs from the list of applications which is filtered through the categories? Thank you in advance I wait your comments Jérôme Perret (Translated from the French translation via google) ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Please add a configuration option to make 'Power Off...' the default!
Iki Sham ikis...@gmail.com a écrit: Maybe the overview mode could have more keyboard interaction options like being able to change from 'Windows' to 'Applications' with the keyboard Try control-alt-tab in the overview. [...] I'll let others comment on your other questions. :-) Best. -- Dodji ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Please add a configuration option to make 'Power Off...' the default!
Try control-alt-tab in the overview. Thanks! Now I won't forget. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Please add a configuration option to make 'Power Off...' the default!
2011/8/4 Iki Sham ikis...@gmail.com Maybe the overview mode could have more keyboard interaction options like being able to change from 'Windows' to 'Applications' with the keyboard There's also ctrl-pgUp/pgDown, which is the GTK+ shortcut to switch between tabs. Florian ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Mockup for design team
2011/8/4 informalibre montceau informalibre.montc...@gmail.com So I explain, when I click on application, is that I want an application that is not in the dash. I am also disturbed to see this application in the list of all applications. I dislike this repetition too. There is no need for the same application icon to be presented twice in the same screen. It appears when I click on the category to which it belongs, I understand. But it should not appear when no category is selected. One problem with that idea is that the set of applications in the Dash (= Favorites + other open) is dynamic, so the position of applications in the application view would change too, breaking the spacial reference. That could be prevented if only the Favorites were left out of application picker, while any other app would always appear, but that way the repetition problem would not be completely solved. I would propose another idea: hidding the Dash itself. That is the easiest way to prevent showing the same application icon twice. Just like you said, if a user opens the application picker, that's because the application the user is looking for is not in the Dash. Sure, the presence of the Dash hints at the possibility to drag an application icon there. But it is also possible to drag an application icon to an workspace, yet the workspaces sidebar is not shown. In my opinion, hidding the Dash in the applications view wouldn't hurt, and would free some horizontal space. In my opinion, the Dash is useful in the [windows] Overview, but is distracting elsewhere. That is the reason why it is not shown in the normal view, but the same could be said about the application picker view (except for acting as a hint) and also the search results view ( where it is out of context, distrating and wasting horizontal space that could be used to present more results.) Do you understand me better ? Jerome Translated from the French translation by google 2011/8/4 Florian Müllner fmuell...@gnome.org 2011/8/4 informalibre montceau informalibre.montc...@gmail.com Further, I ask if it is really necessary to bring up the favorite programs from the list of applications which is filtered through the categories? What do you mean? Florian ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Mockup for design team
I would propose another idea: hidding the Dash itself. That is the easiest way to prevent showing the same application icon twice. Just like you said, if a user opens the application picker, that's because the application the user is looking for is not in the Dash. Sure, the presence of the Dash hints at the possibility to drag an application icon there. But it is also possible to drag an application icon to an workspace, yet the workspaces sidebar is not shown. In my opinion, hidding the Dash in the applications view wouldn't hurt, and would free some horizontal space. In my opinion, the Dash is useful in the [windows] Overview, but is distracting elsewhere. That is the reason why it is not shown in the normal view, but the same could be said about the application picker view (except for acting as a hint) and also the search results view ( where it is out of context, distrating and wasting horizontal space that could be used to present more results.) I've just submitted this as an enhancement request: https://bugzilla.gnome.org/show_bug.cgi?id=655972 Feel free to back it up with your own comments. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Mockup for design team
I really like it! I hope it gets implemented even though they're talking about getting rid of categories in 3.2 (which I hope doesn't happen). 2011/8/4 Julien Olivier jul...@gmail.com: I would propose another idea: hidding the Dash itself. That is the easiest way to prevent showing the same application icon twice. Just like you said, if a user opens the application picker, that's because the application the user is looking for is not in the Dash. Sure, the presence of the Dash hints at the possibility to drag an application icon there. But it is also possible to drag an application icon to an workspace, yet the workspaces sidebar is not shown. In my opinion, hidding the Dash in the applications view wouldn't hurt, and would free some horizontal space. In my opinion, the Dash is useful in the [windows] Overview, but is distracting elsewhere. That is the reason why it is not shown in the normal view, but the same could be said about the application picker view (except for acting as a hint) and also the search results view ( where it is out of context, distrating and wasting horizontal space that could be used to present more results.) I've just submitted this as an enhancement request: https://bugzilla.gnome.org/show_bug.cgi?id=655972 Feel free to back it up with your own comments. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list -- Diego Fernandez - 爱国 ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Please add a configuration option to make 'Power Off...' the default!
There is an extension that will put that back. It's relatively harmless. On my desktop I actually do not shut down now I just suspend. 450 watts of power saved when not in use. :-) sri On Thu, Aug 4, 2011 at 4:13 AM, iki sham ikis...@gmail.com wrote: Just to make it clear, I'm talking about something like a gsettings option that would be oficially supported and would allow us to set it up (for us or for mama) and forget about it (in principle it wouldn't break during upgrades). ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
The path of least blame
I hate that Gnome 3 gets a bad rap for little issues like starting a new terminal instance ( http://digitizor.com/2011/08/04/linus-torvalds-ditches-gnome-for-xfce/). I personally love the interface, so seeing everyone get angry over very fixable little faults makes me disappointed. Then, it got me thinking: how can one avoid Gnome 3 users from getting angry? Thought: If users can't blame Gnome 3, then they won't be frustrated by it. Case in point: assume an instance of terminal is already open and the user has forgotten about it. Also, assume that clicking the terminal icon always opens a new instance. Now when the user clicks the terminal icon and a new window pops up, she might see the old instance and go, oops! I totally forgot I had a terminal already open. silly me!. Furthermore, users that wanted to start a new instance get the expected result. This way, Gnome doesn't get the blame. In the current scenario, the set of users that forgot about the existing terminal are happy, but the rest are very unhappy. Raising the existing terminal is a completely unexpected result for those that want to start a new instance. So, they blame Gnome for that result...because they can. So, my thesis is that in a situation where the common case is not known, or the outcome is hard to predict, software should choose the outcome of least blame to avoid user frustration and eventual alienation. Just my thoughts, - Akshay http://web.cecs.pdx.edu/~akshay/ Footnote: Users might want the feature to raise existing windows, but they will be understanding of the fact that Gnome cannot possibly know if they wanted to raise the existing window or create a new one. Besides, the activities overview already shows what's open on the desktop so raising the existing window is a patronizing move on Gnome's part. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: The path of least blame
2011/8/4 Akshay Dua daks...@gmail.com I hate that Gnome 3 gets a bad rap for little issues like starting a new terminal instance ( http://digitizor.com/2011/08/04/linus-torvalds-ditches-gnome-for-xfce/). I personally love the interface, so seeing everyone get angry over very fixable little faults makes me disappointed. Then, it got me thinking: how can one avoid Gnome 3 users from getting angry? Thought: If users can't blame Gnome 3, then they won't be frustrated by it. Case in point: assume an instance of terminal is already open and the user has forgotten about it. Also, assume that clicking the terminal icon always opens a new instance. Now when the user clicks the terminal icon and a new window pops up, she might see the old instance and go, oops! I totally forgot I had a terminal already open. silly me!. Furthermore, users that wanted to start a new instance get the expected result. This way, Gnome doesn't get the blame. Is it fair to blame the user for forgetting that a given application was already open? I don't think so. We all have many things to think about in our lifes, why do we need to keep track of that kind of thing? Software is suposed to save us the trouble and just let us work. In the current scenario, the set of users that forgot about the existing terminal are happy, but the rest are very unhappy. Raising the existing terminal is a completely unexpected result for those that want to start a new instance. So, they blame Gnome for that result...because they can. So, my thesis is that in a situation where the common case is not known, or the outcome is hard to predict, software should choose the outcome of least blame to avoid user frustration and eventual alienation. Your thesis bases itself in the assumption that the expected result of clicking the terminal icon is start a new instance, but you don't provide evidence to found that assumption. Sure enough, that would be the expected result if one was clicking on a laucher on Gnome Panel. But the Dash is not Gnome Panel and doesn't even look like it, so why would one expect it to behave like it? Dash is much more similar to Docky or DockBarX than a set of launchers on Gnome Panel. Maybe it's users' expectation that is wrong, because they are used to Gnome 2. Why is Gnome 2 way treated as the expected result and Gnome 3 way a completely unexpected result? Maybe it is the other way arround. What is an expected result, by the way? If an action always gives the same result (from the user perspective), and that behaviour is reasonable, I would say it gives an expected result. In Gnome Shell, clicking on any application icon on the Dash always has the same logical result: it takes me to that application. I don't need to care if the application is already open or not - that is software business. If it was already open, it takes me to the previously used instance, letting me continue my work with that application where I left it. Otherwise, it opens a new instance for me. From the implementation detail perspective, those are 2 different behaviours. From the user perspective, it is one and the same: it takes me to the applica Just my thoughts, - Akshay http://web.cecs.pdx.edu/~akshay/ Footnote: Users might want the feature to raise existing windows, but they will be understanding of the fact that Gnome cannot possibly know if they wanted to raise the existing window or create a new one. The same can be said to users that want the proposed behaviour. Besides, the activities overview already shows what's open on the desktop so raising the existing window is a patronizing move on Gnome's part. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Suggestions
Question for the list: Is this the place to file suggestions for Gnome Shell? Also, is there a place where suggestions have been collected, so that I can read through them to see if any of my suggestions have already been suggested and approved/rejected? Would bugzilla be a better way to go? --G ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: The path of least blame
Slightly off-topic, but I consider it quite interesting that almost everyone complaining about shell's single-window approach picks the terminal as example. We would probably get rid of all complains by special-casing terminals, without the inconsistency being noticed - normal people don't use terminals, geeks apparently don't use anything else ... Florian ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: The path of least blame
On Thu, Aug 4, 2011 at 9:50 PM, Florian Müllner fmuell...@gnome.org wrote: Slightly off-topic, but I consider it quite interesting that almost everyone complaining about shell's single-window approach picks the terminal as example. We would probably get rid of all complains by special-casing terminals, without the inconsistency being noticed - normal people don't use terminals, geeks apparently don't use anything else ... Don't blame geeks. IMHO, it is simply bad design decision - are app icons in activities for app switching or app starting? How many app switching mechanisms do we need? There are 3 at least now. Best regards, w ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: The path of least blame
Le jeudi 04 août 2011 à 22:50 +0200, Florian Müllner a écrit : Slightly off-topic, but I consider it quite interesting that almost everyone complaining about shell's single-window approach picks the terminal as example. We would probably get rid of all complains by special-casing terminals, without the inconsistency being noticed - normal people don't use terminals, geeks apparently don't use anything else ... I think that terminals are only the best example of this situation. While most apps best behave as single-instance, a few of them are multiple-instance, and we still expect a click to open a new window: terminal, file manager (to open several folders separately), word processor. Maybe special-casing them wouldn't be too disturbing, indeed. Regards ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: The path of least blame
2011/8/4 Artur Wroblewski wrob...@pld-linux.org Don't blame geeks. I don't blame geeks. In fact, I spend most of the day typing in a terminal ;-) IMHO, it is simply bad design decision - are app icons in activities for app switching or app starting? Both. The basic idea is that clicking an app icon means I want to use this app now, without having to care whether the application has been started before or not. You may consider that bad design (and you are not the only one if you do - I remember similar criticism when Apple first introduced the dock), but it is pretty standard behavior nowadays - both the dock in Mac OS X and the taskbar in Windows 7 behave just like that. Florian ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: The path of least blame
On Do, 04.08.2011 23:23, Milan Bouchet-Valat wrote: I think that terminals are only the best example of this situation. While most apps best behave as single-instance, a few of them are multiple-instance, and we still expect a click to open a new window: terminal, file manager (to open several folders separately), word processor. Maybe special-casing them wouldn't be too disturbing, indeed. Instead of special-casing selected applications, it may make sense to define a .desktop-file key that specifys: I am a multi-mainwindow application. Holger ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
