GNOME.org
 

Re: interapplication communication

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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]