Re: Window controls for GNOME 3

[Allan E. Registos]

On Friday, 04 March, 2011 11:42 PM, Adam Williamson wrote:

I agree. As for progress: a message tray icon that subsumes longrunning
>  'progress' (file) operations (copy, move, delete, download; maybe
>  update, install, for packages/applications; ...) with ability to cancel,
>  pause, restart? Wasn't this planned anyway?

KDE 4 has something like this, I believe.
(KDE4)Yes it does... In GNOME Shell, it might defeat the purpose of 
hiding the tray by default.


___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Adam Williamson]

On Fri, 2011-03-04 at 12:57 +0100, Jürgen Mangler wrote:

> I agree. As for progress: a message tray icon that subsumes longrunning 
> 'progress' (file) operations (copy, move, delete, download; maybe 
> update, install, for packages/applications; ...) with ability to cancel, 
> pause, restart? Wasn't this planned anyway?

KDE 4 has something like this, I believe.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Johannes Schmid]

Hi!

> I agree. As for progress: a message tray icon that subsumes longrunning
> 'progress' (file) operations (copy, move, delete, download; maybe
> update, install, for packages/applications; ...) with ability to cancel,
> pause, restart? Wasn't this planned anyway?

Some work has been done but is has to be finished and picked up in the shell:
https://ssickert.wordpress.com/2010/05/09/introducing-my-gsoc%C2%A0project/

Regards,
Johannes

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Jürgen Mangler]

Hi!


* To hide a window in which a background task is ongoing. Minimizing the
window allows the user to monitor the progress in the window list button
(assuming progress is shown in the title bar, which ought to be the case),
and to be alerted when the task has either finished or encountered a
problem (when the window list button flashes), without being distracted by
the window itself.


Which is clearly what notification are for and not the window title. I
think this case is solved in a much nicer way in the shell than it was
before. Might be that some applications need updates though.


How would an application show the continuous progress of a background task 
using notifications, or the messaging tray in general? I don't see anything in 
the shell design docs that suggest that would be a good way to do it. (I guess 
you could show a progress bar or something when you roll over a notification 
icon, but that's not very helpful.)


Well, IMHO I want to be alerted mostly when it finishes or when it has a
problem and that's what notification are for. If I want to know the
exact progress, that's an active action where I can look into the window
or check the message tray.


I agree. As for progress: a message tray icon that subsumes longrunning 
'progress' (file) operations (copy, move, delete, download; maybe 
update, install, for packages/applications; ...) with ability to cancel, 
pause, restart? Wasn't this planned anyway?


___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Johannes Schmid]

Hi!

> >> * To hide a window in which a background task is ongoing. Minimizing the
> >> window allows the user to monitor the progress in the window list button
> >> (assuming progress is shown in the title bar, which ought to be the case),
> >> and to be alerted when the task has either finished or encountered a
> >> problem (when the window list button flashes), without being distracted by
> >> the window itself.
> > 
> > Which is clearly what notification are for and not the window title. I
> > think this case is solved in a much nicer way in the shell than it was
> > before. Might be that some applications need updates though.
> 
> How would an application show the continuous progress of a background task 
> using notifications, or the messaging tray in general? I don't see anything 
> in the shell design docs that suggest that would be a good way to do it. (I 
> guess you could show a progress bar or something when you roll over a 
> notification icon, but that's not very helpful.)

Well, IMHO I want to be alerted mostly when it finishes or when it has a
problem and that's what notification are for. If I want to know the
exact progress, that's an active action where I can look into the window
or check the message tray.

Regards,
Johannes


signature.asc
Description: This is a digitally signed message part
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Calum Benson]

On 3 Mar 2011, at 14:14, Johannes Schmid wrote:

> Hi!
> 
>> * To hide a window in which a background task is ongoing. Minimizing the
>> window allows the user to monitor the progress in the window list button
>> (assuming progress is shown in the title bar, which ought to be the case),
>> and to be alerted when the task has either finished or encountered a
>> problem (when the window list button flashes), without being distracted by
>> the window itself.
> 
> Which is clearly what notification are for and not the window title. I
> think this case is solved in a much nicer way in the shell than it was
> before. Might be that some applications need updates though.

How would an application show the continuous progress of a background task 
using notifications, or the messaging tray in general? I don't see anything in 
the shell design docs that suggest that would be a good way to do it. (I guess 
you could show a progress bar or something when you roll over a notification 
icon, but that's not very helpful.)

Cheeri,
Calum.

-- 
CALUM BENSON, Interaction Designer Oracle Corporation Ireland Ltd.
mailto:calum.ben...@oracle.com Solaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Oracle Corp.

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Johannes Schmid]

Hi!

> * To hide a window in which a background task is ongoing. Minimizing the
> window allows the user to monitor the progress in the window list button
> (assuming progress is shown in the title bar, which ought to be the case),
> and to be alerted when the task has either finished or encountered a
> problem (when the window list button flashes), without being distracted by
> the window itself.

Which is clearly what notification are for and not the window title. I
think this case is solved in a much nicer way in the shell than it was
before. Might be that some applications need updates though.

Regards,
Johannes

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Calum Benson]

On 2 Mar 2011, at 04:23, Robert Park wrote:

> On Tue, Mar 1, 2011 at 7:35 PM, Ryan Peters  wrote:
>> Last I checked, virtually every device with a trackpad has some sort of
>> physical mouse button for this very purpose (laptops and whatnot).
> 
> O RLY?
> 
> http://www.google.ca/images?q=buttonless%20trackpad&oe=utf-8&rls=org.mozilla:en-US:official&client=firefox-a&um=1&ie=UTF-8&source=og&sa=N&hl=en&tab=wi&biw=1671&bih=945

Can't speak for the others, but the Apple laptop trackpads shown there do have 
a physical button, they're just styled to look as though they don't. But they 
absolutely do physically 'click' when you use them, and unlike the old Macs 
that did only have one separate, physical trackpad button, you can do both left 
and right clicks with the 'buttonless' ones as well.

Cheeri,
Calum.

-- 
CALUM BENSON, Interaction Designer Oracle Corporation Ireland Ltd.
mailto:calum.ben...@oracle.com Solaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Oracle Corp.

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Calum Benson]

On 1 Mar 2011, at 21:36, William Jon McCann wrote:

> I don't have any plans to drop the symbolic close button but some
> successful designs have done this already.  WebOS uses a close gesture
> and no on screen explicit controls.  iOS on iPad mostly does away will
> all forms of window management but in some cases (secondary windows)
> uses a "Done" button instead of the symbolic version.

Most secondary windows in GNOME 2.x were never supposed to have a symbolic 
close button anyway (at least from the HIG/usability team's POV), because for 
those windows where there's a choice of dismissal options, it's not clear 
whether closing the window that way means 'OK' or 'Cancel', for example.

For many years I was told it was a metacity bug that we couldn't hide it 
altogether, but I don't know whether that was eventually fixed -- I haven't 
chased it up for a while :)

Cheeri,
Calum.

-- 
CALUM BENSON, Interaction Designer Oracle Corporation Ireland Ltd.
mailto:calum.ben...@oracle.com Solaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Oracle Corp.

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Calum Benson]

On 23 Feb 2011, at 00:21, Owen Taylor wrote:

> Why do people minimize windows?
> ===

I'd also add to your list:

* To hide a window in which a background task is ongoing. Minimizing the window 
allows the user to monitor the progress in the window list button (assuming 
progress is shown in the title bar, which ought to be the case), and to be 
alerted when the task has either finished or encountered a problem (when the 
window list button flashes), without being distracted by the window itself.

Cheeri,
Calum.

-- 
CALUM BENSON, Interaction Designer Oracle Corporation Ireland Ltd.
mailto:calum.ben...@oracle.com Solaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Oracle Corp.

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Vishnoo]

On Wed, 2011-03-02 at 11:53 -0800, Adam Williamson wrote:
> 
> I'm not hugely bothered either way about the maximize button,
> personally. You only have to learn 'double-click on the window bar' once
> and it's just as easy as clicking a maximize button. As a general
> principle, the removal of features with _no easy alternative_ bothers me
> much more than the removal of one of many different ways to do
> something, as long as one of the other ways is not inherently more
> difficult.

Right, but I'm questioning if it was really a feature or a workaround.

If the app *requires* a larger/maximum size, then why does it not open
at that size? 
For anything different, we have an option to manually resize.

Every use-case folks mentioned here, an alternate *custom* size is
required. 
This would require to either: 
1- resize a window from the normal state to custom size
or
2- restore a maximized window and - then resize to custom size.

Currently it is not possible to immediately resize maximized windows, if
someone wants a different custom size.
A maximized state actually makes it longer to do things.

-- 
Cheers,
Vish

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Allan E. Registos]

On Thursday, 03 March, 2011 02:15 AM, Adam Williamson wrote:

In an ideal world there should be no need for maximize/restore.
>  App should be able to know the size that displayed-content requires to
>  display, notifies the window manager and the window resizes accordingly.

Oh god, no.

Agree. You would be adding the auto maximizing / restoring headaches not 
only to window manager devs but to application developers and users as 
well!!!


___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Allan E. Registos]

On Wednesday, 02 March, 2011 10:54 PM, Thomas Bouffon wrote:
The close button is a different case : How will we force firefox to 
quit when it hangs ?
In that case, close button is not of any help. The "Force a misbehaving 
program to quit" applet is what you need.
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Allan E. Registos]

On Wednesday, 02 March, 2011 05:36 AM, William Jon McCann wrote:

Hey Sandy,

On Tue, Mar 1, 2011 at 10:54 AM, Sandy Armstrong
  wrote:

(What happened to your mail client line-wrapping settings?)

On Tue, Feb 22, 2011 at 4:21 PM, Owen Taylor  wrote:

The maximize button
===

The above was about minimization - but the request was also to remove the 
maximize button. This is a little different since there are more obvious ways 
to maximize a window - the drag to the top gesture or double-clicking on the 
title bar - we're not really talking about removing the feature of maximization 
but just the button.

I generally applaud the bold changes happening in the shell, but I
disagree with removing the maximize/restore button.  I'll paste here a
comment I wrote on Allan's blog:

1) Drag-and-drop is very difficult on touchpads, and most people these
days are buying laptops. Drag-and-drop is also undiscoverable.

That depends a lot on the quality of the touchpad too... With a crappy
touchpad (and there are a lot of them) it is arguably harder to aim
precisely to hit a small button than dragging a large object
(titlebar) to a Fittsian infinite edge (top of screen).  This is made
worse when the maximize button is immediately adjacent to a button
that is as opposite in effect as you can get.  Two bits of badness
converge here.

