Bug 39094 - noatun size after store settings
Summary: noatun size after store settings
Status: RESOLVED FIXED
Alias: None
Product: noatun
Classification: Miscellaneous
Component: general (show other bugs)
Version: 1.2
Platform: Mandrake RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Charles Samuels
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-03-08 05:18 UTC by Lubos Lunak
Modified: 2004-06-12 23:00 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Henry Stanaland 2002-03-08 05:10:33 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           noatun
Version:           1.2.0 (using KDE 2.2.1 )
Severity:          normal
Installed from:    Mandrake Linux Vitamin
Compiler:          gcc version 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)
OS:                Linux (i686) release 2.4.8-26mdk
OS/Compiler notes: 


I did a "Store Settings" on the notun *playlist* (so it would remember the size and position) but now my Kaimen interface only shows about 2/3 of the window(equal to the playlist's stored settings).  This is with the "car" skin. Since the skins don't have resize tabs I seems stuck with this small window version of noatun(unless I turn off "Store Settings" for the playlist).

Description:
If the playlist is closed.  I click on the "tray" icon repeatedly and it will alternate between "Show all of Noatun" "Invisible" and "Use Playlist's Size & Position."  So every other time it shows all of noatun.  If the playlist is open it always shows all of noatun.

So it seems to me that the Window Manager's "Store Settings" is recognizing noatun's kaimen as the playlist if the playlist is closed.  If the playlist is open it assigns those settings to the playlist and then gives the kaimen skin it's normal settings.

I'm not sure if the window manager uses the title to identify windows but if it does perhaps each "piece" of noatun should have a different title(or whatever the identifier is).

(Submitted via bugs.kde.org)
(Called from KBugReport dialog)
Comment 1 Lubos Lunak 2002-10-25 14:50:51 UTC
 Noatun developers, please read 
http://lists.kde.org/?l=kde-core-devel&m=103521890818862&w=2 and make sure different 
toplevel window can be distinguished from each other. 
 
Comment 2 Stephan Kulow 2004-05-25 08:51:12 UTC
Replaced henryst@mit.edu with l.lunak@kde.org due to bounces by reporter
Comment 3 Stefan Gehn 2004-06-05 10:52:13 UTC
Does this still happen with current KDE? And if yes, is giving every qwidget based window a different name the right solution (I'm not sure if I understood the mail referred to in this bugreport).
Comment 4 Lubos Lunak 2004-06-07 13:21:30 UTC
Yes, giving every toplevel widget a different name is needed to make kwin recognize them from each other. The values given by "xprop | grep -e ROLE -e CLASS" are used by KWin to identify a window.
Note that I'm not actually the reporter of this bug, and I don't really care about this specific bug.
Comment 5 Stefan Gehn 2004-06-12 23:00:40 UTC
Gave all ui-plugins and splitplaylist toplevel-widgets a name now, hope this fixes the bug.