Awn

Awn dialog follows the bar while it autohides

Bug #133488 reported by Darkmaster
28
Affects Status Importance Assigned to Milestone
Awn
Fix Released
Medium
Michal Hruby
Awn 0.4.0
Awn Extras
Invalid
Undecided
Timon_and_Pumba

Bug Description

Simply, when I click on the stack applet (Very useful and wonderful one), the black transparent space with all the files inside appears and that's OK.... but when AWN autohides, the black balloon follows the bar down to the screen so that if I'm selecting an icon in that moment I end up selecting another icon instead (Cause the balloon changes position)! This is crazy.

I suggest that while the balloon of a stack applet is opened, the bar should keep visible and not hide itself. Alternatively (but it would be only a workaround and not a nice solution), the balloon has to stay still in the original position.

Revision history for this message
Timon_and_Pumba (timonterbraak) wrote :

I vote for the first option: "do not autohide if a dialog is shown".
Then we better find a general solution to prevent Awn's autohiding feature temporarily.

Revision history for this message
Darkmaster (darkmaster) wrote :

I'm very glad about it because I vote for it too :D
Hope it's implemented soon.

Andrew Starr-Bochicchio (andrewsomething)
Changed in awn:
status: New → Confirmed
assignee: nobody → timonterbraak
Revision history for this message
Andrew Starr-Bochicchio (andrewsomething) wrote :

Moved to AWN-extras

Changed in awn-extras:
assignee: nobody → timonterbraak
status: New → Confirmed
Changed in awn:
assignee: timonterbraak → nobody
status: Confirmed → Invalid
Revision history for this message
Timon_and_Pumba (timonterbraak) wrote :

Actually it belong to the Awn core.
The bug report refers to the stack applet, but the actual issue is caused by awn-applet-dialog in libawn.
That object is responsible for the position of the dialog, which is calculated from the bar position.
If awn autohides, the bar gets lower -> the dialog repositions.

Either the position calculation has to be altered, or better: autohide should be disabled when a dialog is active.

Changed in awn:
status: Invalid → Confirmed
Changed in awn-extras:
status: Confirmed → Invalid
Revision history for this message
Neil J. Patel (njpatel) wrote :

dialog should automatically prevent autohide through the new dbus interface scheduled for the 0.2.6 release.

Changed in awn:
assignee: nobody → njpatel
importance: Undecided → Medium
milestone: none → 0.2.6
Revision history for this message
reader4 (cbrace1) wrote :

I am running 0.3.1 and still have the same behavior... when I click on the stack icon using either curved or trasher views, autohide causes the icon/bubble to fall when I move the mouse. If I don't move the mouse while hovering on a popup from the stack, everything stays in place. As soon as I move the mouse, things fall back down.

Revision history for this message
Henry (semperfatuus) wrote :

I'm also running 0.3.1, and the behavior persists. As reader4 notes, holding the mouse over a popup keeps the dialog from moving - but not the whole dock. So when I move the mouse again, the popup snaps down to stay with the dock, which auto-hides as normal.

This bug makes stacks basically unusable for me, because I have to wait for the dock to autohide before getting a stable popup. The ideal fix would be to prevent the whole dock from auto-hiding as long as a dialog is open - even if the mouse isn't over the popup.

Revision history for this message
Mark Lee (malept) wrote :

I should note that the 0.2.6 that Neil refers to is not the same as the 0.2.6 that was released - we changed our versioning scheme and the autohide refactor is now scheduled for 0.4. Unfortunately, Neil has not had any time to work on it.

Revision history for this message
Bernhard (b.a.koenig) wrote :

Can confirm this as well. Wonder if it's really an issue in awn itself rather than the extras because it works fine for calendar and weather applet (these windows remain stable).

Revision history for this message
moonbeam (rcryderman) wrote :

This is definitely an issue in awn. Specifically in libawn and, more specifically, exposing limitations of AwnAppletDialog. The fact that calendar and weather applet dialogs remain stable in this circumstance almost certainly means they do not behave correctly in other circumstances.

Revision history for this message
Sandeep (sandys-gmail) wrote :

upvote for this issue - this is extremely irritating from a usability point-of-view

Michal Hruby (mhr3)
Changed in awn:
assignee: Neil J. Patel (njpatel) → Michal Hruby (mhr3)
status: Confirmed → Fix Committed
Mark Lee (malept)
Changed in awn:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.