The first is that the cost of a slip in aiming and clicking is
unreasonably large.  There is no undo for window close.  It is
definitely not what you wanted to happen.  It is relatively difficult
to recover from.  And in some cases may result in data loss.  In every
case it results in intense frustration (argh-ing).  We don't want the
user to ever feel that.

The second is the stress involved in aiming at a small target which is
intensified by a known cost of a slip.  It makes you think.  The
interface ideally should not interrupt you and draw that kind of
attention to itself.

These issues were always present in classic window management but
become highly problematic with many touch interfaces and especially so
with low precision pointing devices.

There are three other things that should help in these cases:

  * using the entire titlebar as a double click target to maximize
  * using keyboard shortcuts for maximization
  * in some cases maximizing certain sovereign apps by default
(particularly on smaller screens)


2) Double-clicking the title-bar is undiscoverable.

Honestly, I think "discoverability" is one of the more misused
critiques of user interface design.  There are a lot of reasons for
this and I won't cover them.  I don't think that discoverability is a
prerequisite for a successful interface.  Surely, in many cases it
helps.  But it is just one factor.  Gestures (especially touch) aren't
discoverable and yet they are extremely useful and powerful.
Gestures, even me a power user, do not use them. I have to focus on the 
task, rather than to discover a gesture which may very difficult to do 
first time. The shortcut method and the easiest thing is to click on the 
symbolic icon.

Context
menus aren't discoverable and yet they provide a way to access lots of
functionality that couldn't otherwise be presented in the visible and
discoverable interface.
*menus are presented because they will present you _tons_ of options 
that cannot be implemented using symbols, maybe the reason is the lack 
of space, but I doubt, the MS Office folks will argue you against that.

  Keyboard shortcuts obviously aren't
discoverable most of the time.  As you mention above, drag and drop of
any kind is not discoverable and yet it has formed the basis of many
very successful designs.
Drag and drop is a special kind of event, that may or can never be 
presented using symbols. Like drag an object to X, Y coordinates, how 
can you do that using symbols?

  Discoverability almost always involves
learning.  You are not born knowing what the "_" icon in every window
means.  Nor do you intrinsically know what "maximize" means.  You
learned it at some point.
And we are born that way, generally presented by _ [] X buttons. Other 
operating systems presented these symbols where the current design in GS 
is with only a close symbol.

Another trend you are seeing is a bit of a drift away from symbolic
representation and indirect action to more tactile direct
manipulation.  I think this is natural.  It feels better somehow.

Care to have examples?

And
if it just does that thing I don't need to know the name for that
thing.  When I throw a window at the top of the screen it gets bigger.
  I wanted it to get bigger.  Cool.
Yes, the current GS of maximizing/restoring a window is exactly the same 
in Windows 7 yet they still present those traditional buttons. You know 
the reason _why_.

  I don't have to even know the word
for it in tech speak is maximize or know that it is symbolically
represented by a square.

I don't have any plans to drop the symbolic close button but some
successful designs have d

Re: Window controls for GNOME 3

[Akshay Dua]

I am OK with or without buttons, but surely, you don't mean that
stable desktop interfaces released to production environments should
be a test bed, do you? I would assume that a test bed consists of a
volunteer group of beta testers that fill out usability surveys (which
I will be more than happy to do for the shell), but I am not sure that
a stable release should work as a test bed. It should probably try to
maximize popularity and keep focus on new and important features.

-- Akshay
http://web.cecs.pdx.edu/~akshay/



On Wed, Mar 2, 2011 at 3:22 PM, Robert Park  wrote:
> On Wed, Mar 2, 2011 at 4:01 PM, Akshay Dua  wrote:
>> I don't know what started the rash that caused the itch to remove
>> those buttons, but its causing everyone to talk negatively about the
>> shell, while otherwise no one would have even cared if they remained
>> there. Am I wrong? Are there people truly bothered by seeing the
>> minimize button in the title bar?
>
> The goal of Gnome Shell is not to uphold the status quo. Gnome Shell
> is a test bed to experiment with a new paradigm in UI design. It is
> going to be different than what you are used to.
>
> --
> http://exolucere.ca
>
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Robert Park]

On Wed, Mar 2, 2011 at 4:01 PM, Akshay Dua  wrote:
> I don't know what started the rash that caused the itch to remove
> those buttons, but its causing everyone to talk negatively about the
> shell, while otherwise no one would have even cared if they remained
> there. Am I wrong? Are there people truly bothered by seeing the
> minimize button in the title bar?

The goal of Gnome Shell is not to uphold the status quo. Gnome Shell
is a test bed to experiment with a new paradigm in UI design. It is
going to be different than what you are used to.

-- 
http://exolucere.ca
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Akshay Dua]

I am going to go off on a tangent here and say that decisions like
removing the maximize/minimize buttons take little time to execute,
but go a long way in tarring the image of the product (Gnome shell).

I think the real question is not if removing those buttons is a good
or bad decision, but what would have happened if Gnome devs had let it
be? Users would simply have one less thing to talk/complain about, and
this would be a great thing because it would move focus towards all
the awesome features of the shell. I don't remember seeing heated
discussions about the minimize button before.

I don't know what started the rash that caused the itch to remove
those buttons, but its causing everyone to talk negatively about the
shell, while otherwise no one would have even cared if they remained
there. Am I wrong? Are there people truly bothered by seeing the
minimize button in the title bar?

Maybe a gentler approach to removing tremendously familiar features is better...

-- Akshay
http://web.cecs.pdx.edu/~akshay/



On Wed, Mar 2, 2011 at 12:17 PM, Robert Park  wrote:
> On Wed, Mar 2, 2011 at 11:15 AM, Adam Williamson  wrote:
>> flow. I like a full-screen browser window, lots of people think this
>> makes lines of text way too wide. Neither of us is correct or incorrect.
>
> What websites do you visit that actually use the full width of a
> maximized window? It seems like every site on the internet is using
> fixed-width columns these days.
>
> Not that I'm disagreeing with you -- I also maximize firefox on an HD
> widescreen (1920x1080), and I love it.
>
> --
> http://exolucere.ca
> ___
> 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

Re: Window controls for GNOME 3

[Robert Park]

On Wed, Mar 2, 2011 at 11:15 AM, Adam Williamson  wrote:
> flow. I like a full-screen browser window, lots of people think this
> makes lines of text way too wide. Neither of us is correct or incorrect.

What websites do you visit that actually use the full width of a
maximized window? It seems like every site on the internet is using
fixed-width columns these days.

Not that I'm disagreeing with you -- I also maximize firefox on an HD
widescreen (1920x1080), and I love it.

-- 
http://exolucere.ca
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Adam Williamson]

On Thu, 2011-03-03 at 00:55 +0530, Vishnoo wrote:

> You are reading/understanding things too literally. 

> Let me rephrase that more clearly, When I said "In an ideal world there
> should be no need for maximize/restore" , it just meant we should not
> _have_ to do window resize often. 
> I'm *not* suggesting the removal of the ability to resize and that
> everything be done only automatically.

Well, you didn't say I was supposed to understand them metaphorically.
=) But if all you're saying is that GNOME should try to be smarter about
initial sizes (and, possibly, dynamic resizing/tiling) so that manual
resizing becomes less necessary, sure, I can get all the way behind
that. I was just worried about the idea of taking it to its 'logical
extension' - your 'ideal world' scenario where manual maximizing /
resizing become unnecessary. If we're not going there, then no problem,
go ahead.

> But, IMO, this outcry for removal of the maximize button seems a very
> disproportionate to the actual need and does not focus on the cause of
> the problem which requires user to resize often.
> If we were to restore the maximize button, it would not be the right
> solution, it would only be a workaround.

I'm not hugely bothered either way about the maximize button,
personally. You only have to learn 'double-click on the window bar' once
and it's just as easy as clicking a maximize button. As a general
principle, the removal of features with _no easy alternative_ bothers me
much more than the removal of one of many different ways to do
something, as long as one of the other ways is not inherently more
difficult.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Vishnoo]

On Wed, 2011-03-02 at 10:15 -0800, Adam Williamson wrote:
> On Wed, 2011-03-02 at 16:44 +0530, Vishnoo wrote:
> 
> > IMO, the maximize/resize 'feature' is a workaround for a window
> > management that never got fully implemented.
> > 
> > It would be very interesting to know why user is forced to resize the
> > windows manually and try to fix those problems.
> > 
> > In an ideal world there should be no need for maximize/restore.
> > App should be able to know the size that displayed-content requires to
> > display, notifies the window manager and the window resizes accordingly.
> 
> Oh god, no.
> 
> How does a text editor 'know' how big a window 'needs' to be to display
> a 500 page document (or a 10,000 line source code file)? It can't fit on
> one screen.

You are reading/understanding things too literally. 
If there are 500/5000 lines of code it obviously necessitates to display
the lines as several pages. It can not be *legibly* displayed in a
single page view.

Let me rephrase that more clearly, When I said "In an ideal world there
should be no need for maximize/restore" , it just meant we should not
_have_ to do window resize often. 
I'm *not* suggesting the removal of the ability to resize and that
everything be done only automatically.

There are always special cases, on desktop/laptops, where we would like
to resize manually. 
Some of the cases mentioned earlier could be dealt with better
tiling/grid views, but some wont work with improving grid view alone.

But, IMO, this outcry for removal of the maximize button seems a very
disproportionate to the actual need and does not focus on the cause of
the problem which requires user to resize often.
If we were to restore the maximize button, it would not be the right
solution, it would only be a workaround.

-- 
Cheers,
Vish

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Adam Williamson]

On Wed, 2011-03-02 at 19:49 +0100, Gendre Sebastien wrote:
> Le mercredi 02 mars 2011 à 10:15 -0800, Adam Williamson a écrit :
> > Oh god, no.
> > 
> > How does a text editor 'know' how big a window 'needs' to be to
> > display
> > a 500 page document (or a 10,000 line source code file)? It can't fit
> > on
> > one screen. I like to have it in a full-screen window at 1680x1050. I
> > know people who think I'm insane and think you should never display
> > text
> > more than 80 characters wide as it's 'unreadable'. Am I right? Are
> > they
> > right? Which of us would you like this new intelligent window manager
> > to
> > piss off?
> > 
> > That's just the first case that springs to mind. Terminals, as Thomas
> > points out, are another good one. Browsers; again, it comes down to
> > text
> > flow. I like a full-screen browser window, lots of people think this
> > makes lines of text way too wide. Neither of us is correct or
> > incorrect. 
> 
> (sorry if I feed the troll...)
> 
> If the window size can be adapted to its content, it should be smart. If
> the window adapted is > than the available size on the display, it will
> adapt itself to the available size. 

