Bugzilla – Bug 15098
title bar not getting style from window but from global
Last modified: 2010-04-08 17:25:31 UTC
Created attachment 6295 [details] screenshot of window with incorrect title style (and hidden label element incorrectly visible) I'm seeing occasional situations where a new window is not obeying all of the styles that it should from the window, particularly in the titlebar area. I've put skin debug on in these cases and noticed that the style of the title area are reporting things like title, title.text rather than nowplaying_art_only.title and nowplaying_art_only.title.text On touch I've worked around this with skin params that suppress the title bar for a selected window style, but e.g. on baby where the title bar is needed and of a different style than the global, the change in style results in a broken UI Sorry if this explanation is convoluted...my guess is that this will end in a WONTFIX but I'm doing my due diligence to report it.
If you have a current fw running on controller, this is pretty easily seen by spinning the wheel on the NP screen. You likely will see a label that should be hidden and the height of the titlebar asset wrongly shrink to the global s.title setting
== Auto-comment from SVN commit #8086 to the jive repo by richard == == https://svn.slimdevices.com/jive?view=revision&revision=8086 == Bug #15098 Added error logging when a widget is incorrectly added or removed from a window.
When a widget x is added to a window w then x.parent=w is set to maintain the widget hierarchy. This property is used to determine the style path. So when the style is just 'title' this suggests that x.parent==nil. The bug seen here might be working as below (I've not fully traced the NP code, but it'll be something like this). The first time now playing is displayed, everything is correct: Window w1 = Window() Group g = Group() w1.addWidget(g) Then when the next NP window is selected this happens: Window w2 = Window() w2.addWidget(g) w1.removeWidget(g) The w2.addWidget(g) will set g.parent to w2, but the w1.removeWidget(g) will set it to nil. Now the style will be reported incorrectly. The original software design did not use a strict widget hierarchy, so no code is in place to enforce this. The above checkin adds an error log when a widget is added to a window and it already has a parent, or when a widget is removed from a window and it's parent is incorrect. I don't want to enforce it in the framework, as other code maybe broken but working. In the NP applet this patch stops the error: Index: squeezeplay/share/applets/NowPlaying/NowPlayingApplet.lua =================================================================== --- squeezeplay/share/applets/NowPlaying/NowPlayingApplet.lua (revision 8085) +++ squeezeplay/share/applets/NowPlaying/NowPlayingApplet.lua (working copy) @@ -484,7 +484,7 @@ if playlistSize == 1 and self.rbutton == 'playlist' then if not self.suppressTitlebar then log:debug('changing rbutton to + button') - self.window:removeWidget(self.titleGroup) +-- self.window:removeWidget(self.titleGroup) self.window:addWidget(self.titleGroupOneTrackPlaylist) end self.rbutton = 'more' I am not sure why the removeWidget is required, but possible fixes would be: 1. (nasty hack) check the self.titleGroup == self.window before calling removeWidget 2. Make sure a new titleGroup is created for every NP window, so that group of widget is not reused between windows 3. Enforce the removeWidget()/addWidget() ordering
I think Richard's checkin for 15097 also fixes this
This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release. If you are still seeing this issue, please let us know!