Re: [Ayatana] Windicators

[Shane Fagan]

On Fri, 2010-12-10 at 12:04 +0530, Owais Lone wrote:
> Just wanted to check. Are Windicators targeted for Natty? How much
> work has been done? What if I wanted to play with it a little?
No there was no talk about anything unless canonical have it going on
it.

--fagan


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

[Ayatana] Windicators

[Owais Lone]

Just wanted to check. Are Windicators targeted for Natty? How much work has
been done? What if I wanted to play with it a little?
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

[Ayatana] Fwd: Usability - Useless effect when clicking an icon (Unity)

[Spike Burch]

-- Forwarded message --
From: Spike Burch 
Date: Thu, Dec 9, 2010 at 11:51 PM
Subject: Re: [Ayatana] Usability - Useless effect when clicking an icon (Unity)
To: Peterson Silva 


minimize upon click is probably a bad idea. too easy for users to
accidentally lose their window

On Thu, Dec 9, 2010 at 7:03 PM, Peterson Silva  wrote:
> "That's what it does in Windows 7, for some applications but not others:
> for example, it works for Windows Explorer, but not for Windows Backup."
>
> What an inconsistency oO
>
> "It's not what it does in Mac OS X, at all:"
>
> Sorry, I've never used a Mac, but as all the docks out there which try to
> copy it somehow have this behaviour, I assumed that it was there where it
> came from.
>
> "Unity will soon have something very much like this."
>
> Awesome! =D But then with only one window will it minimise after clicking?
>
> Peterson
> http://petercast.net
>
>
> On 9 December 2010 14:12, Matthew Paul Thomas  wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Peterson Silva wrote on 08/12/10 15:01:
>> >...
>> > So the thing is, if you have only one instance of an active window and
>> > you click its icon in the Launcher, the effect is useless. Users coming
>> > from Windows 7 (or any other version of it for that matter) or Mac OS
>> > will expect the application to minimize;
>>
>> That's what it does in Windows 7, for some applications but not others:
>> for example, it works for Windows Explorer, but not for Windows Backup.
>>
>> It's not what it does in Mac OS X, at all: clicking the launcher of a
>> running application always brings all its windows to the front, and if
>> they already are, it does nothing.
>>
>> >...
>> > So here's what we could do, then: to have different effects based on
>> > the windows opened, but with a visual hint so the user knows what to
>> > expect (and can easily understand the point of the behaviour). I'm not
>> > currently using Unity, but as far as I remember, there's no visual hint
>> > as to whether or not there are multiple instances of a window opened.
>> > We could put a small emblem over the program icon in the launcher (like
>> > in one of its corners) with a number indicating the number of windows.
>> >...
>>
>> Unity will soon have something very much like this.
>>
>> - --
>> Matthew Paul Thomas
>> http://mpt.net.nz/
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.10 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk0A/+kACgkQ6PUxNfU6ecqDGgCgiiivwgBZp6o+Jh8i7cn6DxZL
>> MqEAn1CSYglwHEYT4gzuhTKYcEUBrASN
>> =z9At
>> -END PGP SIGNATURE-
>>
>> ___
>> 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
>
>

___
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] Usability - Useless effect when clicking an icon (Unity)

[Peterson Silva]

"That's what it does in Windows 7, for some applications but not others:
for example, it works for Windows Explorer, but not for Windows Backup."

What an inconsistency oO

"It's not what it does in Mac OS X, at all:"

Sorry, I've never used a Mac, but as all the docks out there which try to
copy it somehow have this behaviour, I assumed that it was there where it
came from.

"Unity will soon have something very much like this."

Awesome! =D But then with only one window will it minimise after clicking?

*Peterson*
*http://petercast.net*



On 9 December 2010 14:12, Matthew Paul Thomas  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Peterson Silva wrote on 08/12/10 15:01:
> >...
> > So the thing is, if you have only one instance of an active window and
> > you click its icon in the Launcher, the effect is useless. Users coming
> > from Windows 7 (or any other version of it for that matter) or Mac OS
> > will expect the application to minimize;
>
> That's what it does in Windows 7, for some applications but not others:
> for example, it works for Windows Explorer, but not for Windows Backup.
>
> It's not what it does in Mac OS X, at all: clicking the launcher of a
> running application always brings all its windows to the front, and if
> they already are, it does nothing.
>
> >...
> > So here's what we could do, then: to have different effects based on
> > the windows opened, but with a visual hint so the user knows what to
> > expect (and can easily understand the point of the behaviour). I'm not
> > currently using Unity, but as far as I remember, there's no visual hint
> > as to whether or not there are multiple instances of a window opened.
> > We could put a small emblem over the program icon in the launcher (like
> > in one of its corners) with a number indicating the number of windows.
> >...
>
> Unity will soon have something very much like this.
>
> - --
> Matthew Paul Thomas
> http://mpt.net.nz/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0A/+kACgkQ6PUxNfU6ecqDGgCgiiivwgBZp6o+Jh8i7cn6DxZL
> MqEAn1CSYglwHEYT4gzuhTKYcEUBrASN
> =z9At
> -END PGP SIGNATURE-
>
> ___
> 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] Seeking feedback on professional video import UX design

