[Ayatana] Multiple virtual desktops in Unity

[Jorge Ortega]

I find Unity approach to multiple virtual desktops extremely half-hearted:
it just provides the option to used them and an icon which you can't remove
from the bar.

Unity could use virtual desktop in a transparent way:

1-Don't show icon if only a desktop is being used.
2-*Apps. should open in a new virtual desktop each. (by default)*
3-When more than one app. is open then the icon to switch desktops appears
in the bar (it has to be very prominent)
4-Exceptions should be made, probably for configuration tools. For instance,
when you open pulseaudio sound preferences this window should appear in the
active dektop. The understanding is you are just checking on something or
carrying out a very transitory task and close the app straight away. A case
could be made for multiple isntances of the file manger as well: most of the
time we are transferring files between windows.
5-The transitions between desktops (apps. in fact) should be very smooth and
not sight-tiring.

In short:
current behaviour: apps open in the same space and the user has to put them
in different deskops.
suggested behaviour: apps open in their own space and the user has to put
put them manually in the same desktops if they want to do it.

Which such a behaviour the concept of virtual desktops becomes transparent:
people would use them without actually realizing, you don't decide to use
the feature or not, the feature is at the core of how your computer
works.The way to do this doesn't have to be the traditional zoom out/drag
and drop/zoon in: drag an icon onto other icon to move apps to the same
space/desktop and gain focus on this desktop immediately.

In this context minimizing seems to loose any sense: why do you wan to
minimize an app that is not sharing its space with anything else?

The above proposal has far reaching consecuences but would go a very long
way towards simplifying how people use their computers.


Failing to implement the above then please, get rid of the desktop-switcher
icon and  bring back the possibility to minimize windows from the launcher.


Jorge
-
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Multiple virtual desktops in Unity

[Jorge Ortega]

Hi jamur,

 I don't want the shell to make arbitrary decisions for me
>

the decision to open apps on the same workspace is as arbitrary  as the
decision to give them their own workspace.

Now, I don't have hard data to support this but there it goes anyway: most
of the times, when people work with one app. they work with (focus on) just
one app at a time. This is even if they have several open: torrent client
downloading in the background, the music player playing in the background,
the browser open and ready for next time you check facebook or what not. I
know that the occasions when you actually need to interact with more than
one app at a time are not rare: but I would argue that they are the
minority.

You are right to say  that just now mainly power users use multiple
workspaces. But this is mainly down to how badly designed this feature is.
There is nothing advanced in working in an orderly and and uncluttered way:
this is how it should be by default, no by hard-won skills.

>From a personal (and anecdotal) point of view: over the years every now and
again I've tried to incorporate the use of multiple workspaces in my
workflow. I was obviously trying to improve the clutter on the desktop like
everyone else. It's never worked for me in the current form.

All the other stuff: what to do with multiple instances of an app. how to
switch between apps, etc is really just a matter of detail, meaning that
they can be worked out.

On 14 April 2011 18:14, Jamu Kakar  wrote:

