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
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
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
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?
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
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
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
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
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
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
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
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*
On Wed, Mar 2, 2011 at 4:01 PM, Akshay Dua aks...@cs.pdx.edu 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
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
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.
(What happened to your mail client line-wrapping settings?)
On Tue, Feb 22, 2011 at 4:21 PM, Owen Taylor otay...@redhat.com wrote:
The maximize button
===
The above was about minimization - but the request was also to remove the
maximize button. This is a little different
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 otay...@redhat.com wrote:
The maximize button
===
The above was about minimization - but the request was
Hey Sandy,
On Tue, Mar 1, 2011 at 10:54 AM, Sandy Armstrong
sanfordarmstr...@gmail.com wrote:
(What happened to your mail client line-wrapping settings?)
On Tue, Feb 22, 2011 at 4:21 PM, Owen Taylor otay...@redhat.com wrote:
The maximize button
===
The above was about
2011/3/1 John Stowers john.stowers.li...@gmail.com:
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
On 03/01/2011 03:52 PM, Alberto Ruiz wrote:
2011/3/1 John Stowersjohn.stowers.li...@gmail.com:
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
On Tue, Mar 1, 2011 at 7:35 PM, Ryan Peters slosh...@sbcglobal.net 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?
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?
On Fri, Feb 25, 2011 at 8:56 AM, Christian Jäger
christian.jae...@rub.de 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
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 Fri, Feb 25, 2011 at 12:20 PM, Sriram Ramkrishna s...@ramkrishna.me 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
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
On Fri, Feb 25, 2011 at 3:05 PM, Pat Suwalski p...@suwalski.net 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
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
On Thu, Feb 24, 2011 at 11:31 AM, Federico Mena Quintero feder...@gnome.org
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
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
On Wed, Feb 23, 2011 at 10:03 AM, Frederik scumm_fr...@gmx.net 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
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
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
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
On 02/23/2011 03:53 AM, Fabian A. Scherschel wrote:
On Wed, Feb 23, 2011 at 10:03 AM, Frederik scumm_fr...@gmx.net
mailto:scumm_fr...@gmx.net 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)
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:
[ 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
On Wed, Feb 23, 2011 at 12:20 AM, Sriram Ramkrishna s...@ramkrishna.me 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
On Wed, Feb 23, 2011 at 13:23, Robert Park rbp...@exolucere.ca 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
On Wed, Feb 23, 2011 at 12:30 PM, Jason D. Clinton m...@jasonclinton.com
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
: Federico Mena Quintero feder...@gnome.org
To: Marina Zhurakhinskaya mari...@redhat.com
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
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
On Tue, Feb 22, 2011 at 4:21 PM, Owen Taylor otay...@redhat.com 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?
43 matches
Mail list logo