[Jason DeRose]

Frederik,

On Wed, Dec 8, 2010 at 3:53 AM, frederik.nn...@gmail.com
 wrote:
> Hi Jason,
>
> well, this is what i've been waiting for all along:
> professional post production software for Ubuntu!

Music to my ears. :)

For anyone who missed earlier emails, discussion is about this pro
file import UX design:

https://wiki.ubuntu.com/AyatanaDmediaLovefest

> On Tue, Dec 7, 2010 at 19:33, Jason DeRose  wrote:
>>
>> I didn't make it clear, but in my scenario there will very likely be a
>> person editing at the workstation.
>
> Being a devoted AVID user (audio), I'm well aware of the various zombie
> states one can assume, operating a digital workstation for the better part
> of the day..

Nice. We haven't received as much feedback yet from AVID user (more
FCP), nor from pro audio users, so we really appreciate your thoughts
on any of this.

In your pro audio work, are you typically importing from cards, or
recording directly to your workstation?  We need to support both, but
right now we're trying to make the most common HDSLR hardware setup
work very smoothly... which pretty much means recording on a Zoom H4n
or similar, importing from SD cards.

Out of curiosity, have you used any of AVID's Media Asset Management
software?  If so, what do you think of it, any features stand out as
especially worthwhile?

>> When someone is there editing, I think NotifyOSD strikes a wonderful
>> balance between reliably capturing the user's attention yet not
>> distracting them.  It's all because the notifications are
>> non-interactive.  They're strangely soothing, IHMO.  (Mad props to
>> those who designed them so well.)
>
> I can only begin to imagine the benefits of my ProTools being integrated
> into its hosting DE for once.. that would change everything! Notify OSD and
> AppIndicators provide such an easy way of integrating one's professional
> software into the Desktop Environment seamlessly.

That's my thinking... why shouldn't creative professionals have some
first-class DE features just for them?

IHMO, there is a *huge* opportunity right now to bring creative
professionals to Ubuntu, especially in the big-data, compute-intensive
areas of pro video and audio.  Like what already has happened with
super computing, I think Linux will become the preferred platform for
creative professionals.  Hollywood special effects and 3d animation
have been done almost exclusively on Linux for some time, and from
talking to a friend that works in the industry, production shops are
foaming at the mouth to move to a *fully* Linux-based solution... they
just need a suitable video editor, suitable Media Asset Management.

I personally think Apple sees the writing on the wall already... I
think there is clear evidence that Apple isn't making further serious
investment in its pro content creation software.  It's all about iOS
and content consumption.  And that has opened the door for Ubuntu to
provide a new home for a lot of creative professionals.

>>
>> All the same, it would be a small effort to try both approaches, get
>> feedback from the users.  If you ever have a mockup of what you had in
>> mind for said window, I'd love to see it.
>
> Menus are condensed interfaces, they offer the most frequently used options
> of an otherwise more comprehensive interface for rapid interaction. In a
> similar way, as in Ayatana Indicator Menus, they can also offer the most
> recent and current event/process/progress/item in a given activity, e.g. a
> conversation, a message or a completed transfer.
>
> I think it is always easy to see a menu as a proxy to the more comprehensive
> main window of the same respective "project".
> Only that the menu will give back focus to the thing you were working on
> without the disturbing requirements of window management.
>
>> I know this is a very specialized use case and it might seem like I'm
>> splitting hairs, but it's also a use case where small improvements can
>> make a big difference to the user.
>
> I can confirm that.
> When only a single keyboard command changes, it can have a severe effect on
> how usable my workstation is!
> Imagine.. you sit behind that workstation for a dozen of hours on many a
> day, doing the same thing over and over again, how terrible would it be, to
> run into a logical regression in the UI design.
>
>> Thanks again for your input!  I'll add your suggestion to the wiki page.
>
> keep me posted as the software becomes available for testing, i for one
> can't wait to get professional post production work done in desktop Linux.

So the features described in this UX design should almost all land in
dmedia 0.2, which will be released on December 30th:

https://launchpad.net/dmedia/+milestone/0.2

Although the content of the RenderMenu will still be quiet rough and
cards wont automatically be formatted yet.

I'll let you know when it's available!  Thanks again for the feedback!

___
Mailing list: https://launchpad.net/~ayatana
Post to  

Re: [Ayatana] Allowing windows to move past launchers

[Jason Smith]

Lovely concept. I think it would make positioning windows near the
launcher less frustrating.

On Thu, 2010-12-09 at 18:14 +, Mark Shuttleworth wrote:
> On 09/12/10 17:43, Sam Spilsbury wrote:
> > My idea was this:
> >
> > 1) On the intellihide case:
> > [...]
> > -> When resizing a window, if the resize border touches the launcher,
> > it goes away, easy
> 
> I'd like to see a proximity "push" in this case. When the window is
> brought "close" to the launcher, we start to "push" the launcher away.
> Say, when the edge of the window is 10px from the launcher, we start to
> move the launcher 1px for each 2px it approaches. When the window gets
> to the point where it would have touched the launcher, the launcher goes
> away.
> 
> I think this would feel a little more organic and real than the current
> "insta-trigger". The px values might best be shared with the notify-osd
> proximity-effect fade boundary too.
> 
> > 2) On the "fixed launcher" case:
> >
> > -> We set the strut property, so no implicit incorrect placement
> > -> On maximization the window does not cover the launcher
> > -> Windows cannot be resized underneath the launcher
> > -> Windows cannot be moved underneath the launcher.
> >
> > The reason for the fourth one is because we have the window buttons on
> > the left - we do not want to have to obscure them  in the case that we
> > move a window.
> 
> Let's do some testing with a less rigid interpretation - allow the
> window to be resized or moved so its left edge is under the launcher,
> but make sure it encounters some resistance when it touches, before
> pushing through under the launcher.
> 
> Mark
> 

-- 
Jason Smith | Desktop Experience Team
GNOME Developer
Canonical USA Inc.
T. +1.248.756.6266 | jason.sm...@canonical.com
Ubuntu - Linux for human beings | www.ubuntu.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] Allowing windows to move past launchers

[Sam Spilsbury]

On Fri, Dec 10, 2010 at 2:14 AM, Mark Shuttleworth  wrote:
> On 09/12/10 17:43, Sam Spilsbury wrote:
>> My idea was this:
>>
>> 1) On the intellihide case:
>> [...]
>> -> When resizing a window, if the resize border touches the launcher,
>> it goes away, easy
>
> I'd like to see a proximity "push" in this case. When the window is
> brought "close" to the launcher, we start to "push" the launcher away.
> Say, when the edge of the window is 10px from the launcher, we start to
> move the launcher 1px for each 2px it approaches. When the window gets
> to the point where it would have touched the launcher, the launcher goes
> away.
>

This is easy to implement in compiz.

> I think this would feel a little more organic and real than the current
> "insta-trigger". The px values might best be shared with the notify-osd
> proximity-effect fade boundary too.
>
>> 2) On the "fixed launcher" case:
>>
>> -> We set the strut property, so no implicit incorrect placement
>> -> On maximization the window does not cover the launcher
>> -> Windows cannot be resized underneath the launcher
>> -> Windows cannot be moved underneath the launcher.
>>
>> The reason for the fourth one is because we have the window buttons on
>> the left - we do not want to have to obscure them  in the case that we
>> move a window.
>
> Let's do some testing with a less rigid interpretation - allow the
> window to be resized or moved so its left edge is under the launcher,
> but make sure it encounters some resistance when it touches, before
> pushing through under the launcher.
>

Right. I'll look into implementing edge resistance for resize as well
in the snap plugin

> Mark
>
>



-- 
Sam Spilsbury

___
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] Allowing windows to move past launchers

[Mark Shuttleworth]

On 09/12/10 17:43, Sam Spilsbury wrote:
> My idea was this:
>
> 1) On the intellihide case:
> [...]
> -> When resizing a window, if the resize border touches the launcher,
> it goes away, easy

I'd like to see a proximity "push" in this case. When the window is
brought "close" to the launcher, we start to "push" the launcher away.
Say, when the edge of the window is 10px from the launcher, we start to
move the launcher 1px for each 2px it approaches. When the window gets
to the point where it would have touched the launcher, the launcher goes
away.

I think this would feel a little more organic and real than the current
"insta-trigger". The px values might best be shared with the notify-osd
proximity-effect fade boundary too.