> Hi Jorge,
>
> On Thu, Apr 14, 2011 at 11:18 AM, Jorge Ortega
>  wrote:
> > I find Unity approach to multiple virtual desktops extremely
> half-hearted:
> > it just provides the option to used them and an icon which you can't
> remove
> > from the bar.
> >
> > Unity could use virtual desktop in a transparent way:
> >
> > 1-Don't show icon if only a desktop is being used.
> > 2-Apps. should open in a new virtual desktop each. (by default)
>
> I want to choose how I use workspaces.  I don't want the shell to make
> arbitrary decisions for me.  My impression is that workspaces are used
> primarily by power users who know what they want.  Putting a default
> in place that gets in the way of that sounds like a bad idea.
>
> > 3-When more than one app. is open then the icon to switch desktops
> appears
> > in the bar (it has to be very prominent)
>
> This is a bit like the pattern used to stick an icons in the launcher.
> You first have to start an application and only then can you make it
> sticky.  I find this behaviour in the launcher confusing.  When I
> started using Unity I expected to be able to drag applications from
> the application dash and stick them in the Launcher.
>
> I suspect having to do something before you know that workspaces exist
> would be similarly confusing.  Also, for those users that aren't
> familiar with them, they'd probably be confused as to why two icons
> appear in the launcher when they start an application instead of one
> (the desktop switcher and the application icon).
>
> Also, how will workspace focus behave?  If I have Firefox running on
> workspace one and I then start Evolution, will it magically take me to
> workspace two?  If so, I won't be able to Alt-Tab back to Firefox.  If
> not, Evolution will appear not to have started.  In the first case,
> this will force me to either (a) use the mouse to click on the Firefox
> icon or (b) know about Alt-Shift-Tab (which I think is not well
> known).  In the second case, I'll have to know that Evolution started
> somewhere else and figure out where and how to get there.
>
> > 4-Exceptions should be made, probably for configuration tools. For
> instance,
> > when you open pulseaudio sound preferences this window should appear in
> the
> > active dektop. The understanding is you are just checking on something or
> > carrying out a very transitory task and close the app straight away. A
> case
> > could be made for multiple isntances of the file manger as well: most of
> the
> > time we are transferring files between windows.
>
> This sounds tricky to get right.
>
> > 5-The transitions between desktops (apps. in fact) should be very smooth
> and
> > not sight-tiring.
>
> Agreed.
>
> > In short:
> > current behaviour: apps open in the same space and the user has to put
> them
> > in different deskops.
>
> I usually move to the workspace I want before opening an application,
> if I want it to be on a different workspace than the one I'm on.
>
> > suggested behaviour: apps open in their own space and the user has to put
> > put them manually in the same desktops if they want to do it.
> >
> > Which s

Re: [Ayatana] Multiple virtual desktops in Unity

[Jorge Ortega]

Christopher,

But the new app would open right in front of you...

The way I see it is: there wouldn't be any defined number of desktops, and
definitely you shouldn't be able to see several empty desktops. The point is
that a new desktop is created every time you start a new app.

A compromise would be to make it action-dependent: clicking on the icon
would open in new desktop and draging and droping the icon would open it in
a new dektop (or viceverse). But this is probably far too much of a
compromise...

On 14 April 2011 20:15, Christopher Kahn  wrote:

> Hello Ayatana mailing list.
>
> This would cause a lot of confusion for users. When you're on a viewport
> and you click an icon you expect the program to open right in front of you.
> Whisking the user around to different viewports when he opens programs will
> cause confusion and frustration... it is not intuitive behaviour. And if I
> have 4 workspaces and open 5 programs, where does the 5th program open and
> why?
>
> My suggestion is to add an item to launchers' right-click menus: "Open in
> workspace X", when you click it you'd be be moved to that workspace with the
> new window open.
>
> --Chris
>
>
>
> On Thu, Apr 14, 2011 at 2:07 PM, Jorge Ortega 
> wrote:
>
>> Hi jamur,
>>
>>
>>  I don't want the shell to make arbitrary decisions for me
>>>
>>
>> the decision to open apps on the same workspace is as arbitrary  as the
>> decision to give them their own workspace.
>>
>> Now, I don't have hard data to support this but there it goes anyway: most
>> of the times, when people work with one app. they work with (focus on) just
>> one app at a time. This is even if they have several open: torrent client
>> downloading in the background, the music player playing in the background,
>> the browser open and ready for next time you check facebook or what not. I
>> know that the occasions when you actually need to interact with more than
>> one app at a time are not rare: but I would argue that they are the
>> minority.
>>
>> You are right to say  that just now mainly power users use multiple
>> workspaces. But this is mainly down to how badly designed this feature is.
>> There is nothing advanced in working in an orderly and and uncluttered way:
>> this is how it should be by default, no by hard-won skills.
>>
>> From a personal (and anecdotal) point of view: over the years every now
>> and again I've tried to incorporate the use of multiple workspaces in my
>> workflow. I was obviously trying to improve the clutter on the desktop like
>> everyone else. It's never worked for me in the current form.
>>
>> All the other stuff: what to do with multiple instances of an app. how to
>> switch between apps, etc is really just a matter of detail, meaning that
>> they can be worked out.
>>
>> On 14 April 2011 18:14, Jamu Kakar  wrote:
>>
>>> Hi Jorge,
>>>
>>> On Thu, Apr 14, 2011 at 11:18 AM, Jorge Ortega
>>>  wrote:
>>> > I find Unity approach to multiple virtual desktops extremely
>>> half-hearted:
>>> > it just provides the option to used them and an icon which you can't
>>> remove
>>> > from the bar.
>>> >
>>> > Unity could use virtual desktop in a transparent way:
>>> >
>>> > 1-Don't show icon if only a desktop is being used.
>>> > 2-Apps. should open in a new virtual desktop each. (by default)
>>>
>>> I want to choose how I use workspaces.  I don't want the shell to make
>>> arbitrary decisions for me.  My impression is that workspaces are used
>>> primarily by power users who know what they want.  Putting a default
>>> in place that gets in the way of that sounds like a bad idea.
>>>
>>> > 3-When more than one app. is open then the icon to switch desktops
>>> appears
>>> > in the bar (it has to be very prominent)
>>>
>>> This is a bit like the pattern used to stick an icons in the launcher.
>>> You first have to start an application and only then can you make it
>>> sticky.  I find this behaviour in the launcher confusing.  When I
>>> started using Unity I expected to be able to drag applications from
>>> the application dash and stick them in the Launcher.
>>>
>>> I suspect having to do something before you know that workspaces exist
>>> would be similarly confusing.  Also, for those users that aren't
>>> familiar with them, they'd probably be confused as to why two icons
>>> appear in

