Autohide Not At All -- stays up

I don't normally use auto-hide so never noticed this, but can now confirm that this is reproducible running bzr17.

Yeah, I think thats the problem. Niel doesn't seem to use it either... thats partially why there are so many bugs there.

This sounds useful. Should we even fix this?

Maybe if a user configurable timer was implemented (see https://bugs.launchpad.net/awn/+bug/130233) that would be the best of both worlds?

Allow the user to specify how many seconds AWN should stay up before auto-hiding.

Or my suggested feature...

Hide on gesture. Meaning, it hides if you do a mouse gesture (like rapid movement back and forth), and comes back up using the same. To be honest, I think it makes more sense to have it always there until you tell it to get out of the way, rather than never there unless you make a bug stay up :)

https://blueprints.launchpad.net/awn/+spec/non-auto-hide

That's my suggestion...

I think to leave it there as a "feature" might prove confusing in terms of explaining to new users the autohide feature. If we want autohide to be easily turned on and off without having to peruse to a configuration screen, then a button (or somesuch) should be added to the dock to help users directly and quickly turn the functionality on/off. Maybe a toggle option in the right-click menu? Maybe a control-click...alt-click...whatever...

I think the behavior might be more consistent if awn tracked the position of the mouse whenever the mouse is above it (yes, I know...not exactly elegant...). That way, the auto-hide can be triggered 1000ms after the last mouse event was received *and* the mouse is not on top of the bar (or any of its artifacts such as window titles, or window thumbnails for those of us who use compiz/beryl).

I'm not that familiar with the new code, so I'll have to do some perusing to get up to speed to see if this is even feasible or desirable...

Thoughts?

Sorry...not 1000ms...I meant "auto_hide_delay" ms...cuz it's configurable now :)

I've recently started using awn on Gutsy and latest (as of Aug 24th) code from bzr and have a few problems with auto-hide that may not be bugs in code, but implementation features done in a way that seems not-quite-right to me.

I've enabled auto-hide, because I really can't afford to loose that much of my screen to something that I use only 90 seconds a day. (The fact that I use it only 90 seconds is cool, because the alternatives take up much more of my time)

Basically, I want it there when I want it, and I want it gone when I don't want it. I'm not trying to impress anyone, just trying to get my work done.

It makes perfect sense for it to auto-hide when my pointer approaches the bottom of the screen and then go away when my mouse moves a certain distance away from the doc.

Right now, if I move my mouse pointer within about 5px of the bottom of the screen, it appears. Perfect.

However, when I move my mouse pointer away, it stays there. If I move my mouse slowly over a couple of the icons then move it away vertically, it hides again. (problem 1)

Also, sometimes I get two bars at the same time or within a few seconds of each other. Sometimes they're identical, sometimes the icons are in different places. You can only interact with the awn on top (problem 2) See attached screenshot where I've added two arrows to draw your attention to where you can see the icons overlapped from the two separate bars. They usually don't pop-up at the same time, so you can see one bar sliding up over the existing bar.

Another issue, which compared to the two above is quite minor, is that moving your mouse pointer anywhere along the bottom of the screen causes awn to pop-up. This interferes with the compiz-fusion scale plugin that I have set to activate for the bottom right corner of the screen. Also, if I interact with plugins in the status bar of my browser, such as firebug or greasemonkey. (problem 3)

I like awn a lot, and like I said, it has the potential to speed up things.

Here are some suggestions for the auto-hide feature:

First, read http://www.asktog.com/columns/044top10docksucks.html

Reading that article made me curious about a feature... instead of it hiding completely, I wonder if there's a way for it to shrink so that only 5px or so of the bar is available along the bottom of the screen. Applications that need attention would bounce up off the bottom of the screen to get your attention. See http://people.ubuntu.com/~mnuzum/tmp/awn-example.jpg

The benefit of this is that the area you need to mouse-over to see awn would be well defined, so you'd only need to have the mouseover region be the actual bar, also, it would be ever present but take very little of the screen. And finally, this is the biggie, it would make you very aware of programs that need your attention without needing sound. For example, if you stepped away for a moment and someone IMd you or if you alt+tabbed right when a program popped up a dialog and you didn't see it.

It might annoy people if the icons are constantly bouncing full height, so maybe they only slowly bounce up to about 15px above the bottom of the screen so that they just peek up over the edge. That would tak...

Hello,

I have the same "bug" as Matthew Nuzum : whenever I try to use Compiz Scale (going to the right-bottom corner) or Desktop Wall (going to the left-bottom corner), the dock shows up and will not hide unless I move my mouse over it.

The same thing happens when I use Thunderbird or Nautilus (in maximized display) and that there are file/folders in my window that are close to the bottom of the screen, if I try to select these, the dock shows up and will never hide.

Should we fill a new bug for this ? (because it's slightly different from bug 130235 above)

I also have this problem- it is really annoying.

(my dock is at the bottom)
If I accidentally mouse my mouse to the bottom of the screen, the dock shows up and stays stuck. So i have to move the mouse over the dock to unstuck it (and make sure the mouse goes directly upward)

why is the importance undecided?

This is the most annoying thing ever. I might have to go back to kiba-dock

I think my problems are also related, but slightly different to the above accounts.

My bug occurs when I move the mouse down to raise the dock. If I move my mouse away from the dock before it has finished its "show" animation, it does not go back down again, even if I click on another window etc. It only goes back down once it gets and then loses mouse focus. Not sure if this is considered a bug or not, but it is darn annoying when a user needs auto-hide to preserve screen space.

heres a vid of my bug

http://video.google.com/videoplay?docid=6983199758207245011&hl=en

It also happens to me if I simply move my mouse down to the bottom of the screen where AWN hasn't expanded to. This will bring up AWN and it will stay up until you move the mouse to an icon in AWN. I don't think AWN should even show up if you move the mouse to a part of the screen to which it has not yet extended.

This is very annoying and happens all the time. As a matter of fact, it is happening right now...

I have this exact same problem, and it bugs the crap out of me.

marking this as also affecting awn in Ubuntu.

Out of curiosity, would disabling focus for awn via CompizConfig help or hurt?

Azeem Khan wrote:
> If you mean trailfocus, I do not have that enabled at all. There is no
> plugin I have that is called "focus". If you mean a different plugin,
> could you please tell me the name that shows up on the window "Advanced
> Desktop Effects Settings"?
>
> On Thu, May 8, 2008 at 7:44 PM, Thinboy00 <<email address hidden>
> <mailto:<email address hidden>>> wrote:
>
> Out of curiosity, would disabling focus for awn via CompizConfig help or
> hurt?
>
> --
> Autohide Not At All -- stays up
> https://bugs.launchpad.net/bugs/130235
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
>
>
>
> --
> (o_
> // \ This is Penguin.
> V_/_ Don't mess with Penguin.
>
>
> Gmail. Two letters ahead of Email.
> Geniuses, which I is one of am, so Gmail use do I.
>
>
No, I mean in either the general preferences window or the Window rules
window, you can disable focus for particular windows to prevent focus
stealing.

--
Sincerely,
Thinboy00

Hmm. The dock has variable width... could there be problems with that
(in terms of usability)?
On Sun, May 11, 2008 at 6:49 PM, Azeem Khan <email address hidden> wrote:
> That didn't work. It allows the active window to focus after I mouse over an
> icon on the dock, but when I mouse to the bottom of the screen (where the
> dock is NOT, e.g. the bottom right corner) then the dock will pop up for
> some reason. Then, it will not even go away until I mouse over a dock icon.
> This is the bug I've been trying to fix.
>
> I think a solution would be to make it so the dock (navigator) does not pop
> into focus unless you mouse to the bottom of the screen where the dock
> actually is. That is, if the dock does not cover the entire bottom of the
> screen, do not let it appear when the user mouses to an area on the bottom
> edge where the dock is not.
>
>
>
> On Sun, May 11, 2008 at 10:42 AM, Thinboy00 <email address hidden> wrote:
> > Azeem Khan wrote:
> >
> > >
> > > If you mean trailfocus, I do not have that enabled at all. There is no
> plugin I have that is called "focus". If you mean a different plugin, could
> you please tell me the name that shows up on the window "Advanced Desktop
> Effects Settings"?
> > >
> > >
> > > On Thu, May 8, 2008 at 7:44 PM, Thinboy00 <<email address hidden>
> <mailto:<email address hidden>>> wrote:
> > >
> > > Out of curiosity, would disabling focus for awn via CompizConfig help
> or
> > > hurt?
> > >
> > > --
> > > Autohide Not At All -- stays up
> > > https://bugs.launchpad.net/bugs/130235
> > > You received this bug notification because you are a direct
> subscriber
> > > of a duplicate bug.
> > >
> > >
> > >
> > >
> > > --
> > > (o_
> > > // \ This is Penguin.
> > > V_/_ Don't mess with Penguin.
> > >
> > >
> > > Gmail. Two letters ahead of Email.
> > > Geniuses, which I is one of am, so Gmail use do I.
> > >
> > >
> > >
> > No, I mean in either the general preferences window or the Window rules
> > window, you can disable focus for particular windows to prevent focus
> > stealing.
> >
> > --
> > Sincerely,
> > Thinboy00
> >
>
>
>
> --
> (o_
> // \ This is Penguin.
> V_/_ Don't mess with Penguin.
>
>
> Gmail. Two letters ahead of Email.
> Geniuses, which I is one of am, so Gmail use do I.
>
>
>

--
Sincerely,
Thinboy00

I'm not sure what you mean by usability issues with regards to variable width. Could you explain?

If the User doesn't know the width of the dock but has to mouse over the part of the dock that actually is present, and the dock is of variable width, one of the following must be true:
1. The user has to guess at or keep track of where the dock is
2. The user has to throw the mouse towards the center of the screen /every time/ he wants the dock
3. The user has to wave the mouse around (in hopes of finding where the dock is) some/most of the time to get the dock up.

This is not exactly a terrible idea, now that i think of it. It would be better if the dock could be pinned to a corner pixel, preferably the left one because firefox etc. often puts a lot of interactive stuff in the lower right corner (ABP, Noscript, Greasemonkey, ... list goes on). Since corner pixels have (effectively) infinite area, this means less guesswork for the user and better conformance to Fitts' law. A gesture should be optional and configurable, since, for some users, the bar is used every ten seconds and when it's not in use it's hidden, while at the other end of the spectrum, some users rarely/never use it except to launch applications (you have <Alt>+<Tab> for everything else) and rarely run more than one app (so they primarily use awn from the Desktop, when it's /never hidden/ and therefore have no need to see awn intruding on their apps, but still want to be able to access it, just in case. The former obviously would not want any gesture (slows down access) whilst the latter would desire a complex gesture to reduce false positives. Give both what they want.

Can confirm this bug and I think it's really a bug, not just an "interesting mouse gesture function". For example, you can move the pointer down to make the dock come up and then (quickly) move the pointer up just while the dock comes up. If you try a little you will be able to get something similar: the dock stays up and does not hide.

Like Bernhard Koenig i confirm this bug, and when this occur it's annoying.

Definitely a bug, a very annoying one at that too.

Passing it as a feature is just unfortunate. If it is really a desired feature, name it, have a check-box in the preferences that can enable the said feature.

When I set the autohide feature, my intent is to "temporarily" raise the dock, use it and forget about it. If I am expected to manually hide the dock, auto-hide is broken.

Uhm, I have to agree with the previous comments too; this bug annoys my wife to the point she is willing to move from gnome de (for me an additional click out of awn can be free, but I wouldn't call it a feature).

You know.... i choose AWN than cairo-dock.... because i don't like cairo's preferences... confusing..... come on AWN developers you can make it better

This has been stated in numerous other places but since it appears that it hasn't been said in this bug...

1) The current awn architecture means that the current autohide is hackish. There are _numerious_ issues. It was added after the fact.
2) No one has stepped forward to try to fix autohide with the current architecture. My guess is those with knowledge of 1) assume that it really isn't fixable with the current architecture. Chances are individual issues can probably be resolved but the "fixes" would probably lead to new issues.

The 0.4 rewrite has significant architecture changes that should lead to a more usable autohide. Don't expect any significant changes/improvements in autohide before then.

This is easily fixed.

mjmt,

Thanks for the patch. What WMs has it been tested on?

That above isn't right, dunno what I diff'd there. Sorry.
Here's what I actually have. Since lat last year has Worked For Me with Compiz, I gave a few settings I don't normally use like click-to-focus a spin as well, that all seems fine.

Perhaps we should apply this fix to trunk, so at least users of the testing-ppa have it?

Michal,

If you're comfortable with the fix then I say go ahead. It probably wouldn't do any harm (though it has a short life expectancy).

I've committed the latest patch to trunk (r566). I'm leaving it as assigned to Michal, so he can make sure that this bug doesn't occur with the rewritten autohide subsystem.

This bug was fixed in the package avant-window-navigator - 0.3.9~bzr1890-0ubuntu1

---------------
avant-window-navigator (0.3.9~bzr1890-0ubuntu1) lucid; urgency=low

  * New upstream snapshot.
   - Fix autohide behavior (LP: #130235)
   - Allow only 1 instance of Awn (LP: #258675)
  * debian/patches:
   - 10_correct_exception.patch: Dropped, problem fixed in the new version.
   - 00-wm-behavior.patch and 01-tasks-have-arrow.patch: Merged upstream.
   - 03-python-import.patch: Refresh.
  * Bump libawn SONAME.
  * debian/control:
   - Add minimum requirement for libwnck-dev libgtk2.0-dev and libglib2.0-dev.
   - Drop build-depends on libgnome2-dev, libgnome-desktop-dev, libglade2-dev.
   - Bump build-depends for debhelper to (>= 7.0.50~) for overrides.
   - Build-depends on libgtop2-dev.
   - Replace build-depends on python-gnome-dev by python-gtk2-dev (>= 2.12).
   - Build-depends on gconf2, libdesktop-agnostic-dev, libdesktop-agnostic-bin,
     python-desktop-agnostic, vala-desktop-agnostic for desktop-agnostic
     support.
   - Demote the composite manager to Recommends, Awn works without it.
   - Depends on libdesktop-agnostic-* and dbus.
   - Bump libawn SONAME.
   - Rename awn-manager to awn-settings.
   - libawn-dev : drop libgnome*-dev and add libdesktop-agnostic-dev depends.
   - Replace depends on awn-manager by Recommends on awn-settings for
     avant-window-navigator.
   - Add depends on avant-window-navigator, python-desktop-agnostic, bzr and
     python-dbus for awn-settings.
   - Replace vala depends by vala-desktop-agnostic for vala-awn.
   - Bump standard version to 3.8.3, no change needed.
   - Add Conflicts/Replaces to replace separator applets which is in core now.
  * debian/rules:
   - Rewrite with overrides.
   - Remove awn.wrapper.
   - Bump libawn SONAME.
   - Remove LDFLAGS and useless flag from configure.
  * debian/awn.wrapper & debian/avant-window-navigator.links:
   - Dropped, previous configuration is incompatible.
  * debian/avant-window-navigator{,-data}.install:
   - Update installed files in core.
   - Install core applets
  * debian/awn-manager.install
   - Rename to awn-settings.install
   - Update installed files.
  * debian/awn-applet*.1 && debian/avant-window-navigator.manpages
   - Update manpages.
  * debian/awn-manager.*
   - Rename awn-manager to awn-settings.
   - Remove unused manpages.
  * debian/python-awn:
   - Update to the new location.
  * debian/README.Debian:
   - Mention that real transparency is not needed.
   - Add mutter in the list of composite managers.
  * debian/copyright:
   - Update copyright and licenses.
 -- Julien Lavergne <email address hidden> Mon, 11 Jan 2010 22:27:06 +0100