> 2) On the "fixed launcher" case:
>
> -> We set the strut property, so no implicit incorrect placement
> -> On maximization the window does not cover the launcher
> -> Windows cannot be resized underneath the launcher
> -> Windows cannot be moved underneath the launcher.
>
> The reason for the fourth one is because we have the window buttons on
> the left - we do not want to have to obscure them  in the case that we
> move a window.

Let's do some testing with a less rigid interpretation - allow the
window to be resized or moved so its left edge is under the launcher,
but make sure it encounters some resistance when it touches, before
pushing through under the launcher.

Mark



signature.asc
Description: OpenPGP digital signature
___
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] Allowing windows to move past launchers

[Sam Spilsbury]

On Fri, Dec 10, 2010 at 1:33 AM, Mark Shuttleworth  wrote:
> On 09/12/10 10:59, Didier Roche wrote:
>> Le jeudi 09 décembre 2010 à 18:55 +0800, Sam Spilsbury a écrit :
>>> Hi,
>>>
>>> I was doing some work on the snap windows plugin for compiz and I was
>>> wondering if it is the correct behaviour design wise to allow windows
>>> to move underneath the launcher and the panel. Currently we have it so
>>> that windows snap to the launcher but the user can move the window
>>> past the launcher if they "move hard enough" but I was wondering if we
>>> should even allow windows to move past these panels in the first
>>> place.
>>>
>>> Let me know what you all think.
>> We should just perhaps agree on the snap value? I mean, we want to avoid
>> false positive on intellihide but still enabling people to have
>> intellihide :)
>
> In the intellihide, moving the window against the launcher should kick
> the launcher out immediately, as it currently does. I think Sam's
> referring more to the case where the launcher is locked in place, not
> intellihide.

I was thinking something like this (warning: coder's POV, it gets a
bit technical).

Bit of lingo here since I tend to use it regularly:
-> strut: A property called _NET_WM_STRUT_PARTIAL that docks,
launchers, etc place on windows to "reserve" an area of the screen.
Windows don't get placed there and they cannot maximize over it.
-> placement: where the window is positioned on open.


My idea was this:

1) On the intellihide case:

-> We don't set the strut property, which means that windows can
implicitly get placed underneath the launcher (this can be overridden
in the unityshell plugin)
-> On maximisation the launcher is going to go away anyway, since the
window will be covering it
-> When moving a window near the launcher, if it goes close then the
launcher will go away (intellihide)
-> When resizing a window, if the resize border touches the launcher,
it goes away, easy

2) On the "fixed launcher" case:

-> We set the strut property, so no implicit incorrect placement
-> On maximization the window does not cover the launcher
-> Windows cannot be resized underneath the launcher
-> Windows cannot be moved underneath the launcher.

The reason for the fourth one is because we have the window buttons on
the left - we do not want to have to obscure them  in the case that we
move a window.

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



-- 
Sam Spilsbury

___
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] Usability - Useless effect when clicking an icon (Unity)

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peterson Silva wrote on 08/12/10 15:01:
>...
> So the thing is, if you have only one instance of an active window and
> you click its icon in the Launcher, the effect is useless. Users coming
> from Windows 7 (or any other version of it for that matter) or Mac OS
> will expect the application to minimize;

That's what it does in Windows 7, for some applications but not others:
for example, it works for Windows Explorer, but not for Windows Backup.

It's not what it does in Mac OS X, at all: clicking the launcher of a
running application always brings all its windows to the front, and if
they already are, it does nothing.

>...
> So here's what we could do, then: to have different effects based on
> the windows opened, but with a visual hint so the user knows what to
> expect (and can easily understand the point of the behaviour). I'm not
> currently using Unity, but as far as I remember, there's no visual hint
> as to whether or not there are multiple instances of a window opened.
> We could put a small emblem over the program icon in the launcher (like
> in one of its corners) with a number indicating the number of windows.
>...

Unity will soon have something very much like this.

- -- 
Matthew Paul Thomas
http://mpt.net.nz/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0A/+kACgkQ6PUxNfU6ecqDGgCgiiivwgBZp6o+Jh8i7cn6DxZL
MqEAn1CSYglwHEYT4gzuhTKYcEUBrASN
=z9At
-END PGP SIGNATURE-

___
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] progress window chrome

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

frederik.nn...@gmail.com wrote on 08/12/10 21:24:
>
> On Wed, Dec 8, 2010 at 20:57, Roth Robert ...
>> On Wed, Dec 8, 2010 at 2:22 PM, Matthew Paul Thomas
>...
>>> Yes. It is a bug in the HIG that it recommends repeating title bar
>>> text as primary text in progress windows.
>>
>> The sentence that recommended repeating the title bar text as
>> primary text in progress windows was removed since 2.30... you can
>> still see it in 2.28, but it does not appear since 2.30 anymore. I
>> guess that the screenshot was not updated.
> 
> whow, such historical detail ;)