Re: [Ayatana] Multiple virtual desktops in Unity

[Jorge Ortega]

I think from now own I'm repeating myself but I'll try again.

If I call them virtual desktops is because they are not real, in the sense
that Gimp open and running is real. There is not system overhead there. I
really don't see the extra layer of complexity, quite the opposite. This is
simple: one running app-one dektop/workspace/background. In this respect
changing between workspaces is not any different than changing between
running apps: an icon-click or shortcut away.

To be honest, this wouldn't be very different from saying: every time the
user opens a new app the others get minimize instantly.

The process should be transparent in the sense that you don't have to
connect to the internet, find out the address of some server in USA, send a
request for some information, deal with proxies, etc. every time you launch
the browser to look up something in Google: this is all done for you when
you trigger an action.

To make it short: if people understand that I'm suggesting and extra layer
of complexity, then a)didn't understand my point b)didn't explain myself
well c) My suggestion is plain wrong.



On 14 April 2011 20:45, Christopher Kahn  wrote:

> What I mean by that is, when you click the launcher you expect one thing to
> happen: the program to open. Opening it anywhere else but right in front of
> me-*-on the viewport I'm currently looking at*--is adding unnecessary
> complexity and confusion to what should be a dead simple procedure. Whisking
> the user to another workspace and having him say "hey! why'd all my other
> windows disappear? why do I have to go to another workspace just to get my
> browser back?" is confusing.
>
> So if I open 8 different programs I'd end up with 8 virtual workspaces? And
> then I'd have to go manually consolidating them if I only wanted them on one
> or two? Or take extra steps to get it to open on the current viewport?
> What's the limit to the number of virtual workspaces that can be open? Does
> this affect performance?
>
> I agree that workspaces need more accessible default behaviour but I don't
> think this is it.
>
> --Chris
>
>
> On Thu, Apr 14, 2011 at 3:23 PM, Jorge Ortega 
> wrote:
>
>> Christopher,
>>
>> But the new app would open right in front of you...
>>
>> The way I see it is: there wouldn't be any defined number of desktops, and
>> definitely you shouldn't be able to see several empty desktops. The point is
>> that a new desktop is created every time you start a new app.
>>
>> A compromise would be to make it action-dependent: clicking on the icon
>> would open in new desktop and draging and droping the icon would open it in
>> a new dektop (or viceverse). But this is probably far too much of a
>> compromise...
>>
>>
>> On 14 April 2011 20:15, Christopher Kahn wrote:
>>
>>> Hello Ayatana mailing list.
>>>
>>> This would cause a lot of confusion for users. When you're on a viewport
>>> and you click an icon you expect the program to open right in front of you.
>>> Whisking the user around to different viewports when he opens programs will
>>> cause confusion and frustration... it is not intuitive behaviour. And if I
>>> have 4 workspaces and open 5 programs, where does the 5th program open and
>>> why?
>>>
>>> My suggestion is to add an item to launchers' right-click menus: "Open in
>>> workspace X", when you click it you'd be be moved to that workspace with the
>>> new window open.
>>>
>>> --Chris
>>>
>>>
>>>
>>> On Thu, Apr 14, 2011 at 2:07 PM, Jorge Ortega >> > wrote:
>>>
>>>> Hi jamur,
>>>>
>>>>
>>>>  I don't want the shell to make arbitrary decisions for me
>>>>>
>>>>
>>>> the decision to open apps on the same workspace is as arbitrary  as the
>>>> decision to give them their own workspace.
>>>>
>>>> Now, I don't have hard data to support this but there it goes anyway:
>>>> most of the times, when people work with one app. they work with (focus on)
>>>> just one app at a time. This is even if they have several open: torrent
>>>> client downloading in the background, the music player playing in the
>>>> background, the browser open and ready for next time you check facebook or
>>>> what not. I know that the occasions when you actually need to interact with
>>>> more than one app at a time are not rare: but I would argue that they are
>>>> the minority.
>>>>
>>>

Re: [Ayatana] Multiple virtual desktops in Unity

[Jorge Ortega]

>
> What if I want to use two applications at once?
> I prefer an environment in which I decide where windows are placed and when
> they're minimized, and given the ubiquity of such a convention I'd be very
> surprised if user testing could demonstrate that others don't.
> I may be referring to a web page as I take notes in a word processor, or
> copying parts of scripts a friend sent me in an email into GIMP.  All sorts
> of combinations of simultaneous use are easily imaginable.
>

For example: drag word processor icon onto Firefox icon. For example: give
the option to "lock" a workspace with corresponding icon -say- at the bottom
of the unity bar.

I prefer an environment in which I decide where windows are placed and when
> they're minimized, and given the ubiquity of such a convention I'd be very
> surprised if user testing could demonstrate that others don't.


But you don't work in an environment in which you decide that all windows
are open in the same workspace: this is just the default behaviour and you
had to adapt to it.
I could argue that the ubiquity of such convention has created the ubiquity
of "how the hell do I find my way through this mess of 10 open windows in
the same workspace". This is the problem I was trying to address.

How many time have you seen it (or suffered it)? some one trying to find
that app varied between many other windows...
On 14 April 2011 22:10, Richard Gaskin  wrote:

> On 4/14/11 1:48 PM, Jorge Ortega wrote:
>
>> I think from now own I'm repeating myself but I'll try again.
>>
>> If I call them virtual desktops is because they are not real, in the sense
>> that Gimp open and running is real. There is not system overhead there. I
>> really don't see the extra layer of complexity, quite the opposite. This
>> is
>> simple: one running app-one dektop/workspace/background. In this respect
>> changing between workspaces is not any different than changing between
>> running apps: an icon-click or shortcut away.
>>
>> To be honest, this wouldn't be very different from saying: every time the
>> user opens a new app the others get minimize instantly.
>>
>
> I still can't post to the Ayatana List (neither the list admin nor anyone
> else I've tried writing to can figure out why), so please forgive me for
> writing to you directly but I must ask:
>
> What if I want to use two applications at once?
>
> I may be referring to a web page as I take notes in a word processor, or
> copying parts of scripts a friend sent me in an email into GIMP.  All sorts
> of combinations of simultaneous use are easily imaginable.
>
> I prefer an environment in which I decide where windows are placed and when
> they're minimized, and given the ubiquity of such a convention I'd be very
> surprised if user testing could demonstrate that others don't.
>
> That assumes, of course, that user testing of such important and pervasive
> design decisions is being done with A/B prototypes.
>
> If not, then perhaps that's the meta-problem that needs to be solved before
> any other design problem can be addressed by more than a hunch. Heuristics
> only go so far, and with something as bold as Unity they can be difficult to
> apply without prejudice.
>
> I spoke with Ted Gould at SCaLE about the possibility of drafting user
> testing guidelines to allow distributed testing by the community with
> minimal cost to Canonical.
>
> If this sort of thing is of interest I'd be happy to contribute in any way
> I can, even if it's just to help set up the logistics to deliver raw data to
> the usability professionals at Canonical in a way that avoids potentially
> poor interpretation by contributors.
>
> --
>  Richard Gaskin
>  ___
>  ambassa...@fourthworld.com   http://www.FourthWorld.com
>
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Switching lenses shouldn't need 2 clicks

[Jorge Ortega]

