QUOTE(FofR @ Mar 30 2007, 13:28)

You say that puis are only visual stuff, thing is - our layouts are very dependent on the grouping/sort modes (thats why group by was previously included in SCPL no?); We'd use the sort mode name or index to change group headers (e.g. from album name to artist name when grouping changed) or even the whole SCP (when sorting by a track title rather than an album); if a user doesn't have these functioning sort modes then the layout doesn't change correctly and things stop working. If we don't bundle the sort modes with the pui then they'll go ahead and try and sort anyway - this produces different errors.
yes, the layouts are dependent on the grouping/sort mode, which is why there is the layout selector. It should automatically match the appropriate layout (or probably "Singles" if the appropriate one doesn't exist), to the current group/sort mode. So, if you're grouping by album, the "Album" layout will be used. Likewise, if you're grouping by artist, the "Artist" layout will be used. The layout selector probably needs better defaults, so I'm open to suggestions. Also, the layout names will need to be standardized (so "Album" is designed around grouping albums instead of something else).
I think what you're trying to do is probably use one layout to handle both artist and album groupings, and while this could be made to work, I think it would be better to split them into two.
QUOTE
Two cases:
Say I include a button on my layout that sorts by rating then folder, groups by rating.
It would probably be better to have a button that applies preset 1 (maybe something like "Sort by $presetname(1)", although this function doesn't exist yet...). This way the user would get always get something useful and appropriate for them.
QUOTE
A.) A user with this preset but with a different grouping/sort order will see a messed up playlist as either it groups wrong, the wrong group header text is displayed or the items appear in an order not consistent with the layout's design (for example including images in the item display requires strict ordering for the image to display correctly)
no, they would never see a messed up playlist because the layout selector should always choose a correct layout based on the current sort/group mode. If you have a preset called "foo" that sorts/groups by album, then when you hit "foo" you will see the "Album" layout. If someone else has a preset called "foo" that sorts randomly, then they will see the "Singles" layout.
As for including images in the item display, using item index instead of track number should handle most of the problems. If you want to do something like group/sort by artist, then sort by album and display album covers in the item display, the layout selector should make sure that all the correct criteria are applied before calling that layout.
The reason for not including the sort / group strings in the pui is that each person has a different way of sorting/grouping. For example, how do you define what is a single and what is part of an album? do you prefer to sort by artist/date/album or by date/artist/album? do you even use the %rating% tag? Including this stuff in the pui makes it work to the pui creators preference, but for others there will always be the need to edit each pui for their preferences. With the current way, you only need to set up your sort/group settings and layout selector code once and it will work across all puis.
QUOTE(Kiteroa @ Mar 30 2007, 23:03)

Feature request:
I'd like to display some tiny pictures etc. on the tracks they relate to. No problem setting a pvar in SCP and picking it up in panels_ui to put a button/Track Display in the right place on top of the SCP, everything refreshes nicely, no flickering etc. BUT when the SCP screen is scrolled panels-ui doesn't know and the buttons/TD are in wrong place!
Any chance you could give us a variable in SCP or panel_UI, or is (as I fear) scrolling handled elsewhere and not visible to your component?
hmmm, I'm not clear on what you're trying to do... maybe a screenshot?
QUOTE(FofR @ Mar 31 2007, 03:59)

I distinctly remember being able to do this in SCPL, I would drag a track or album from Windows Explorer into foobar and the items would be placed after the now selected songs. After enabling the ColumnsUI "drop at end of playlist" feature these songs started being dropped at the end. Now trying to turn off this feature doesn't work. Was it somehow disabled in a PUI update?
no, it would working differently under columns ui vs. panels ui.
QUOTE
Is the Single Columns Playlist selector code included with the PUI?
no, it is stored in the .cfg. I am looking for better defaults though.
QUOTE(tomthomson @ Mar 31 2007, 08:13)

Another problem

:
$playlistname() / %playlist_name% doesnt work as a sourting/grouping criteria code.
I want to do something like this in the "group by" box (shortened)
CODE
$if($strchr($playlistname(),'°'),!noheader!,%album%%discnumber%%disctitle%)
The problem is this condition never returns the TRUE statement
the grouping/sorting criteria code don't take any other functions other than the stock foobar ones (to remain as fast as possible). you can, however, use the layout selector to select a different layout base on playlist name (eg singles), although you can't (currently) remove the groupsl.
QUOTE(elenhil @ Mar 31 2007, 08:41)

Any chance of implementing subgrouping, Terrestrial?
not in the near future

QUOTE(Yotsuya @ Mar 31 2007, 21:37)

I would like the ability to manually switch layouts on the same playlist with a button. (i.e.: album vs. singles groupings on the same playlist). While this could be accomplished by switching sort/group patterns I think that switching layouts would offer much more flexibilty. The mechanisms to accomplish this all appear to be there there if we could somehow force SCPL to refresh. I have read several other posts where users have requested the ability to force SCPL to refresh for various reasions. Would it be possible to add a button command to force the refresh? We could then stack this on any other button to accomplish various things. Maybe a way to hook into when pvars are set to trigger a refresh. The new layout code appears to be very powerful but if it is not re-evaluated when the variables change then it loses much of its potential functionality.
with albums vs singles, you would group by album for the former and not for the latter, and let the layout selector pick the appropriate layout. but you want to switch layouts with the exact same grouping/sorting pattern? In that case the best way is to add a dummy group/sort criteria and use that in the layout selector to force one or the other. eg add a criteria called "Force Single Layout" and in the layout selector check if $isgrouped(Force Single Layout) and set the singles layout. The reason for this step instead of directly being able to select a layout is that this will make your selection "stick", otherwise it would be reset to something else each time the layout selector is run.