But that only makes me happy. It doesn't make the people who think a
full-screen window is too big to read text on happy.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Gendre Sebastien]

Le mercredi 02 mars 2011 à 10:15 -0800, Adam Williamson a écrit :
> Oh god, no.
> 
> How does a text editor 'know' how big a window 'needs' to be to
> display
> a 500 page document (or a 10,000 line source code file)? It can't fit
> on
> one screen. I like to have it in a full-screen window at 1680x1050. I
> know people who think I'm insane and think you should never display
> text
> more than 80 characters wide as it's 'unreadable'. Am I right? Are
> they
> right? Which of us would you like this new intelligent window manager
> to
> piss off?
> 
> That's just the first case that springs to mind. Terminals, as Thomas
> points out, are another good one. Browsers; again, it comes down to
> text
> flow. I like a full-screen browser window, lots of people think this
> makes lines of text way too wide. Neither of us is correct or
> incorrect. 

(sorry if I feed the troll...)

If the window size can be adapted to its content, it should be smart. If
the window adapted is > than the available size on the display, it will
adapt itself to the available size. 


signature.asc
Description: This is a digitally signed message part
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Adam Williamson]

On Wed, 2011-03-02 at 16:44 +0530, Vishnoo wrote:

> IMO, the maximize/resize 'feature' is a workaround for a window
> management that never got fully implemented.
> 
> It would be very interesting to know why user is forced to resize the
> windows manually and try to fix those problems.
> 
> In an ideal world there should be no need for maximize/restore.
> App should be able to know the size that displayed-content requires to
> display, notifies the window manager and the window resizes accordingly.

Oh god, no.

How does a text editor 'know' how big a window 'needs' to be to display
a 500 page document (or a 10,000 line source code file)? It can't fit on
one screen. I like to have it in a full-screen window at 1680x1050. I
know people who think I'm insane and think you should never display text
more than 80 characters wide as it's 'unreadable'. Am I right? Are they
right? Which of us would you like this new intelligent window manager to
piss off?

That's just the first case that springs to mind. Terminals, as Thomas
points out, are another good one. Browsers; again, it comes down to text
flow. I like a full-screen browser window, lots of people think this
makes lines of text way too wide. Neither of us is correct or incorrect.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Thomas Bouffon]

>
> For example while trying to store knowledge in my brain, I often have pdfs
> with exercise opened and maximize the window to have it easily readable
> while working on plain ol' paper.
> When I do actual coding (and dont have the 2nd monitor available), I often
> have the exercise next to the IDE which requires the windows to be resized
> properly. 50/50 splitting wouldn't help since I'd want to set the
> distribution of screen real estate dynamically. Regardless of the fact that
> evince comes up with a completely unusable window dimension here, I often
> need to adjust the size of the content displayed.
>
>
I completely agree with Marcus.
For example, when you have some information in your email client that you
have to report somewhere else, cycling through windows can be a pain. In
that case, I prefer resizing windows, having Tbird in the background with
the relevant information in sight, while having the other app in the
foreground with focus.
Other case : terminals. The size of the terminal really depends on what you
are doing. Plus, when working on distant machines, window resizing can be
really bad interpreted.

I personally don't care much of having the resizing buttons or not, but
still I want to be able to set the size. Maybe at open time, a window with a
surface above a certain threshold can be maximized at startup ?
The close button is a different case : How will we force firefox to quit
when it hangs ?

Cheers,
Thomas
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Andreas Wallberg]

Hi Marcel & Co!

Is this discussion moving into tiling? I suggested a while back to
have a simple user-configurable per-workspace grid for windows tiling,
something along the guide lines (no pun intended) in programs like
Gimp and Inkscape. For this idea, the max button would indeed be very
important. This is a very basic mockup:

http://dl.dropbox.com/u/1879450/Idea_For_Tiling_In_Gnome_Shell.png

In this scenario, the grid would be controlled from the activities
overview. If the crosshair was put in a corner, pressing the maximize
button would indeed maximize the window over the whole workspace,
otherwise it would maximize the window to fill the space in which the
max button (or corner) of the window was located when pressed. The
idea is to make it easier to manage multi-window workspaces where, as
often is the case, one main window needs the most size but the others
still needs to be visible and we would like to resize all of them
together.

That idea originated back when the workspaces had a very different
layout compared with what it looks like today and I am not so sure it
would fit well with the current vision of the Gnome Shell. I still
think that the idea is neat though and would propose that instead of
controlling the grid from the overview, one would do this directly on
the workspace using a different workflow:

* When a window is maximized, it should still be possible to resize it
in any direction.
* When resized, the vacant space between the edge of the workspace and
the window should use a similar hint as when a window is dragged to
either edge, but this time indicating that there is a new area into
which windows can be maximized.
* Alternatively, snapping one window to another window would also
create a division among areas, or change the current division.
* If a window has been maximized in an area, it would be resized when
the size of the area changes.
* Resizing one of two maximized and snapped windows would also move
the guide line, resize the areas and any other maximized windows at
the same time.
* When a grid has been created, its guide lines should fade in/out
when a window is moved.
* Resetting the grid should be possible by right clicking a window
title bar and selecting the reset option or using some shortkey combo.

I realize that this idea is crude and would need a lot of refinement
to work. Among other things there needs to be a very visible
difference between an area-maximized window and floating windows. In
either case, the max button itself would be important and I strongly
suggest it is kept for future tweaks like this one.

Best regards,
Andreas

On Wed, Mar 2, 2011 at 2:45 PM, Marcel  wrote:
> Am 02.03.2011 12:14, schrieb Vishnoo:
>>
>> Why does one actually want to maximize and restore windows or resize
>> them? (nautilus windows dont count, lets think about apps/task instead
>> of file-management ;p )
>>
>> IMO, the maximize/resize 'feature' is a workaround for a window
>> management that never got fully implemented.
>>
>> It would be very interesting to know why user is forced to resize the
>> windows manually and try to fix those problems.
>
> For example while trying to store knowledge in my brain, I often have pdfs
> with exercise opened and maximize the window to have it easily readable
> while working on plain ol' paper.
> When I do actual coding (and dont have the 2nd monitor available), I often
> have the exercise next to the IDE which requires the windows to be resized
> properly. 50/50 splitting wouldn't help since I'd want to set the
> distribution of screen real estate dynamically. Regardless of the fact that
> evince comes up with a completely unusable window dimension here, I often
> need to adjust the size of the content displayed.
>
> Marcel
> ___
> 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

Re: Window controls for GNOME 3

[Marcel]

Am 02.03.2011 12:14, schrieb Vishnoo:

Why does one actually want to maximize and restore windows or resize
them? (nautilus windows dont count, lets think about apps/task instead
of file-management ;p )

IMO, the maximize/resize 'feature' is a workaround for a window
management that never got fully implemented.

It would be very interesting to know why user is forced to resize the
windows manually and try to fix those problems.


For example while trying to store knowledge in my brain, I often have 
pdfs with exercise opened and maximize the window to have it easily 
readable while working on plain ol' paper.
When I do actual coding (and dont have the 2nd monitor available), I 
often have the exercise next to the IDE which requires the windows to be 
resized properly. 50/50 splitting wouldn't help since I'd want to set 
the distribution of screen real estate dynamically. Regardless of the 
fact that evince comes up with a completely unusable window dimension 
here, I often need to adjust the size of the content displayed.


Marcel
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Vishnoo]

On Tue, 2011-03-01 at 16:36 -0500, William Jon McCann wrote:
> Hey Sandy,
> 
> On Tue, Mar 1, 2011 at 10:54 AM, Sandy Armstrong
>  wrote:
> > (What happened to your mail client line-wrapping settings?)
> >
> > On Tue, Feb 22, 2011 at 4:21 PM, Owen Taylor  wrote:
> >> The maximize button
> >> ===
> >>
> >> The above was about minimization - but the request was also to remove the 
> >> maximize button. This is a little different since there are more obvious 
> >> ways to maximize a window - the drag to the top gesture or double-clicking 
> >> on the title bar - we're not really talking about removing the feature of 
> >> maximization but just the button.
> >
> > I generally applaud the bold changes happening in the shell, but I
> > disagree with removing the maximize/restore button.  I'll paste here a
> > comment I wrote on Allan's blog:
> >
> > 1) Drag-and-drop is very difficult on touchpads, and most people these
> > days are buying laptops. Drag-and-drop is also undiscoverable.


> 
> There are three other things that should help in these cases:
> 
>  * using the entire titlebar as a double click target to maximize
>  * using keyboard shortcuts for maximization
>  * in some cases maximizing certain sovereign apps by default
> (particularly on smaller screens)


(Apart from multiple window management, where we have the snap to grids)

Why does one actually want to maximize and restore windows or resize
them? (nautilus windows dont count, lets think about apps/task instead
of file-management ;p )

IMO, the maximize/resize 'feature' is a workaround for a window
management that never got fully implemented.

It would be very interesting to know why user is forced to resize the
windows manually and try to fix those problems.

In an ideal world there should be no need for maximize/restore.
App should be able to know the size that displayed-content requires to
display, notifies the window manager and the window resizes accordingly.

Some apps try to do this, some just save the window state, but the
current situation is not perfect since we seem to require
window-resizing.

IMO, we should look into fixing this broken maximize/resize "feature".
And removing this button or making it less discoverable might force us
into thinking of an ideal situation.. 

just my non-coder 2c ;-)

-- 
Cheers,
Vish

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Robert Park]

On Tue, Mar 1, 2011 at 7:35 PM, Ryan Peters  wrote:
> Last I checked, virtually every device with a trackpad has some sort of
> physical mouse button for this very purpose (laptops and whatnot).

O RLY?

http://www.google.ca/images?q=buttonless%20trackpad&oe=utf-8&rls=org.mozilla:en-US:official&client=firefox-a&um=1&ie=UTF-8&source=og&sa=N&hl=en&tab=wi&biw=1671&bih=945


-- 
http://exolucere.ca
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Ryan Peters]

On 03/01/2011 03:52 PM, Alberto Ruiz wrote:

2011/3/1 John Stowers:

Admittedly it is usually windows users who I observe doing this, but I
think it is wrong to assume that users;

a) know that double click exists
b) can actually distinguish that it is different from single click

Not to mention, trackpads are double click unfriendly.

Last I checked, virtually every device with a trackpad has some sort of 
physical mouse button for this very purpose (laptops and whatnot).

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Alberto Ruiz]

2011/3/1 John Stowers :
> Admittedly it is usually windows users who I observe doing this, but I
> think it is wrong to assume that users;
>
> a) know that double click exists
> b) can actually distinguish that it is different from single click