>
> Currently when the dash is already open, switching to another lense from
> the launcher takes two clicks, instead of the more natural one. Even worse,
> the first click closes the dash, which completely contradicts a users
> expectation, because he was expecting the dash to stay visible
>
.
You're right, it is very irritating. Is this a bug, something that has been
overlooked or is it like this by design? I would like to believe it is
either of the first two options.
On 15 April 2011 15:39, Arian van Gend  wrote:

> Hi every one!
>
> Currently when the dash is already open, switching to another lense from
> the launcher takes two clicks, instead of the more natural one.
> Even worse, the first click closes the dash, which completely contradicts a
> users expectation, because he was expecting the dash to stay visible. It
> should just change content/context, without going away first, and without
> requiring 2 clicks.
>
> Kind regards,
> Arian
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Fwd: [Bug 733349] Re: Natty: Unity launcher buttons should allow to minimize apps, not just launch/restore

[Jorge Ortega]

I really don't understand this kind of reasoning.

IMHO this is a case of creating a very real problem by means of fixing a
very theoretical one. I find *consistency* a well over-used concept: one can
try to force consistent behaviour between any two given elements in a web of
many others (and in the process forget about all the others). Let me explain
myself.

The problem which has been fixed here was a non-existing one: most people
don't know the difference between an app and a window, it is an extremely
abstract concept and people just don't do their computing like that; people
are mainly totally alien to this. Most people don't know what a file manager
is. People do care though about *predictibility*: you provoke and action and
expect/hope for some particular reaction.

One such is being able to minimize from the same place you used to launch an
app. This is -talking about consistency- just about what always  happens in
the rest of the Univers, and this goes for many version of Windows, all
Linux desktops I've laid my hands on, any other dock I've used, etc. The use
is so widely spread that it should be considered a de-facto standard.
Compared to this the theoretical problem of having multiple or single
windows of an app., etc seems irrelevant.

There is of course the option of having icons for windows no apps (Gimp
being a very obvious exception to this), there is the option of First click:
maximizes all, Second click minimazes all. There are other options but none
should include what there is now.

Just my opinion.


On 19 April 2011 15:15, Marco Biscaro  wrote:

>  Ian, I think you're right.
>
> applications != windows
>
> An application can have zero or more windows. I think the question here is
> consistency:
>
> If your application has just one window, when you click on the launcher
> icon, this window will minimize. But if you have 3 opened windows to that
> application? What should happen when you click the launcher icon if:
>
> 1. All windows are visible?
> 2. Two windows are visible and one is already minimized?
> 3. One window is visible and two are already minimized?
> 4. All windows are minimized?
>
> Considering that there is just one icon per application, I think the best
> way to minimize a window is to click the minimize button of that window. If
> I'm not mistaken, this why clicking on launcher icons doesn't minimize
> windows.
>
> Besides this, If you want to organize your windows, you can use the
> workspaces to arrange them. And use +D to show desktop if needed.
>
>
> On Ter, 2011-04-19 at 07:30 -0600, Ian Santopietro wrote:
>
> It was my understanding that the launcher  icons only represent apps, and
> since an app can't really be minimized (only windows of that app), they
> don't do it.  It works with Gnome 2 because the list was a list of windows.
> It would be clicking on a Gnome 2 shortcut and having the windows of that
> app minimize.
>
> I might be wrong here though.
>
>  On Apr 19, 2011 7:19 AM, "Bazon"  wrote:
> >  Original Message 
> > Subject: [Bug 733349] Re: Natty: Unity launcher buttons should allow to
> > minimize apps, not just launch/restore
> > Date: Tue, 19 Apr 2011 07:45:08 -
> > From: Michael <733...@bugs.launchpad.net>
> > Reply-To: Bug 733349 <733...@bugs.launchpad.net>
> >
> >
> >
> > > I'm sure that if you ask on the Ayatana mailing list they will be happy
> >
> >> to explain, and perhaps to discuss, the reasoning.
> >
> >
> > OK, so here we go:
> > Why isn't it possible any more to minimize windows when clicking a
> further time on the button which represents the application?
> > That was possible with the Gnome Panel Window Switcher, it is possible in
> the XFCE taskbar, it is possible in Cairo-Dock, it is possible with the MS
> Windows taskbar and probably many more.
> >
> > So why break users expectations?
> > You leave the experienced user in frustration while the inexperienced
> user will not be mocked by minimizing on an extra click he probably never
> makes.
> > (Showing and hiding a window quick by clicking two times on the
> icon/switcher is a very common practice.)
> >
> > I believe it's generally not a good idea that clicking on an interactive
> element of your screen leads to NOTHING.
> >
> > Some users will wonder whether their system is responding slow,
> experienced users who are used to the minimize behaviour will miss it.
> > (and you know, many of them are already frustrated enough losing Gnome 2
> features.)
> >
> >
> > So please reconsider allowing minimizing windows by clicking on the
> launcher.
> >
> >
> >
> >>
> > --
> >>
> >>
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> > https://bugs.launchpad.net/bugs/733349
> >
> > Title:
> > Natty: Unity launcher buttons should allow to minimize apps, not just
> > launch/restore
> >
> > To unsubscribe from this bug, go to:
> > https://bugs.launchpad.net/ayatana-design/+bug/733349/+subscribe
> >
> >
> > _

Re: [Ayatana] Fwd: [Bug 733349] Re: Natty: Unity launcher buttons should allow to minimize apps, not just launch/restore

[Jorge Ortega]

Still more: all the indicators on the top right corner. You click one and it
shows, click again and it hides. And this is how it should be.

On 19 April 2011 21:12, Bazon  wrote:

>  Additionally, the Dash works exactly that way:
> First click: show
> Next click: hide
>
> This works for all Dashes, the Ubuntu-Logo-Dash, the Applications-Dash and
> the Files-and-Folders-Dash - why not for the other symbols on the launcher?
>
> So much for consistency.
>
>
>
>
> On 19.04.2011 20:41, Jorge Ortega wrote:
>
> I really don't understand this kind of reasoning.
>
> IMHO this is a case of creating a very real problem by means of fixing a
> very theoretical one. I find *consistency* a well over-used concept: one
> can try to force consistent behaviour between any two given elements in a
> web of many others (and in the process forget about all the others). Let me
> explain myself.
>
> The problem which has been fixed here was a non-existing one: most people
> don't know the difference between an app and a window, it is an extremely
> abstract concept and people just don't do their computing like that; people
> are mainly totally alien to this. Most people don't know what a file manager
> is. People do care though about *predictibility*: you provoke and action
> and expect/hope for some particular reaction.
>
> One such is being able to minimize from the same place you used to launch
> an app. This is -talking about consistency- just about what always  happens
> in the rest of the Univers, and this goes for many version of Windows, all
> Linux desktops I've laid my hands on, any other dock I've used, etc. The use
> is so widely spread that it should be considered a de-facto standard.
> Compared to this the theoretical problem of having multiple or single
> windows of an app., etc seems irrelevant.
>
> There is of course the option of having icons for windows no apps (Gimp
> being a very obvious exception to this), there is the option of First click:
> maximizes all, Second click minimazes all. There are other options but none
> should include what there is now.
>
> Just my opinion.
>
>
> On 19 April 2011 15:15, Marco Biscaro  wrote:
>
>>  Ian, I think you're right.
>>
>> applications != windows
>>
>> An application can have zero or more windows. I think the question here is
>> consistency:
>>
>> If your application has just one window, when you click on the launcher
>> icon, this window will minimize. But if you have 3 opened windows to that
>> application? What should happen when you click the launcher icon if:
>>
>> 1. All windows are visible?
>> 2. Two windows are visible and one is already minimized?
>> 3. One window is visible and two are already minimized?
>> 4. All windows are minimized?
>>
>> Considering that there is just one icon per application, I think the best
>> way to minimize a window is to click the minimize button of that window. If
>> I'm not mistaken, this why clicking on launcher icons doesn't minimize
>> windows.
>>
>> Besides this, If you want to organize your windows, you can use the
>> workspaces to arrange them. And use +D to show desktop if needed.
>>
>>
>> On Ter, 2011-04-19 at 07:30 -0600, Ian Santopietro wrote:
>>
>> It was my understanding that the launcher  icons only represent apps, and
>> since an app can't really be minimized (only windows of that app), they
>> don't do it.  It works with Gnome 2 because the list was a list of windows.
>> It would be clicking on a Gnome 2 shortcut and having the windows of that
>> app minimize.
>>
>> I might be wrong here though.
>>
>>  On Apr 19, 2011 7:19 AM, "Bazon"  wrote:
>> >  Original Message 
>> > Subject: [Bug 733349] Re: Natty: Unity launcher buttons should allow to
>> > minimize apps, not just launch/restore
>> > Date: Tue, 19 Apr 2011 07:45:08 -
>> > From: Michael <733...@bugs.launchpad.net>
>> > Reply-To: Bug 733349 <733...@bugs.launchpad.net>
>> >
>> >
>> >
>> > > I'm sure that if you ask on the Ayatana mailing list they will be
>> happy
>> >
>> >> to explain, and perhaps to discuss, the reasoning.
>> >
>> >
>> > OK, so here we go:
>> > Why isn't it possible any more to minimize windows when clicking a
>> further time on the button which represents the application?
>> > That was possible with the Gnome Panel Window Switcher, it is possible
>> in the XFCE taskbar, it is possible in Cairo-Dock, it is pos

