> The mockup of the message tray system here:
>
http://www.gnome.org/~mccann/shell/mockups/20090630-demo shows something
> similar to a minimized list of applications. Perhaps applications could
> create an icon there when they open, and shrink down to their icon when they
> are minimized. Furthermore, it could allow more complex interaction as shown
> in the mockup (e.g. music control) by showing a Docky like popup on
> mouseover, which each application could customize for themselves. If the
> application was not built for Gnome, the popup could simply show the
> traditional close, minimize, etc.
>
> This implementation of a taskbar/dock will allow space for the messaging
> system, but still provide easy, non-obtrusive window switching that is
> currently lacking in GNOME Shell.
>
> As far is making this area known as a application/window switcher, it could
> slide up, as it does in the mockup, whenever a new window is opened.
>
> On Wed, Dec 30, 2009 at 7:16 AM, Rovanion Luckey <
rovanion luckey gmail com>
> wrote:
>>
>> ---------- Forwarded message ----------
>> From: Rovanion Luckey <
rovanion luckey gmail com>
>> Date: 2009/12/30
>> Subject: Re: Re : interapplication communication
>> To: Nicolas de Fontenay <
n_de_fontenay yahoo com>
>>
>>
>> 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 <
n_de_fontenay yahoo com>:
>> > 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 <
femorandeira igalia com>
>> > À :
gnome-shell-list gnome org
>> > 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
>> >> <
rovanion luckey gmail com>
>> >> 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 <
mazz0 mazz0 com>:
>> >>>> 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 <
jhs jsschmid de>
>> >>>>>
>> >>>>> 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
>> >>>>>
gnome-shell-list gnome org
>> >>>>>
http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Sam Illingworth
>> >>>>
>> >>>> _______________________________________________
>> >>>> gnome-shell-list mailing list
>> >>>>
gnome-shell-list gnome org
>> >>>>
http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>>
www.twitter.com/Rovanion
>> >>> Steam: Rovanion
>> >>> MSN:
rovanion luckey gmail com
>> >>> _______________________________________________
>> >>> 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
>> >>
>> > _______________________________________________
>> > 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
>> >
>> >
>>
>>
>>
>> --
>>
www.twitter.com/Rovanion
>> Steam: Rovanion
>> MSN:
rovanion luckey gmail com
>>
>>
>>
>> --
>>
www.twitter.com/Rovanion
>> Steam: Rovanion
>> MSN:
rovanion luckey gmail com
>> _______________________________________________
>> gnome-shell-list mailing list
>>
gnome-shell-list gnome org
>>
http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>
>
>
> --
> appi
>
