Re: Re : interapplication communication

[Rovanion Luckey <rovanion luckey gmail com>]

But then again. What is the function of the top bar if you move the
notification area to the bottom?

By moving the activities button to the bottom panel there is no issue
in removing the top pane since the only thing that it currently
provides is a clock and a user settings menu. Or is a Mac OS like menu
planned for the top pane?

2009/12/30 Apoorva Sharma <appi2012 gmail com>:
> 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
>



-- 
www.twitter.com/Rovanion
Steam: Rovanion
MSN: rovanion luckey gmail com