unexpected results using tagFormat

[Oliviander]

Hi Simon,
I was just experimenting some more with MinS_071.

I got confused as I expected something from the
TagFormat option which it isn't designed for:

As it is not helpful to have WORKS in a list not having the
Composer attached to them I tried

tagFormat = WORK.displayFormat={$COMPOSER^^: ^ / $WORK}

to make "WORK" look like "COMPOSER: WORK"

But when I selected the tag WORK to make a selection
nothing had changed in the WORK list.

At first I thought I did something wrong,
but after some thinking I suspected that this feature obiously doesn't
rebuild the index just changes the view.
(I tell you that because even after rereading the manual
I'm sure one might expect it working that way.)

So after aliasing the WORK to GROUP,
Applying the same tagFormat to the Group
gave me the view I expected.
(but only in the first line of the ITEMS view,
and not when selecting the index GROUP.)

BUT with the major drawback that the itemview was now
sorted in the same order as it was without the Tagformat applied.

When you do something like this to the album View
you can change Album.sortTags accordingly

but with Groups as they show up in the ITEMS list
you don't have that possibility.

So in my opinion one should have at least the possibility
for an -> Item.sortTags option to make this
feature complete.

Alternatively a feature that would build a
complete new index out of the existing ones
(without replacing them like aliasing)
would do many useful tricks.

[classical11]

I apply the same displayFormat transformation to the Groups to prefix them with the Composer.

I would also like to see the Items sorted correctly when displayFormat transformation are applied, as Oliviander as suggested.

[simoncn]

(19-04-2013 00:23)Oliviander Wrote:  Hi Simon,
I was just experimenting some more with MinS_071.

I got confused as I expected something from the
TagFormat option which it isn't designed for:

As it is not helpful to have WORKS in a list not having the
Composer attached to them I tried

tagFormat = WORK.displayFormat={$COMPOSER^^: ^ / $WORK}

to make "WORK" look like "COMPOSER: WORK"

But when I selected the tag WORK to make a selection
nothing had changed in the WORK list.

At first I thought I did something wrong,
but after some thinking I suspected that this feature obiously doesn't
rebuild the index just changes the view.
(I tell you that because even after rereading the manual
I'm sure one might expect it working that way.)

So after aliasing the WORK to GROUP,
Applying the same tagFormat to the Group
gave me the view I expected.
(but only in the first line of the ITEMS view,
and not when selecting the index GROUP.)

Thanks for this feedback. As you say, this is working as intended. Customized index entries will be supported in a future release of MinimServer. In 0.71, you can customize the Artist index, but nothing else.

Quote:BUT with the major drawback that the itemview was now
sorted in the same order as it was without the Tagformat applied.

When you do something like this to the album View
you can change Album.sortTags accordingly

but with Groups as they show up in the ITEMS list
you don't have that possibility.

So in my opinion one should have at least the possibility
for an -> Item.sortTags option to make this
feature complete.

I'm planning to add something like this as well.

Quote:Alternatively a feature that would build a
complete new index out of the existing ones
(without replacing them like aliasing)
would do many useful tricks.

The index customization support will allow you to do this.

[Oliviander]

(19-04-2013 07:49)simoncn Wrote:  

Quote:Alternatively a feature that would build a
complete new index out of the existing ones
(without replacing them like aliasing)
would do many useful tricks.

The index customization support will allow you to do this.

Sounds Great
now I'm absolutely sure that I am supporting
coolest horse in the race
THX for the great work
and of course I am anxious for this new feature.