Red Hat Bugzilla – Bug 612721
after shading/unshading main window is unmoveable
Last modified: 2010-07-19 02:50:09 EDT
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
Steps to Reproduce:
1. start audacious
2. shade/unshade the main window
3. try to drag to another position
Window becomes undraggable and is nailed to the Desktop
Window can be freely dragged around
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
> shade/unshade the main window
What does that mean?
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.
Created attachment 430485 [details]
small window after double left click
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)
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.
Created attachment 430994 [details]
Audacious config File.
My Audacious config file. Nothing special in there.
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.
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.
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.
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?
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.
$ gconftool-2 -g /apps/metacity/general/disable_workarounds
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.
See upstream's response here: