Fwd: Re : interapplication communication

[Rovanion Luckey <rovanion luckey gmail com>]

---------- 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