Not to mention, trackpads are double click unfriendly.

-- 
Un saludo,
Alberto Ruiz
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[William Jon McCann]

Hey Sandy,

On Tue, Mar 1, 2011 at 10:54 AM, Sandy Armstrong
 wrote:
> (What happened to your mail client line-wrapping settings?)
>
> On Tue, Feb 22, 2011 at 4:21 PM, Owen Taylor  wrote:
>> The maximize button
>> ===
>>
>> The above was about minimization - but the request was also to remove the 
>> maximize button. This is a little different since there are more obvious 
>> ways to maximize a window - the drag to the top gesture or double-clicking 
>> on the title bar - we're not really talking about removing the feature of 
>> maximization but just the button.
>
> I generally applaud the bold changes happening in the shell, but I
> disagree with removing the maximize/restore button.  I'll paste here a
> comment I wrote on Allan's blog:
>
> 1) Drag-and-drop is very difficult on touchpads, and most people these
> days are buying laptops. Drag-and-drop is also undiscoverable.

That depends a lot on the quality of the touchpad too... With a crappy
touchpad (and there are a lot of them) it is arguably harder to aim
precisely to hit a small button than dragging a large object
(titlebar) to a Fittsian infinite edge (top of screen).  This is made
worse when the maximize button is immediately adjacent to a button
that is as opposite in effect as you can get.  Two bits of badness
converge here.

The first is that the cost of a slip in aiming and clicking is
unreasonably large.  There is no undo for window close.  It is
definitely not what you wanted to happen.  It is relatively difficult
to recover from.  And in some cases may result in data loss.  In every
case it results in intense frustration (argh-ing).  We don't want the
user to ever feel that.

The second is the stress involved in aiming at a small target which is
intensified by a known cost of a slip.  It makes you think.  The
interface ideally should not interrupt you and draw that kind of
attention to itself.

These issues were always present in classic window management but
become highly problematic with many touch interfaces and especially so
with low precision pointing devices.

There are three other things that should help in these cases:

 * using the entire titlebar as a double click target to maximize
 * using keyboard shortcuts for maximization
 * in some cases maximizing certain sovereign apps by default
(particularly on smaller screens)

> 2) Double-clicking the title-bar is undiscoverable.

Honestly, I think "discoverability" is one of the more misused
critiques of user interface design.  There are a lot of reasons for
this and I won't cover them.  I don't think that discoverability is a
prerequisite for a successful interface.  Surely, in many cases it
helps.  But it is just one factor.  Gestures (especially touch) aren't
discoverable and yet they are extremely useful and powerful.  Context
menus aren't discoverable and yet they provide a way to access lots of
functionality that couldn't otherwise be presented in the visible and
discoverable interface.  Keyboard shortcuts obviously aren't
discoverable most of the time.  As you mention above, drag and drop of
any kind is not discoverable and yet it has formed the basis of many
very successful designs.  Discoverability almost always involves
learning.  You are not born knowing what the "_" icon in every window
means.  Nor do you intrinsically know what "maximize" means.  You
learned it at some point.

Another trend you are seeing is a bit of a drift away from symbolic
representation and indirect action to more tactile direct
manipulation.  I think this is natural.  It feels better somehow.  And
if it just does that thing I don't need to know the name for that
thing.  When I throw a window at the top of the screen it gets bigger.
 I wanted it to get bigger.  Cool.  I don't have to even know the word
for it in tech speak is maximize or know that it is symbolically
represented by a square.

I don't have any plans to drop the symbolic close button but some
successful designs have done this already.  WebOS uses a close gesture
and no on screen explicit controls.  iOS on iPad mostly does away will
all forms of window management but in some cases (secondary windows)
uses a "Done" button instead of the symbolic version.

To summarize, discoverability is only one of the considerations in
designing a successful interface.  In this case, it wasn't the most
important factor.  But if you simply cannot get used to life without
the maximize button, despite the benefits, or using one of the other
approaches mentioned above, feel free to add the button back using the
settings.

Hope that helps a bit.

Jon
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[John Stowers]

On Tue, 2011-03-01 at 07:54 -0800, Sandy Armstrong wrote:
> (What happened to your mail client line-wrapping settings?)
> 
> On Tue, Feb 22, 2011 at 4:21 PM, Owen Taylor  wrote:
> > The maximize button
> > ===
> >
> > The above was about minimization - but the request was also to remove the 
> > maximize button. This is a little different since there are more obvious 
> > ways to maximize a window - the drag to the top gesture or double-clicking 
> > on the title bar - we're not really talking about removing the feature of 
> > maximization but just the button.
> 
> I generally applaud the bold changes happening in the shell, but I
> disagree with removing the maximize/restore button.  I'll paste here a
> comment I wrote on Allan's blog:
> 
> 1) Drag-and-drop is very difficult on touchpads, and most people these
> days are buying laptops. Drag-and-drop is also undiscoverable.
> 2) Double-clicking the title-bar is undiscoverable.

I agree with these reasons.

May I also add one more - double clicking is terrible. Firstly, I always
opt for single click (recovering RSI/OOS). Secondly, how many computer
users *still* have no idea what double clicking does; the kind of people
who double click on *everything*, links in websites, menus, buttons, or
keep double clicking on applications while waiting for them to start.
Admittedly it is usually windows users who I observe doing this, but I
think it is wrong to assume that users;

a) know that double click exists
b) can actually distinguish that it is different from single click

I would prefer the approach of 'one foot in the old and one in the new'.
maximize for the old, dragging for the new. I still know windows 7 users
who don't use aero snap, so keeping maximize not only retains
familiarity for them, but current gnome2 users too. 

John


___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Sandy Armstrong]

(What happened to your mail client line-wrapping settings?)

On Tue, Feb 22, 2011 at 4:21 PM, Owen Taylor  wrote:
> The maximize button
> ===
>
> The above was about minimization - but the request was also to remove the 
> maximize button. This is a little different since there are more obvious ways 
> to maximize a window - the drag to the top gesture or double-clicking on the 
> title bar - we're not really talking about removing the feature of 
> maximization but just the button.

I generally applaud the bold changes happening in the shell, but I
disagree with removing the maximize/restore button.  I'll paste here a
comment I wrote on Allan's blog:

1) Drag-and-drop is very difficult on touchpads, and most people these
days are buying laptops. Drag-and-drop is also undiscoverable.
2) Double-clicking the title-bar is undiscoverable.

Conclusion: maximize/restore button should remain.

Too me, it's a simple as that.  I don't think the "cleanliness" of
removing the button is worth the UX trade-off.  Getting rid of the
minimize button is great, though!

Thanks,
Sandy
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Robert Park]

On Fri, Feb 25, 2011 at 3:05 PM, Pat Suwalski  wrote:
> Funny how we both use workspaces the same way, and both do essentially the 
> same task, but have exactly different uses of the minimize button.

That is odd, isn't it! Whenever I want to hide something I always
think in terms of putting something in front of it, either the big
gedit window or a new tab.

> I think my values simply come from always having enjoyed and liked the 
> spatially-oriented desktop. I was very sad when two events happened in GNOME:
>
> 1) Nautilus switched away from spatial-by-default
> 2) Nautilus stopped supporting "homedir as desktop"
>
> I thought those were both fantastic ways to go, but it explains why I like to 
> be able to manipulate the clutter on my desktop rather than simplify it into 
> more group/task-oriented windows.

Ah yeah, I remember being excited about the idea of the spatial
nautilus before it came out, but not actually liking it in practise,
but I can't remember why.

> PS: Love the photography.

Thanks! It's something I'm passionate about.

-- 
http://exolucere.ca
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Sriram Ramkrishna]

On Fri, Feb 25, 2011 at 11:45 AM, Pat Suwalski  wrote:

> On 25/02/11 02:20 PM, Sriram Ramkrishna wrote:
>
>> So out of curiosity, what sort of  tasks do both you and Robert do if
>> you don't mind me being nosy?
>>
>
> Normal day-to-day work and development. I have tonnes of windows opened,
> because I have to.
>

Right, I figured that you were of the developer type.  Lots of windows,
compiling and what not.  I'm in a similar boat when I'm working on an IT
issue.


>
> I alt-tab between windows (Process/Window Grouping makes this a real pain),
> minimize them when I need to focus (mentally). When I don't need one
> (usually a browser), I use Ctrl-W or Ctrl-Q to close it. I only use the
> close button when my left hand isn't free, in fact (coffee?). Occasionally
> alt-F4 is appropriate if the others aren't implemented and my hands are
> already on the keyboard.
>
>
OK.


> I depend on the panel list of icons, because they show me a one-to-one
> mapping of my windows, minimized or not, *in the order I opened them*. This
> is where the Win7 strip definitely doesn't cut it for me, gnome-shell makes
> it much more difficult, and MacOSX makes me somewhat unproductive.
>

You probably can write an extension..  Probably as we expose different parts
of GNOME through the shell.


>
> Lastly, I absolutely hate virtual desktops. That might be an overstatement,
> but I avoid using them. Things get lost very easily, and it's a pain to set
> them up on every boot. I find a single desktop over two monitors the right
> balance. I'll keep a blank extra virtual desktop for when I need to quickly
> do something in programs that open way too many windows, like Gimp. That
> last example is the only thing I like about the concept of workspaces in
> Mutter.
>
>
I use virtual spaces a lot.  I cannot have more than 4-5 windows open at at
time.


> I think a better example, though, might be my brother. He's a
> uni-student/gamer, and he doesn't like to reboot, ever. He has at any given
> time, at least 25 Firefox or Chrome tabs open. He has at least 20 windows in
> his panel as well, right where he likes them. I predict that he would be
> very uncomfortable without that window-to-panel relation as well.
>
>
As an exercise, given an env like GNOME 3 and you had to come up with a new
methodology what would you do?  I found that changing to GNOME 3, no
minimize wasn't as bad as I thought it would be provided I keep the number
of windows open to a minimal of 4.  There are a couple of reasons where I
wanted to use the minimize:

1) privacy, someone is coming into my cube, and I wanted to minimize for
instance my GNOME irc channel window.  Or I'm about to make a screenshot and
I don't want to show certain windows

2) I have a jhbuild or some other thing sprouting debug messages and it's
distracting me.  this is where the shelf or whatever seems like a good
idea..  Moving to another workspace is also just as good in this case, if it
is a jhbuild, but not if it is part of a task of a cycle of
compiling/debugging.

3) An application is opening sub windows that I don't currently want to see
right now

other than that it has been smooth.

sri
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Pat Suwalski]