Oh, it's even worse than that. The person who removed it was ... me.


I just forgot yesterday that I'd done it.

> Now let's hope that the 3.0 will rid us of the necessity of talking
> about how many titles a progress window needs..

Or, if hoping isn't your style, you could report bugs and make patches
for the programs (like Synaptic) that currently repeat titles.

> In reality, even the current stable HIG recommends against using
> windows for the indication of progress,

That's a misleading summary. The guidelines recommend against using
progress windows in specific cases -- where the task prevents you from
doing anything in an existing window (in which case you should show
progress in that existing window), or where the task will take only a
few seconds. There are still many cases where progress windows are
appropriate.

> which itself leads to the
> conclusion that displaying progress within an extra window is an
> improper way of presenting that kind of data.

It doesn't really.

- -- 
Matthew Paul Thomas
http://mpt.net.nz/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0A2GoACgkQ6PUxNfU6ecpOaACeNvKjsqv3OOJbvWoMhEdKiPBS
C7IAoKBxJsSX4yGZoNDWBmwwkQrKRryv
=1wLe
-END PGP SIGNATURE-

___
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] Allowing windows to move past launchers

[Mark Shuttleworth]

On 09/12/10 10:59, Didier Roche wrote:
> Le jeudi 09 décembre 2010 à 18:55 +0800, Sam Spilsbury a écrit :
>> Hi,
>>
>> I was doing some work on the snap windows plugin for compiz and I was
>> wondering if it is the correct behaviour design wise to allow windows
>> to move underneath the launcher and the panel. Currently we have it so
>> that windows snap to the launcher but the user can move the window
>> past the launcher if they "move hard enough" but I was wondering if we
>> should even allow windows to move past these panels in the first
>> place.
>>
>> Let me know what you all think.
> We should just perhaps agree on the snap value? I mean, we want to avoid
> false positive on intellihide but still enabling people to have
> intellihide :)

In the intellihide, moving the window against the launcher should kick
the launcher out immediately, as it currently does. I think Sam's
referring more to the case where the launcher is locked in place, not
intellihide.

Mark



signature.asc
Description: OpenPGP digital signature
___
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] Allowing windows to move past launchers

[Didier Roche]

Le jeudi 09 décembre 2010 à 18:55 +0800, Sam Spilsbury a écrit :
> Hi,
> 
> I was doing some work on the snap windows plugin for compiz and I was
> wondering if it is the correct behaviour design wise to allow windows
> to move underneath the launcher and the panel. Currently we have it so
> that windows snap to the launcher but the user can move the window
> past the launcher if they "move hard enough" but I was wondering if we
> should even allow windows to move past these panels in the first
> place.
> 
> Let me know what you all think.

We should just perhaps agree on the snap value? I mean, we want to avoid
false positive on intellihide but still enabling people to have
intellihide :)

Cheers
Didier


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

[Ayatana] Allowing windows to move past launchers

[Sam Spilsbury]

Hi,

I was doing some work on the snap windows plugin for compiz and I was
wondering if it is the correct behaviour design wise to allow windows
to move underneath the launcher and the panel. Currently we have it so
that windows snap to the launcher but the user can move the window
past the launcher if they "move hard enough" but I was wondering if we
should even allow windows to move past these panels in the first
place.

Let me know what you all think.

Cheers
-- 
Sam Spilsbury

___
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] Usability - Useless effect when clicking an icon (Unity)

[frederik.nn...@gmail.com]

On Wed, Dec 8, 2010 at 16:01, Peterson Silva  wrote:

> Recently I've posted this bug at Launchpad:
>
> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/686822
>
> So the thing is, if you have only one instance of an active window and you
> click its icon in the Launcher, the effect is useless. Users coming from
> Windows 7 (or any other version of it for that matter) or Mac OS will expect
> the application to minimize; instead, it will just float. It is useless and
> counter-intuitive already.
>
> On the other hand, when there are multiple windows of the same app, the
> effect is very cool and useful;


+1

and well, i miss my SUPER+W !!!
If Scale aka Expose becomes so central, i would strongly recommend to
associate the scale addon features:
 * secondary click to zoom in
 * middle click to close

especially the unread messages from the Messaging Menu shouldn't get
acknowledged, before i haven't seen them at full scale.
Seeing the window, scaled down on a Netbook 10" display in Exposé, surely
doesn't validate removing a message indicator from the Messaging Menu as
"seen".
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp