Bug 612721 - after shading/unshading main window is unmoveable
Summary: after shading/unshading main window is unmoveable
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: audacious   
(Show other bugs)
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Michael Schwendt
QA Contact: Fedora Extras Quality Assurance
URL: http://jira.atheme.org/browse/AUD-225
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-08 20:49 UTC by Stefan Jensen
Modified: 2010-07-19 06:50 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-19 06:50:09 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Normal application window (14.30 KB, image/png)
2010-07-08 21:41 UTC, Stefan Jensen
no flags Details
small window after double left click (2.94 KB, image/png)
2010-07-08 21:42 UTC, Stefan Jensen
no flags Details
Audacious config File. (3.04 KB, text/plain)
2010-07-11 13:02 UTC, Stefan Jensen
no flags Details

Description Stefan Jensen 2010-07-08 20:49:35 UTC
Description of problem:

When i once shade/unshade the main window, the window become unmoveable. It can not be dragged anywhere and is nailed in the current position.

Version-Release number of selected component (if applicable):

$rpm -qa| grep audacious

audacious-plugins-2.2-34.fc13.x86_64
audacious-2.2-16.fc13.x86_64
audacious-plugins-freeworld-2.2-3.fc13.x86_64
audacious-plugins-freeworld-aac-2.2-3.fc13.x86_64
audacious-plugins-freeworld-mp3-2.2-3.fc13.x86_64
audacious-plugins-freeworld-ffaudio-2.2-3.fc13.x86_64
audacious-libs-2.2-16.fc13.x86_64
audacious-plugins-freeworld-mms-2.2-3.fc13.x86_64

How reproducible:

Always

Steps to Reproduce:
1. start audacious
2. shade/unshade the main window
3. try to drag to another position
  
Actual results:

Window becomes undraggable and is nailed to the Desktop

Expected results:

Window can be freely dragged around

Additional info:

on shade and unshade:

==> /home/jensen/.xsession-errors <==

error 9: BadDrawable (invalid Pixmap or Window parameter) request 155 minor 1 serial 18092128
error 3: BadWindow (invalid Window parameter) request 20 minor 0 serial 18092129
error 3: BadWindow (invalid Window parameter) request 15 minor 0 serial 18092130
error 3: BadWindow (invalid Window parameter) request 15 minor 0 serial 18092689

Comment 1 Michael Schwendt 2010-07-08 21:06:02 UTC
> shade/unshade the main window

What does that mean?

Comment 2 Stefan Jensen 2010-07-08 21:41:38 UTC
Created attachment 430483 [details]
Normal application window

Sorry, my english is bad. Ok, i try to explain:

When i start audacious the "main window" apears.
I can "double left click" in the top area of this window to (what i call it) "shade" it.
The window becomes very small and minimalistic.
Then "double left click" again in that minimalistc window and the main window is resized to normal.

I hope i have explain it right. Please see the attached 2 screenshots.

best regards

Comment 3 Stefan Jensen 2010-07-08 21:42:26 UTC
Created attachment 430485 [details]
small window after double left click

Comment 4 Michael Schwendt 2010-07-08 22:02:36 UTC
Those are window manager functions:

 - Maximize Window
 - Unmaximize Window (or "Restore Window")

Available also via the "Window Menu" or the window's top-right buttons. With GNOME and Metacity a double-click on the window title bar triggers "Maximize", and the subsequent double-click triggers "Unmaximize" (Restore). One can reconfigure "Maximize" to become "Roll up" instead. That's something available with other desktop operating systems. Shade/Unshade could be MacOS or something else.

[...]

In Audacious, a double-click is "Roll up" (= reduce player window to a small bar), the next double-click restores the window again.

It works just fine here with default F13 x86_64 GNOME. The steps on how to reproduce a problem are insufficient. 


Do you use KDE or GNOME?
Could you attach your $HOME/.config/audacious/config file? (delete any passwords in the file in case you have configured special plugins)

Comment 5 Stefan Jensen 2010-07-11 13:00:00 UTC
Thank you for clearing this.

I'm running gnome, without compiz installed and metacity as WM. I have installed "control-center-extra-2.30.1-2.fc13.x86_64", which give the me "Roll up" Function. Switching to the default "Maximize" doesn't change anything.

Also i'm using the binary-only "nvidia" driver, but switching to default "nouveau" doesn't change the behaviour.

Maybe "without compiz" may be the key here? I run only "xcompmgr" to get basic transparency. I have also tried without xcompmgr, but without luck. Still the audacious become unmoveable after one "Roll up".

I have my audacious config file attached.

best regards

Comment 6 Stefan Jensen 2010-07-11 13:02:20 UTC
Created attachment 430994 [details]
Audacious config File.

My Audacious config file. Nothing special in there.

Comment 7 Stefan Jensen 2010-07-11 13:12:56 UTC
Oh, i just forgott.

The same happens to the equalizer and the playlist window, too. For instance, when the playlist window ist snaped to the main window, both are moveable together. When i now "Roll up" the playlist window, it become unmoveable. So when i move the main window, the playlist stays on its current position.

Closing and reopening the playlist fix that util next time roll up the playlist window.

Comment 8 Michael Schwendt 2010-07-14 09:34:02 UTC
Can't reproduce it yet. [Video hardware is ATI Radeon, though.]

About the playlist window: When it is rolled up (Ctrl+Shift+W) there is only a very small vertical area (near the bottom of the rolled up window) where one can click with the mouse to drag the window. That may be a bug.

About the main and equalizer window: When rolled up, one must be careful not to click the mouse on the control elements and buttons, which are still active.

Comment 9 Stefan Jensen 2010-07-14 15:19:58 UTC
I had the chance to test it on another box, today. Plain install, same result. But this box had a nvidia card, too. I can test it on a notebook with another (i think Intel) gfx card, hopefully tomorrow.

I guess the equalizer and playlist window will suffer from the same issue as the main window. I even noticed the small area in the playlist, because usually i "grab" the main window (when all windows are rolled up and snaped together) to move the hole player. For me it's not really a bug.

I hope i can test it on this notebook, tomorrow.

best regards

Comment 10 Stefan Jensen 2010-07-14 16:34:16 UTC
Ok, i think i found, that maybe metacity is the problem here.

For testing I just switch to blackbox as WM.

"killall metacity && blackbox"

With blackbox, audacious works like expected. All that Roll up, Window Placement, dragging windows and such works fine.

I 've no clue to debug this. Should i file a bug against metacity?

Comment 11 Stefan Jensen 2010-07-14 16:50:37 UTC
Doh, long story short:

$gconftool-2 -s --type bol /apps/metacity/general/disable_workarounds false

Does make it work with metacity, too. Sorry for the noise.

I leave it to you, if you what to close this now. Thank you very much.

best regards

Comment 12 Michael Schwendt 2010-07-14 17:26:24 UTC
$ gconftool-2 -g /apps/metacity/general/disable_workarounds
false

Its description says:

| Some applications disregard specifications in ways that result in
| window manager misfeatures. This option puts Metacity in a rigorously
| correct mode, which gives a more consistent user interface, provided
| one does not need to run any misbehaving applications.

'false' is the default. I've never changed it after installing F13. Setting it to 'true' seems to break many other applications according to a brief Google search, not limited to Nautilus, Pidgin, XChat, Mozilla, ... and Audacious.

Under the hood, Audacious' skinned UI also uses GTK+ 2.

The problem is not specific to Fedora and has been noticed by other people years ago. Perhaps the Audacious upstream devs aren't aware of it. Perhaps it's related to GTK. I'll check Audacious 2.4 (Rawhide) and ask them.

Comment 13 Michael Schwendt 2010-07-19 06:50:09 UTC
See upstream's response here:
http://jira.atheme.org/browse/AUD-225


Note You need to log in before you can comment on or make changes to this bug.