On Feb 25, 2011, at 16:33, Robert Park wrote:
> Oh, ok. Well, I'm an app developer and I have two physical displays.
> Before I got the second display (nearly 10 years ago now) I was a
> heavy user of workspaces, but since getting the second screen, I have
> literally never once used more than one virtual workspace.
> 
> My typical workflow is like this: left screen contains a maximized
> gedit window, right screen contains maximized firefox window. Both
> will be open with many tabs at any given time (firefox displaying API
> reference docs, and gedit editing various files for my current
> project). Any non-maximized window, such as empathy chat window or a
> terminal or whatever, goes onto the left screen. I never, ever need to
> minimize anything because if there's ever anything that I don't want
> to look at, I just bring gedit to the front and everything else
> disappears.

Funny how we both use workspaces the same way, and both do essentially the same 
task, but have exactly different uses of the minimize button.

I think my values simply come from always having enjoyed and liked the 
spatially-oriented desktop. I was very sad when two events happened in GNOME:

1) Nautilus switched away from spatial-by-default
2) Nautilus stopped supporting "homedir as desktop"

I thought those were both fantastic ways to go, but it explains why I like to 
be able to manipulate the clutter on my desktop rather than simplify it into 
more group/task-oriented windows.

--Pat

PS: Love the photography.
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Robert Park]

On Fri, Feb 25, 2011 at 12:20 PM, Sriram Ramkrishna  wrote:
> So out of curiosity, what sort of  tasks do both you and Robert do if you
> don't mind me being nosy?

Oh, ok. Well, I'm an app developer and I have two physical displays.
Before I got the second display (nearly 10 years ago now) I was a
heavy user of workspaces, but since getting the second screen, I have
literally never once used more than one virtual workspace.

My typical workflow is like this: left screen contains a maximized
gedit window, right screen contains maximized firefox window. Both
will be open with many tabs at any given time (firefox displaying API
reference docs, and gedit editing various files for my current
project). Any non-maximized window, such as empathy chat window or a
terminal or whatever, goes onto the left screen. I never, ever need to
minimize anything because if there's ever anything that I don't want
to look at, I just bring gedit to the front and everything else
disappears.

Also, I should mention that the bottom 20% of my gedit window is a
terminal (thanks to gedit-plugins), but I also frequently have a
couple other terminals open as well. The terminal inside gedit is used
almost exclusively for launching my app (and running it's test suite),
while the other terminal windows are for compiling (so they can be
easily hidden behind gedit). Typically also my terminal windows will
be tabbed, because I'll start a long compile going in one, then open a
new tab to do something else, and then whenever I do something that
takes more than 30 seconds to complete I start a new tab in order to
continue working.

Hope that makes sense. ;-)

In terms of the overall vision of the new Gnome Shell, I'm really
enamored with it. I've *always* thought of the taskbar as something
clunky and I'm glad to see it go. Way way back before I could afford a
computer capable of running GNOME, I used to really like the Blackbox
WM (I'm talking GNOME 1.x days here). I'm a minimalist and I like
things to be as simple as possible. Blackbox has no taskbar and no
minimize button! Funny how we've come full circle with that ;-)

-- 
http://exolucere.ca
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Gendre Sebastien]

Under my previous analysis, I propose this:

Maximize Button
===

To summarize my previous analysis, users need to maximize a window for:
- Concentrate on his work.
- See the maximum of content in the window.

For concentrate on the work, user can also use the fullscreen mode.

If the other use case of the "Maximize window size to the most of the
remaining space" button is to see the maximum of content in the window,
I propose to replace it by a "Adjust the window size to its contents"
button and keep "Maximize window size to the most of the remaining
space" when you paste the window on the top panel of Gnome-Shell (like
now). This last use is mostly do on small screen, so it's not a
constrained action.

Idea for the icon icon:

+---+
| --  █ |
| - |
| ---   |
| - |
+---+

Note: It represents a window with its content.


Minimize Button
===
To summarize my previous analysis, users need to minimize a window for:
- Hide the window without close it.

Its use really depends on the use of "maximization" of window. But in
middle and big screen, where we not much maximize windows, this feature
is really needed.

So, I propose to keep this button for "hide the window in the Dash" with
an animation. When you click on this button the Dash appears (without
the rest of Activities overview) and the window narrows and move to its
application icon in the Dash. After that, the Dash disappears. The
appearance/disappearance animation of the dash is a slide. (I know, it's
not original)

Idea for the icon:

██
██
██
█+--+
█|  |
█+--+
██

Note: The dark column represents the dash and the white square the
window minimized. I can remake it quickly in Inskape if you want.



So, what do you think?

My previous analysis, at 23 feb 2011 à 13:54 +0100:
> Le mardi 22 février 2011 à 19:21 -0500, Owen Taylor a écrit :
> > 
> > Feedback?
> > =
> > 
> > If people want to give their thoughts here, that's fine, but I don't think 
> > a mailing list debate is the best way to come to a decision, so the 
> > decision above should be considered basically final for the 3.0 release.
> > 
> > The real form of feedback that we need going from GNOME 3.0 to 3.2 is 
> > careful observation of how users are using GNOME 3 - are they figuring out 
> > how to use the overview and workspaces and message tray as we expect them 
> > to use them, or are they doing cumbersome workarounds because we took away 
> > essential features.
> > 
> > - Owen
> 
> This is just a personal analisys based what I have based on what I have
> seen since 5 years.
> 
> Maximize
> 
> 
> 
> The usage of maximize depends to the display size and resolution. If you
> have a screen < 14",  you maximize the majority of windows and keep some
> windows not maximize like Empathy IM, Gnome Terminal, etc. But If you
> have a screen > 20", you maximize only one or two windows like Inkscape
> or Anjuta but not maximize the majority of windows. You just adpat the
> size of the window to this own content.
> 
> To summarize, more the screen is little, more you will maximize and vice
> versa. And why you maximize? To see more content in a window. So I
> wonder if it's not better to don't maximize beside the screen but beside
> the window content (like in Mac OS X).
> 
> And about maximise to focus on work: That depends on people. Some will
> mazimiser the window on which they work and some do not need it.
> 
> 
> Minimize to panel
> =
> 
> The use of this feature depends to the use of maximise. In Gnome 2 (or
> in other OS), why people use minimize to panel? For hide the window. So
> if the majority of windows are maximized, user don't need to minimize
> the window to panel for hide it. But if the majority of windows are not
> maximized, user really need to minimize the window to panel for hide it.
> 
> On Gnome Shell, we don't have a panel but we have a dash. So, I think we
> can have a "Minimize to" or a simply "hide window" feature. If user hide
> a window, it don't appears in the desktop and in the windows section on
> Activites overview but only on the Dash.
> 
> Button
> ==
> 
> Keep buttons would not be bad for the newcomers, they would not be lost.
> Buttons "Hide" and "Close" are needed, but maximize button is just for
> don't lost newcommers.




signature.asc
Description: This is a digitally signed message part
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Pat Suwalski]

On 25/02/11 02:20 PM, Sriram Ramkrishna wrote:

So out of curiosity, what sort of  tasks do both you and Robert do if
you don't mind me being nosy?


Normal day-to-day work and development. I have tonnes of windows opened, 
because I have to.


I alt-tab between windows (Process/Window Grouping makes this a real 
pain), minimize them when I need to focus (mentally). When I don't need 
one (usually a browser), I use Ctrl-W or Ctrl-Q to close it. I only use 
the close button when my left hand isn't free, in fact (coffee?). 
Occasionally alt-F4 is appropriate if the others aren't implemented and 
my hands are already on the keyboard.


When there's a terminal with an "ssh -X" session, I don't care to have 
it on my desktop. Same with the output from the programs I'm working on 
(unless they crash and I have to review).


I depend on the panel list of icons, because they show me a one-to-one 
mapping of my windows, minimized or not, *in the order I opened them*. 
This is where the Win7 strip definitely doesn't cut it for me, 
gnome-shell makes it much more difficult, and MacOSX makes me somewhat 
unproductive.


Lastly, I absolutely hate virtual desktops. That might be an 
overstatement, but I avoid using them. Things get lost very easily, and 
it's a pain to set them up on every boot. I find a single desktop over 
two monitors the right balance. I'll keep a blank extra virtual desktop 
for when I need to quickly do something in programs that open way too 
many windows, like Gimp. That last example is the only thing I like 
about the concept of workspaces in Mutter.


I think a better example, though, might be my brother. He's a 
uni-student/gamer, and he doesn't like to reboot, ever. He has at any 
given time, at least 25 Firefox or Chrome tabs open. He has at least 20 
windows in his panel as well, right where he likes them. I predict that 
he would be very uncomfortable without that window-to-panel relation as 
well.


Thanks,
--Pat
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Christian Jäger]

Of course I still favour my idea that windows should be minimized to
thumbnails on the very workspace, though. If you minimize all windows on
your workspace you are effectively in the overview, and that would blend
to two modes of working quite naturally.

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Christian Jäger]

On Fr, 2011-02-25 at 11:46 -0700, Robert Park wrote:
> The more I think about my previous suggestion ('hide on new workspace'
> button at left and close button at right), the more I like it. It's
> because both actions will result in the window disappearing, but the
> buttons are far apart, so there's no chance to accidentally hit one
> when you meant the other. 

The idea is intriguing.But perhaps all it needs is to make current
behavior of the minimze-button more clear; i.e. where the window
'physically' goes. Let the thumbnail of the current workspace slide in
briefly during the minimize-animation and highlight the thumbnailed
version of the minimized window with a subtile glow on the
workspace-thumbnail before it slides out. That would help a lot to make
things clear, I think.

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Sriram Ramkrishna]

On Fri, Feb 25, 2011 at 11:13 AM, Pat Suwalski  wrote:

> On 25/02/11 01:46 PM, Robert Park wrote:
>
>> Agreed. I'm all for experimenting with new ideas, but the close button
>> MUST stay. Minimize I never use except by accident so I am happy to
>> see it go. Maximize I do use, but I'm happy with things like double
>> clicking the titlebar, if it means less clutter on the titlebar, but
>> every app and every window needs an easy and immediate method to close
>> it, and there can't possibly be anything better than the existing
>> close button.
>>
>
> I could say exactly the same about the minimize button, that there needs to
> be a way to quickly make a window get out of my sight.
>
> On the balance of things, I use minimize more than close, by a long shot.


So out of curiosity, what sort of  tasks do both you and Robert do if you
don't mind me being nosy?

sri
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Pat Suwalski]

On 25/02/11 01:46 PM, Robert Park wrote:

Agreed. I'm all for experimenting with new ideas, but the close button
MUST stay. Minimize I never use except by accident so I am happy to
see it go. Maximize I do use, but I'm happy with things like double
clicking the titlebar, if it means less clutter on the titlebar, but
every app and every window needs an easy and immediate method to close
it, and there can't possibly be anything better than the existing
close button.


I could say exactly the same about the minimize button, that there needs 
to be a way to quickly make a window get out of my sight.


On the balance of things, I use minimize more than close, by a long shot.

--Pat
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Robert Park]

On Fri, Feb 25, 2011 at 8:56 AM, Christian Jäger
 wrote:
> The 'close'-button might well be THE single attribute you expect any
> window to have; if there's a window you expect to be able to close this
> window. Also it would be pretty inconsistent if there's a close-button
> in the overview when there is none in the worspace view.

Agreed. I'm all for experimenting with new ideas, but the close button
MUST stay. Minimize I never use except by accident so I am happy to
see it go. Maximize I do use, but I'm happy with things like double
clicking the titlebar, if it means less clutter on the titlebar, but
every app and every window needs an easy and immediate method to close
it, and there can't possibly be anything better than the existing
close button.

The more I think about my previous suggestion ('hide on new workspace'
button at left and close button at right), the more I like it. It's
because both actions will result in the window disappearing, but the
buttons are far apart, so there's no chance to accidentally hit one
when you meant the other.

> The whole idea of substituting a straightforward, in-your-face obvious
> way of closing a window by an action that is more complicated and whose
> discoverabilty is dubious to say the least, seems  quite  unmotivated.
> There is simply no compelling reason for this change and lots of good
> reasons against it. It seems more like an attempt at finding a
> justfication for the existence of the application menu in the top bar -
> which is currently lacking.

The application menu will grow in importance as apps increasingly add
support for it. I like the idea of it a lot because it means one
unique space that never moves where you can always find a menu for the
app that you're using. But you're right, it's currently
under-utilized.

-- 
http://exolucere.ca
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Christian Jäger]

On Do, 2011-02-24 at 20:58 -0500, Marina Zhurakhinskaya wrote:

> > There are some apps where using the "quit" button won't make sense.
> > Terminals being the foremost one. I believe for gnome-terminal they
> > are still using the same factory so a quit on terminal it remove all
> > terminals, right?
> 
> For that, there could be a "Close Window" option in the application menu.
> 
> In any case, this is just some idea that I wanted to put out there for 
> designers. Seemed to work for me, but it's up to designers to decide if it 
> fits in with the overall experience.

The 'close'-button might well be THE single attribute you expect any
window to have; if there's a window you expect to be able to close this
window. Also it would be pretty inconsistent if there's a close-button
in the overview when there is none in the worspace view.

The whole idea of substituting a straightforward, in-your-face obvious
way of closing a window by an action that is more complicated and whose
discoverabilty is dubious to say the least, seems  quite  unmotivated.
There is simply no compelling reason for this change and lots of good
reasons against it. It seems more like an attempt at finding a
justfication for the existence of the application menu in the top bar -
which is currently lacking.

Greets,
Chris


___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Marina Zhurakhinskaya]

> On Wed, 2011-02-23 at 16:34 -0500, Marina Zhurakhinskaya wrote:
> 
> > While the close operation is common, it's not frequent, and
> > therefore
> > might not require visual representation on-screen all the time.
> 
> Huh, I use the Close button pretty frequently. I guess I'm still
> scarred from when Esc didn't work in every dialog by default.
> 
> 
> 
> Me too. I don't do file->quit since it's a lot easier to access the
> close button. But not all apps behave the same unfortunately.

I meant that you only need to close things a handful of times per session, not 
that you would use a different way to do that if there is a close button. You 
mostly would close the applications/windows that you open for temporary use, 
but you won't close most of the windows you have open throughout the session.

> There are some apps where using the "quit" button won't make sense.
> Terminals being the foremost one. I believe for gnome-terminal they
> are still using the same factory so a quit on terminal it remove all
> terminals, right?

For that, there could be a "Close Window" option in the application menu.

In any case, this is just some idea that I wanted to put out there for 
designers. Seemed to work for me, but it's up to designers to decide if it fits 
in with the overall experience.

Marina
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Sriram Ramkrishna]

On Thu, Feb 24, 2011 at 11:31 AM, Federico Mena Quintero  wrote:

> On Wed, 2011-02-23 at 16:34 -0500, Marina Zhurakhinskaya wrote:
>
> > While the close operation is common, it's not frequent, and therefore
> > might not require visual representation on-screen all the time.
>
> Huh, I use the Close button pretty frequently.  I guess I'm still
> scarred from when Esc didn't work in every dialog by default.
>

Me too.  I don't do file->quit since it's a lot easier to access the close
button.  But not all apps behave the same unfortunately.


>
> > Both the application menu in the top bar and the close buttons in the
> > overview are well discoverable. Right now, the application menu has
> > one Quit option, and the user actually needs to make a decision
> > whether they want to fully quit the application with all its windows
> > before going for that option. Having both Quit and Close Window (if
> > applicable) options in that menu would inform the user of the choice
> > they have and allow to use that feature as the central way of closing
> > a window or an application.
>
> My main problem with removing the Close button is a combination of
> things:
>
> - The Close button is relevant to a single window.  It's nicely *in* the
> window right now.  Your proposal would put it far away from the window
> (thus losing context), and would make it not immediately visible (you'd
> need to open the app menu first - probably discoverable, as you say, but
> far from obvious).  My experience with non-technical users (say, my
> wife) is that if they don't see something on the screen, they won't know
> that that something is actually available.
>

There are some apps where using the "quit" button won't make sense.
 Terminals being the foremost one.  I believe for gnome-terminal they are
still using the same factory so a quit on terminal it remove all terminals,
right?

As a new user I think I would feel pretty intimidated if I got a bunch of
windows that didn't have a close button.  It would require some training for
them to use the other method because just about every other UI out there
uses a close button and is an established UI.  Combined with the fact that
there are exceptions like the terminal, I think that would lead to some
confusion.

sri
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Federico Mena Quintero]

On Wed, 2011-02-23 at 16:34 -0500, Marina Zhurakhinskaya wrote:

> While the close operation is common, it's not frequent, and therefore
> might not require visual representation on-screen all the time. 

Huh, I use the Close button pretty frequently.  I guess I'm still
scarred from when Esc didn't work in every dialog by default.

> Both the application menu in the top bar and the close buttons in the
> overview are well discoverable. Right now, the application menu has
> one Quit option, and the user actually needs to make a decision
> whether they want to fully quit the application with all its windows
> before going for that option. Having both Quit and Close Window (if
> applicable) options in that menu would inform the user of the choice
> they have and allow to use that feature as the central way of closing
> a window or an application.

My main problem with removing the Close button is a combination of
things:

- The Close button is relevant to a single window.  It's nicely *in* the
window right now.  Your proposal would put it far away from the window
(thus losing context), and would make it not immediately visible (you'd
need to open the app menu first - probably discoverable, as you say, but
far from obvious).  My experience with non-technical users (say, my
wife) is that if they don't see something on the screen, they won't know
that that something is actually available.

- The Close button is the "get me out of here" safety exit.  You
wouldn't remove the Back button on a browser just because you can also
access it from the menus.

  Federico

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Marina Zhurakhinskaya]

While the close operation is common, it's not frequent, and therefore might not 
require visual representation on-screen all the time. Similar reason to why we 
don't want to have application launchers on screen all the time.

Both the application menu in the top bar and the close buttons in the overview 
are well discoverable. Right now, the application menu has one Quit option, and 
the user actually needs to make a decision whether they want to fully quit the 
application with all its windows before going for that option. Having both Quit 
and Close Window (if applicable) options in that menu would inform the user of 
the choice they have and allow to use that feature as the central way of 
closing a window or an application. It's a menu that is visible in the desktop 
view, so it's more of 1.5 step operation with a click - move to the option you 
want - release.

So the goal would be removing a full UI concept and centralizing the options 
related to the operation in another existing part of UI. That would make the 
application menu more functional, inform the user better, reduce redundant 
options, AND make for a sleeker look :).

Marina

- Original Message -
From: "Federico Mena Quintero" 
To: "Marina Zhurakhinskaya" 
Cc: gnome-shell-list@gnome.org
Sent: Wednesday, February 23, 2011 11:12:41 AM
Subject: Re: Window controls for GNOME 3

On Tue, 2011-02-22 at 21:48 -0500, Marina Zhurakhinskaya wrote:

> We've added two other ways for closing windows/applications in GNOME
> 3: a per-window close icon in the overview and a quit option in the
> application menu. The only thing that is missing is the UI ability to
> close an individual window from the desktop view. I mostly used the
> Quit option in the application menu for closing single instance
> applications, such as calculator or gconf-editor, but I had to
> remember to go to the overview if I wanted to close a Firefox
> Downloads window or an individual gedit window I no longer needed.

Be careful with this line of thinking.  You are replacing a one-step,
common operation with a two-step one that is not immediately
discoverable.

It's like saying, "well, we could show the current window's title next
to the Activities button, and since you can already move windows with
Alt-drag, we can remove titlebars altogether" :)

In general, sleek looks just for the sake of sleek looks are not good.
Things have to be comfortable to use.  A knife's handle has an awkward
shape, but the bump in the front is so your hand doesn't slip forward
and you get cut; the bump in the back is so you can pull out the knife
easily; the bump in the center is to accomodate the inside of your palm.
A knife with a sleek, cylindrical handle wouldn't be very nice to use.

  Federico

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Robert Park]

On Wed, Feb 23, 2011 at 12:30 PM, Jason D. Clinton  
wrote:
> Initial reaction is that you've reintroduced a screen element that is
> analogous to the old workspace switcher applet in the GNOME 2 panel: it can
> be hit by a user who has no idea what a workspace is and who suddenly finds
> their window missing without any idea how to get it back.

Ok, but currently with there being a minimize button with no taskbar,
we are already in a situation where users can hit a button and not
know how to get their window back. I'm simply proposing we adapt the
concept of the 'minimize' button to work with workspaces.

Either way, the user has to go to the activities menu to find their
window again, but with my suggestion there's now a designated area for
hidden windows, and the UI for it is completely consistent with the
existing workspaces, because it is just another workspace ;-)

> But maybe with the right level of animation it could be made clear. Not
> sure.

Well, it could animate into the upper left corner, where the
'Activities' button is. Then users will go there looking for it and
they will find the workspaces.


-- 
http://exolucere.ca
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Jason D. Clinton]

On Wed, Feb 23, 2011 at 13:23, Robert Park  wrote:

> [-]Window Title[X]
>
> So that's the 'hide to new workspace' button at left, and close button
> at right, with title centered. Nice and balanced, eh? What does
> everybody think?
>

Initial reaction is that you've reintroduced a screen element that is
analogous to the old workspace switcher applet in the GNOME 2 panel: it can
be hit by a user who has no idea what a workspace is and who suddenly finds
their window missing without any idea how to get it back.

But maybe with the right level of animation it could be made clear. Not
sure.
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Robert Park]

On Wed, Feb 23, 2011 at 12:20 AM, Sriram Ramkrishna  wrote:
> Now, as I understand it the work around would be to move this to another
> workspace.  To do that would require a number of window management steps
> that I previous accomplished using a single button action.

What if there was a titlebar button that moved the window to a new
workspace? I think that would probably be the best of both worlds. The
people who want a 'minimize' button are provided with a single button
that makes the unwanted window disappear, but instead of relying on
the outdated taskbar metaphor, it fits into the 'new' workspace
metaphor that Gnome Shell is aiming towards.

This would be a natural fit for the Activities display, because now
there's no difference between 'hidden/minimized' windows and any other
workspace. There doesn't need to be a designated area for hidden
windows, because they're all just on other workspaces, which there is
already a good interface for.

Owen mentioned the titlebar being 'off balance' because of the title
being at center and all three buttons off to one side, so how about
this:

[-]Window Title[X]

So that's the 'hide to new workspace' button at left, and close button
at right, with title centered. Nice and balanced, eh? What does
everybody think?
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Miek Gieben]

[ Quoting Federico Mena Quintero in "Re: Window controls for GNOME 3"... ]
> It's like saying, "well, we could show the current window's title next
> to the Activities button, and since you can already move windows with
> Alt-drag, we can remove titlebars altogether" :)

yes please!

Have been using a one-pixel-wide window decoration for a few years
now. Love it.

grtz Miek


signature.asc
Description: Digital signature
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Federico Mena Quintero]

On Wed, 2011-02-23 at 12:07 +0100, Johannes Schmid wrote:

> Well this goes a bit off-topic the window control issue but the concept[1]
> of finding and reminding is simply not yet implemented in 3.0. Should be
> in 3.2 hopefully though.

You can see this work-in-progress here:

http://people.gnome.org/~federico/news-2011-02.html#zeitgeist-in-gnome-shell

This week I'm working on having a functional journal after the work in
the Zeitgeist hackfest.

  Federico

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Federico Mena Quintero]

On Tue, 2011-02-22 at 21:48 -0500, Marina Zhurakhinskaya wrote:

> We've added two other ways for closing windows/applications in GNOME
> 3: a per-window close icon in the overview and a quit option in the
> application menu. The only thing that is missing is the UI ability to
> close an individual window from the desktop view. I mostly used the
> Quit option in the application menu for closing single instance
> applications, such as calculator or gconf-editor, but I had to
> remember to go to the overview if I wanted to close a Firefox
> Downloads window or an individual gedit window I no longer needed.

Be careful with this line of thinking.  You are replacing a one-step,
common operation with a two-step one that is not immediately
discoverable.

It's like saying, "well, we could show the current window's title next
to the Activities button, and since you can already move windows with
Alt-drag, we can remove titlebars altogether" :)

In general, sleek looks just for the sake of sleek looks are not good.
Things have to be comfortable to use.  A knife's handle has an awkward
shape, but the bump in the front is so your hand doesn't slip forward
and you get cut; the bump in the back is so you can pull out the knife
easily; the bump in the center is to accomodate the inside of your palm.
A knife with a sleek, cylindrical handle wouldn't be very nice to use.

  Federico

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Ryan Peters]

On 02/23/2011 03:53 AM, Fabian A. Scherschel wrote:


On Wed, Feb 23, 2011 at 10:03 AM, Frederik > wrote:



No minimising does not mean that everything is maximised. You can
maximise a window by dragging it to the top (or by double-clicking)
and de-maximise it by dragging it from the top (or by
double-clicking).


That does make sense. I'll really have to install the F15 Beta soon to 
check this out in more detail.


So there won't be any way to minimise windows at all then? Not saying 
this is a bad idea, I'm just trying to get the facts straight. :)


Fab


___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list
You can minimize windows by right-clicking the title bar, ALT+F9, 
ALT+SPACE and then N, or changing your preferences to include a minimize 
button. If I remember correctly, you can still add and remove and move 
around buttons at your leisure, though I'm not sure what benefits they 
would bring. The reason they're hiding the minimize function isn't 
because its useless, but because it's been mostly deprecated now that 
Shell has an infinite list of workspaces that you can drag and drop 
windows on to. If there's a better way to implement "minimization" or 
"hiding" windows, it should be implemented around 3.2 or 3.4.


By the way, removing the close button by default, while some people 
might like it, I don't really understand. It "reduces visual clutter", 
yes, but I don't want to have to go to the activities overview just to 
close a tiny window, you know? Otherwise, I completely agree with the 
decision to remove those two buttons and I can't wait until GNOME Shell 
is released as stable! :)


- Ryan Peters
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Gendre Sebastien]

Le mardi 22 février 2011 à 19:21 -0500, Owen Taylor a écrit :
> 
> Feedback?
> =
> 
> If people want to give their thoughts here, that's fine, but I don't think a 
> mailing list debate is the best way to come to a decision, so the decision 
> above should be considered basically final for the 3.0 release.
> 
> The real form of feedback that we need going from GNOME 3.0 to 3.2 is careful 
> observation of how users are using GNOME 3 - are they figuring out how to use 
> the overview and workspaces and message tray as we expect them to use them, 
> or are they doing cumbersome workarounds because we took away essential 
> features.
> 
> - Owen

This is just a personal analisys based what I have based on what I have
seen since 5 years.

Maximize



The usage of maximize depends to the display size and resolution. If you
have a screen < 14",  you maximize the majority of windows and keep some
windows not maximize like Empathy IM, Gnome Terminal, etc. But If you
have a screen > 20", you maximize only one or two windows like Inkscape
or Anjuta but not maximize the majority of windows. You just adpat the
size of the window to this own content.

To summarize, more the screen is little, more you will maximize and vice
versa. And why you maximize? To see more content in a window. So I
wonder if it's not better to don't maximize beside the screen but beside
the window content (like in Mac OS X).

And about maximise to focus on work: That depends on people. Some will
mazimiser the window on which they work and some do not need it.


Minimize to panel
=

The use of this feature depends to the use of maximise. In Gnome 2 (or
in other OS), why people use minimize to panel? For hide the window. So
if the majority of windows are maximized, user don't need to minimize
the window to panel for hide it. But if the majority of windows are not
maximized, user really need to minimize the window to panel for hide it.

On Gnome Shell, we don't have a panel but we have a dash. So, I think we
can have a "Minimize to" or a simply "hide window" feature. If user hide
a window, it don't appears in the desktop and in the windows section on
Activites overview but only on the Dash.

Button
==

Keep buttons would not be bad for the newcomers, they would not be lost.
Buttons "Hide" and "Close" are needed, but maximize button is just for
don't lost newcommers.


-- 
Gendre Sebastien 


signature.asc
Description: This is a digitally signed message part
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Johannes Schmid]

Hi!

>   I understand that the desktop icons will go away. But then I need a
> replacement place where I can quickly access the documents that I work
> on during a week. The current state is confusing: desktop hardly
> accessible but no replacement in the sense of a quickly accessible
> document working set buffer.

Well this goes a bit off-topic the window control issue but the concept[1]
of finding and reminding is simply not yet implemented in 3.0. Should be
in 3.2 hopefully though.

Regards,
Johannes

[1]http://live.gnome.org/GnomeShell/Design/Whiteboards/FindingAndReminding

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Frederik]

On 02/23/2011 01:21 AM, Owen Taylor wrote:
> My main objection to removing them has been that I didn't think we really 
> understood the use case for minimization

My two use cases are:

* Removing distracting clutter out of sight (e.g. terminal with
  compilation process)

  Ok, I can move it to another workspace. It's just a little bit more
pointing and dragging action.

* Accessing an icon on the desktop (usually via minimise all / show
  desktop, but sometimes also by clicking minimise buttons)

  I understand that the desktop icons will go away. But then I need a
replacement place where I can quickly access the documents that I work
on during a week. The current state is confusing: desktop hardly
accessible but no replacement in the sense of a quickly accessible
document working set buffer.


Best regards

Frederik
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Fabian A. Scherschel]

On Wed, Feb 23, 2011 at 10:03 AM, Frederik  wrote:

>
> No minimising does not mean that everything is maximised. You can
> maximise a window by dragging it to the top (or by double-clicking)
> and de-maximise it by dragging it from the top (or by double-clicking).
>

That does make sense. I'll really have to install the F15 Beta soon to check
this out in more detail.

So there won't be any way to minimise windows at all then? Not saying this
is a bad idea, I'm just trying to get the facts straight. :)

Fab
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Frederik]

On 02/23/2011 09:36 AM, Fabian A. Scherschel wrote:
> Hi, everyone!
> 
> Sorry if this has been asked before, but if we maximise everything,
> how are we handling windows that aren't designed to be maximized (ie.
> IM and microblogging clients and the like)?

No minimising does not mean that everything is maximised. You can
maximise a window by dragging it to the top (or by double-clicking)
and de-maximise it by dragging it from the top (or by double-clicking).

Best regards,

Frederik
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Fabian A. Scherschel]

Hi, everyone!

Sorry if this has been asked before, but if we maximise everything, how are
we handling windows that aren't designed to be maximized (ie. IM and
microblogging clients and the like)? How would I go about hiding those, is
this functionality that the app needs to provide now as minimise to a
notification area icon?

Hope asking this isn't a pain...
Fab




On Wed, Feb 23, 2011 at 8:20 AM, Sriram Ramkrishna wrote:

>
>
> On Tue, Feb 22, 2011 at 4:21 PM, Owen Taylor  wrote:
>
>> OK, I promised Jon McCann to write a mail here giving information on my
>> thoughts on removing the minimize and maximize buttons since I've been
>> resisting the request of the
>> Why do people minimize windows?
>> ===
>>
>> I think the first thing to realize is that minimization doesn't make sense
>> if you maximize everything. If you run everything maximized, then it just
>> doesn't enter in ... switching between
>> Feedback?
>> =
>>
>> If people want to give their thoughts here, that's fine, but I don't think
>> a mailing list debate is the best way to come to a decision, so the decision
>> above should be considered basically final for the 3.0 release.
>>
>> The real form of feedback that we need going from GNOME 3.0 to 3.2 is
>> careful observation of how users are using GNOME 3 - are they figuring out
>> how to use the overview and workspaces and message tray as we expect them to
>> use them, or are they doing cumbersome workarounds because we took away
>> essential features.
>>
>>
>
> Hi Owen, my two cents.  I'm still going through the process of seeing how
> much pain it is for not having minimizing.  The first instance of wanting to
> minimize something is when I have a terminal that is scrolling debug
> messages and I'm not interested in its contents at the moment.  I really
> want to move it out of my sight.  I'm not exactly interested in the window
> unless something broken has happened.  I would probably say the same if I'm
> on a web browser that is on Pandora or last.fm or some such web page that
> has dynamic content that I'm not really interested in looking at because I'm
> using it as a service but it's using real estate that is distracting me.
>
> Now, as I understand it the work around would be to move this to another
> workspace.  To do that would require a number of window management steps
> that I previous accomplished using a single button action.  The other option
> is to use a key combination.  Now admittedly, things like scrolling texts in
> terminals could be argued as expert mode and one could expect that a key
> combination for those people should be sufficient.  But I'm not sure of the
> pandora or last.fm type thing.
>
> Other than that I haven't really felt an urge to minimize anything.
>
> sri
>
> ___
> 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

Re: Window controls for GNOME 3

[Sriram Ramkrishna]

On Tue, Feb 22, 2011 at 4:21 PM, Owen Taylor  wrote:

> OK, I promised Jon McCann to write a mail here giving information on my
> thoughts on removing the minimize and maximize buttons since I've been
> resisting the request of the
> Why do people minimize windows?
> ===
>
> I think the first thing to realize is that minimization doesn't make sense
> if you maximize everything. If you run everything maximized, then it just
> doesn't enter in ... switching between
> Feedback?
> =
>
> If people want to give their thoughts here, that's fine, but I don't think
> a mailing list debate is the best way to come to a decision, so the decision
> above should be considered basically final for the 3.0 release.
>
> The real form of feedback that we need going from GNOME 3.0 to 3.2 is
> careful observation of how users are using GNOME 3 - are they figuring out
> how to use the overview and workspaces and message tray as we expect them to
> use them, or are they doing cumbersome workarounds because we took away
> essential features.
>
>

Hi Owen, my two cents.  I'm still going through the process of seeing how
much pain it is for not having minimizing.  The first instance of wanting to
minimize something is when I have a terminal that is scrolling debug
messages and I'm not interested in its contents at the moment.  I really
want to move it out of my sight.  I'm not exactly interested in the window
unless something broken has happened.  I would probably say the same if I'm
on a web browser that is on Pandora or last.fm or some such web page that
has dynamic content that I'm not really interested in looking at because I'm
using it as a service but it's using real estate that is distracting me.

Now, as I understand it the work around would be to move this to another
workspace.  To do that would require a number of window management steps
that I previous accomplished using a single button action.  The other option
is to use a key combination.  Now admittedly, things like scrolling texts in
terminals could be argued as expert mode and one could expect that a key
combination for those people should be sufficient.  But I'm not sure of the
pandora or last.fm type thing.

Other than that I haven't really felt an urge to minimize anything.

sri
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Window controls for GNOME 3

[Marina Zhurakhinskaya]

As Owen described, I found it relatively easy to change my workflow to not use 
minimization. It does make more sense to use a positive action for switching to 
a different window I want, rather than a negative action of minimizing and then 
seeing what I have in front of me.

I found it very useful to remove the close button as well. I originally did 
that to wean myself off going for the minimize button and not finding it there, 
but I'm also wondering whether we can get rid of this one-of icon completely. 
We've added two other ways for closing windows/applications in GNOME 3: a 
per-window close icon in the overview and a quit option in the application 
menu. The only thing that is missing is the UI ability to close an individual 
window from the desktop view. I mostly used the Quit option in the application 
menu for closing single instance applications, such as calculator or 
gconf-editor, but I had to remember to go to the overview if I wanted to close 
a Firefox Downloads window or an individual gedit window I no longer needed.

I think having a second option "Close Window" in the application menu if the 
application has multiple windows would solve this problem and allow us to get 
rid of the visual clutter of a lone close icon in the titlebar.

If anyone wants to try it out without the close icon in the titlebar, just run 
' gconftool-2 -s -t string  /desktop/gnome/shell/windows/button_layout "" ' and 
restart gnome-shell.

Marina

- Original Message -
From: "Owen Taylor" 
To: gnome-shell-list@gnome.org
Sent: Tuesday, February 22, 2011 7:21:08 PM
Subject: Window controls for GNOME 3

OK, I promised Jon McCann to write a mail here giving information on my 
thoughts on removing the minimize and maximize buttons since I've been 
resisting the request of the designers to remove these buttons.

My main objection to removing them has been that I didn't think we really 
understood the use case for minimization, or how we would satisfy that use 
case. The pattern of use for minimization is that a lot of people don't use 
minimization at all, and other people use it extensively. 

It didn't make sense to me to remove something that we don't understand with 
idea that we'd add it back later if it turned out to be needed. To make people 
suffer, and have it be a major focus of the GNOME 3 transition, then go and add 
it back anyways.

On the other hand, if we do have a reasonable sense that we have workflows that 
basically will work for everybody, then I'm more comfortable removing 
minimization. So, this mail is reporting on my attempt to come to a better 
understanding of minimization and how it fits in with the GNOME 3 workflow.

Why do people minimize windows?
===

I think the first thing to realize is that minimization doesn't make sense if 
you maximize everything. If you run everything maximized, then it just doesn't 
enter in ... switching between windows is switching between windows. (I 
personally typically maximize everything, so I don't minimize windows.)

Reasons people minimize:

 * Because they like a tidy desktop. I think a lot of people are uncomfortable 
with a desktop where the window the are working with is overlapping other 
windows - where they are looking at a "gigantic pile of papers". These people 
like working with a few windows on a clean desktop. But they still have a 
larger set of windows open for less immediate tasks.

 * Because maximized windows interact badly with unmaximized windows. If I have 
a task that involves looking at multiple unmaximized windows, then I switch to 
a maximized web browser, getting back to the other state is hard - I have to 
select each window in turn without accidentally selecting the maximized window 
again.

 * To find a window behind other windows - if you generally select windows by 
clicking on them, and can't see the window or windows want, minimization can be 
a way of getting a big or maximized window out of the way and working with the 
windows underneath.

 * To "save windows for later" - if you open windows to represent tasks, like 
responding to an email or reading a PDF of a paper, you might not want them 
directly in your face interfering with the work you are doing first.

Are workspaces a replacement for minimization?
==

Since minimization is basically about wanting to work with a subset of windows, 
workspaces are clearly related to them. As compared to minimization they have 
advantages and disadvantages. The advantage is that they are stable - that is, 
I can have one workspace with a terminal and an editor, and another workspace 
with a web browser and my mail program and they will always stay that way - I 
won't lose the grouping. The disadvantage is that it isn't flexible - if I need 
the editor and web browser 

Window controls for GNOME 3

[Owen Taylor]

OK, I promised Jon McCann to write a mail here giving information on my 
thoughts on removing the minimize and maximize buttons since I've been 
resisting the request of the designers to remove these buttons.

My main objection to removing them has been that I didn't think we really 
understood the use case for minimization, or how we would satisfy that use 
case. The pattern of use for minimization is that a lot of people don't use 
minimization at all, and other people use it extensively. 

It didn't make sense to me to remove something that we don't understand with 
idea that we'd add it back later if it turned out to be needed. To make people 
suffer, and have it be a major focus of the GNOME 3 transition, then go and add 
it back anyways.

On the other hand, if we do have a reasonable sense that we have workflows that 
basically will work for everybody, then I'm more comfortable removing 
minimization. So, this mail is reporting on my attempt to come to a better 
understanding of minimization and how it fits in with the GNOME 3 workflow.

Why do people minimize windows?
===

I think the first thing to realize is that minimization doesn't make sense if 
you maximize everything. If you run everything maximized, then it just doesn't 
enter in ... switching between windows is switching between windows. (I 
personally typically maximize everything, so I don't minimize windows.)

Reasons people minimize:

 * Because they like a tidy desktop. I think a lot of people are uncomfortable 
with a desktop where the window the are working with is overlapping other 
windows - where they are looking at a "gigantic pile of papers". These people 
like working with a few windows on a clean desktop. But they still have a 
larger set of windows open for less immediate tasks.

 * Because maximized windows interact badly with unmaximized windows. If I have 
a task that involves looking at multiple unmaximized windows, then I switch to 
a maximized web browser, getting back to the other state is hard - I have to 
select each window in turn without accidentally selecting the maximized window 
again.

 * To find a window behind other windows - if you generally select windows by 
clicking on them, and can't see the window or windows want, minimization can be 
a way of getting a big or maximized window out of the way and working with the 
windows underneath.

 * To "save windows for later" - if you open windows to represent tasks, like 
responding to an email or reading a PDF of a paper, you might not want them 
directly in your face interfering with the work you are doing first.

Are workspaces a replacement for minimization?
==

Since minimization is basically about wanting to work with a subset of windows, 
workspaces are clearly related to them. As compared to minimization they have 
advantages and disadvantages. The advantage is that they are stable - that is, 
I can have one workspace with a terminal and an editor, and another workspace 
with a web browser and my mail program and they will always stay that way - I 
won't lose the grouping. The disadvantage is that it isn't flexible - if I need 
the editor and web browser open at once then I have to go to the Activities 
Overview and move the web browser, and then my web browser and mail program 
can't be open at once until I move it back.

Experiences with removing the minimize button
=

I asked the two people on the Red Hat GNOME Shell team who I knew heavily used 
the minimize button to try removing it and report back to me about their 
experiences. (These obviously are not typical users using typical applications, 
but they provide some data about how people actually use the minimize button.)

 Marina:

   Marina generally used the minimize button when switching between a) coding
   on the shell with non-maximized terminal and editor windows b) doing tasks
   in a maximized web browser. She would minimize the web browser
   to get from a) to b) and then use the overview to get back to the minimized
   web browser.

   When she turned off the minimize button, she was initially very frustrated
   because she kept going to where the minimize button was but finding only
   the "useless" close button there. She then turned off the close button as
   well and was much happier with the result. [I don't think this is
   really an option however - there are going to be too many cases where apps
   are designed expecting a close button.]

   No problems were reported with:

   - Having the maximized web browser window still visible under the coding
 windows... this was reported to not be distracting.
   - Having to separately activate the editor and terminal windows from
 the overview.

   Workspaces were found not to be useful because they didn't allow to
   easily switch between working with a fullscreen webbrowser, to 
   using a non-full-screen web brows