---------- Forwarded message ---------- From: Rovanion Luckey <[email protected]> Date: 2009/12/30 Subject: Re: Re : interapplication communication To: Nicolas de Fontenay <[email protected]>
Switching between windows is probably the most used function of a DE. The activities pane does a fairly good job of this, tough on a small laptop or even netbook screen the interface becomes very small if the user is having more than four workspaces/activities running. I'm sure that this idea has been up previously in the mailing list but if the application switcher is to become a window switcher, why not design it as the Compiz scale plugin? http://andrewharvey4.files.wordpress.com/2009/09/compiz_scale_plugin.png 2009/12/30 Nicolas de Fontenay <[email protected]>: > Hi. > > I have to side with Felipe here. We must be able to switch one application > to another with a mouse click. > I know a lot of people reluctant to use ALT + TAB. Starting by my mother and > dad. > > But why not make it flexibe? > > Basically, anybody new to gnome shell, looking for a way to switch windows > will look for a place where they are listed to click on. > Users should be given the option of having a docking bar with currently open > apps: > a) from the active workspace only > b) from all workspace > c) No dock bar at all (use of alt + tab implied) > > I like the current dock bar at the bottom of gnome. I can hide it if I want > to. I think the auto hide option is good enough. > > As for the ALT + TAB, I think the following behavior would be better. > > 1) Alt + Tab switches between applications from a same workspace first. > 2) If Alt + Tab went through all the list of open applications in active > workspace AND open application exists in Workspace 2 Then > Go to Activity mode and display next application highlighted. > 3) When the next open window is selected: If it's the same workspace, simply > change application ELSE Make workspace owning open application the active > workspace and selected application the active window. > > If people don't like to go across workspace using alt + tab, they should be > given the option to loop through the applications on the active workspace > instead. > > I don't know how hard this would be to implement but it would be pretty > awesome to choose the behavior. > > regards, > > Nico > > > > ________________________________ > De : Felipe Erias Morandeira <[email protected]> > À : [email protected] > Envoyé le : Mer 30 Décembre 2009, 11 h 51 min 41 s > Objet : Re: interapplication communication > > You are suggesting a task bar/window list/dock, even if you don't want > to say it. The visual appearance and user experience is obviously open > to debate, but at the end of the day we want a way to have all windows > in the current activity displayed together, so switching to a certain > one is just a matter of point and click. Yeah, every other system has > something like that and we want GNOME Shell to be different... but have > we considered that maybe they all have it because it makes sense? Isn't > switching between open windows one of the major use cases of a modern > desktop system? > > There's no doubt that the message tray, the favourites well or the > recent documents list are important pieces of functionality. But again I > have to ask, are they more important than switching between open > windows? I personally use neither of the former functionalities in my > daily life, but I surely do switch a lot between windows. It could be > that I am an atypical user, but in any case I would suggest that we > study how people are using their computers right now and try to provide > a solution that at least is not more cumbersome for the most common use > cases. > > > Felipe > > Sam Illingworth wrote: >> Yeah, that's what I was thinking, but with it being automatic (maybe >> that could be an option?) I like the idea of now having a seperate state >> for minimized widows and just making the window manager arrange them so >> teyre out of the way. If there wasn't room to shrink them to a side of >> the screen it could push them off the side a bit. >> >> >> >> >> On 29 Dec 2009, at 09:22 PM, Rovanion Luckey <[email protected]> >> wrote: >> >>> Minimizing windows does not work at the moment, they simply disappear >>> and that's confusing even for me. The stereotypical mom using gnome >>> shell will think that the minimize button closed her application. >>> >>> What if pressing the minimize button made the window become small and >>> hide on free desktop space, space not obscured by any window. I am not >>> sure what would happend if all desktop space was to be obscured, a >>> pretty normal situation I suppose on a small screen. Should the >>> minimized window then take their hideout on the top shell panel? Just >>> showing the lower bottom of the window or maybe it's icon, and moused >>> over the window would become larger and come out of the shell panel. >>> >>> Tough that's a bit like a taskbar. Maybe you would have the lower >>> right corner to show windows on the current activity. Just as the top >>> left corner shows activities. >>> >>> 2009/12/29 Samuel Arthur Wright Illingworth <[email protected]>: >>>> Ooooh, I love that idea! I was just gonna suggest a hot corner that >>>> arranges all the windows on the current workspace, like they get >>>> arranged in >>>> the activities overlay, but without zooming out. >>>> One thing I will say though - Owen, you say you're dead set against >>>> having a >>>> static list of the existing windows, but I for one need a visual >>>> reminder of >>>> what windows I've got open for the current activity - it helps focus >>>> my mind >>>> on what I'm doing, what information I have available to me, what I >>>> need to >>>> do next, etc. It's also an instant and predictable way of finding the >>>> window you want - if something pops up or is arranged dynamically >>>> (like a >>>> hidden alt-tab style dock or Scale style action) you have to wait and >>>> look >>>> to find where the window you want is. >>>> OK, here's an idea (not thought about it much): how about we get rid >>>> of the >>>> minimize button, and replace it with a don't-minimize button. Any >>>> window >>>> that's not got don't-minimize ticked will minimize automatically when >>>> you >>>> select another window. But when minimized, it will actually shrink >>>> into a >>>> thumbnail on whichever edge of the screen (left, bottom or right) has >>>> the >>>> most space (so they can be as big as possible), depending where the >>>> active >>>> window is. Because it visually shrinks down you know where it is. >>>> If the >>>> active window gets too big so the thumbnails would have to shrink >>>> down tiny >>>> to be visible then they'll start to be covered by the active window >>>> and only >>>> come on top on mouse over. When maximized they won't be visible. To >>>> see >>>> two windows side by side, unminimized, you can click the don't minimize >>>> button on one of them (although having some Windows 7 style side-by-side >>>> thingy would be handy too). >>>> I'm sure that there are lots of problems with that idea, but meh. >>>> >>>> 2009/12/29 Johannes Schmid <[email protected]> >>>>> >>>>> 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 >>>> >>>> >>>> >>>> -- >>>> Sam Illingworth >>>> >>>> _______________________________________________ >>>> gnome-shell-list mailing list >>>> [email protected] >>>> http://mail.gnome.org/mailman/listinfo/gnome-shell-list >>>> >>>> >>> >>> >>> >>> -- >>> www.twitter.com/Rovanion >>> Steam: Rovanion >>> MSN: [email protected] >>> _______________________________________________ >>> gnome-shell-list mailing list >>> [email protected] >>> http://mail.gnome.org/mailman/listinfo/gnome-shell-list >> _______________________________________________ >> gnome-shell-list mailing list >> [email protected] >> http://mail.gnome.org/mailman/listinfo/gnome-shell-list >> > _______________________________________________ > gnome-shell-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-shell-list > > > _______________________________________________ > gnome-shell-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-shell-list > > -- www.twitter.com/Rovanion Steam: Rovanion MSN: [email protected] -- www.twitter.com/Rovanion Steam: Rovanion MSN: [email protected] _______________________________________________ gnome-shell-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-shell-list
