Bug 39094

Summary:	noatun size after store settings
Product:	[Unmaintained] noatun	Reporter:	Lubos Lunak <l.lunak>
Component:	general	Assignee:	Charles Samuels <charles>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	NOR
Version:	1.2
Target Milestone:	---
Platform:	Mandrake RPMs
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

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.