Re: [Ayatana] Hide application windows via launcher

[Jorge Ortega]

>
> Those who have been arguing for minimizing on yet another click on the
> launcher will likely not be satisfied with an option
>

I would definitely be satisfied by this [?] just like I'm satisfied by the
possibility of changing the launcher size or his hiding behaviour
On 21 June 2011 10:13, Thorsten Wilms  wrote:

> On 06/21/2011 10:40 AM, Adrian Maier wrote:
>
>> If the contributed code is ok from a technical point of view but is
>> rejected for design reasons  hm, well, in this case it would
>> indicate an unhealthy attitude towards the user community .   There is
>> no harm in having an additional option that is activated only on
>> demand , and I expect that the devels realize it.
>>
>
> Maybe such a patch would be accepted in this specific case, but I would
> guess not. The last statement is wrong. A patch needs to be reviewed and
> tested to make sure it does what it should and makes nothing stop doing what
> it should. So here's harm already. Then it adds complexity. You have to care
> about it on refactoring, it's like extra weight you have to carry around.
>
> The option needs to be exposed to the user somehow. It needs to be
> documented. If hardly anyone knows about it, it would be useless.
>
> Those who have been arguing for minimizing on yet another click on the
> launcher will likely not be satisfied with an option. The real desire is
> default behavior, be it because the person doesn't want to have to change an
> option, be it for a true believe the behavior would be better for the
> majority of users.
>
>
>
> --
> Thorsten Wilms
>
> thorwil's design for free software:
> http://thorwil.wordpress.com/
>
> __**_
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : 
> https://help.launchpad.net/**ListHelp
>
<<328.png>>___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Oneiric Dark Toolbars/Menubar Issues

[Jorge Ortega]

I think it is an interesting solution. I suggested before something a bit
more radical: that every application when open, would create its own virtual
workspace. To do this only for maximised  applications is also, I think, a
good idea.

On 21 July 2011 19:36, Jonathan Meek  wrote:

> I recently say the post on OMG!Ubuntu! about the possibility of dark
> toolbars being included for Oneiric and this sparked an interesting debate
> among someone I know who I asked to draft his thoughts on the issue for post
> to the Ayatana list for discussion. Here it is:
>
>
> PROBLEM:
> The management of maximised windows in Unity is principally flawed and
> could potentially cause confusion.
> This problem arises due to the location of the toolbars of maximised
> windows, and the global menu in the Unity panel.
> Consider the screenshot at
> http://cdn.omgubuntu.co.uk/wp-content/uploads/2011/07/2011-07-19-150134_1366x768_scrot-1.png.
> In the screenshot, you can see that because of the dark theming of the
> toolbar of the image preview window, it appears to be a part of the panel
> and the global menu.
> The screenshot demonstrates a situation in which this is undesirable. It
> may appear to the user that the toolbar for the image preview application is
> a part of the global menu for the settings application. A similar problem
> may arise in the event that a user has, for instance, two documents open in
> a word processor, and one maximised behind another unmaximised window. In
> this case, it may appear that the toolbar of the window behind operates on
> the window in front. This could cause confusion and annoyance.
> SOLUTIONS:
> There are a number of potential solutions, including theming inactive
> windows differently and displaying the title bar of full screen windows.
> In my opinion, the best solution I have observed is the solution in use on
> Mac OS X Lion. Lion creates a dynamic workspace for each maximised  window,
> in effect treating maximised (or full-screen) applications as additional
> workspaces. This means that it is impossible to end up with a situation
> where an unmaximised window is in front of a maximised window.
>
> From Jonathan Rothwell 
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp