Bummer. So the situation is still the same - i'll stay with how it is for now, and when the SDK gets updated to allow plugins declare db-only-tags in the DB, then i may replace the TAGZ-tagguessing with LUA-code....... plus some other stuff - for example, "walking" the comment-tag for multiline-display in albummode should be much more simple and fast in LUA than it is with TAGZ. Not just that, because the results are stored in db-only-tags, they only need to be regenerated when files change - which means one would only need to guess tags one single time for a file, instead of again and again.

sorry, my bad. I was sorting by the toolbar sort option but using %last_played% as the formatting pattern, as i hide the column headers. i put that sort srting into that field and it sorted just fine that way too as expected. wow look at me learn lol

I have a suggestion too, how about changing the background color to something matching the theme background instead of the clashing black? Is that possible through the theme string?

I am using Navigator 1.03 album default mode.

Update: The same behaviour where the album formatting is lost happens when loading the album by right clicking in the Album list and choosing Send to playlist. The only way it looks right is by double clicking in the album list. Weird.

You probably have fb2k set to automatically add "incoming files" to the playlist named "Default"....... default automatically is shown in singlemode, even with the albummode default version. Thats intentional, because most people use this playlist for quick-adding mixed tracks. If you don't like that, then go to the preferences->core and look at the "always send to playlist" option - change "default" to something like "incoming albums" or whatever you like (the name doesn't really matter, as long as it does contain "-a-" or "album".

About the background - sorry, currently not possible with ui_columns. The string has no access to the "basic colors" like i.e. the background color. One can only change it manually in the ui_columns prefs with a color-picker.

- Lyx

edit: forget what i said about the playlist name - i was thinking in "singlemode-default"-mode ;-) just call the incoming playlist however you like as long as its name does not contain "-s-", "single" or "default".

edit: forget what i said about the playlist name - i was thinking in "singlemode-default"-mode ;-) just call the incoming playlist however you like as long as its name does not contain "-s-", "single" or "default".

Just to comment on the date/time format stuff mentioned earlier in this thread:I suggest to stick to the ISO 8601. There's not realy a need to start using a different format again when there is a common and recommended format available already.The ISO 8601 format is the following: "YYYY-MM-DDThh:mm:ss". This includes the hyphen in the date to have the advantages mentioned earlier by Lyx. Using the capital "T" clearly separates the date and time, so does the colon for the different time parts. The only problem might be the T though...since having that displayed might not be everyone's preference. You could deviate from the standard by leaving it out the have the parsing advantages but deviating from standards isn't something I prefer at all.

I have a suggestion too, how about changing the background color to something matching the theme background instead of the clashing black? Is that possible through the theme string?

In the 'Playlist view' tabs of the ColumnsUI preferences, click the 'Playlist view display settings' button and select 'Exposed background colour'. Voila. Took me a while to find that too, and yes the default black is rather hard on the eyes if you ask me.

well, i could change the default to dark-grey. Making it brighter would make dark-schemes look ugly. There's not much more i can do about it, because as i said, the strings have no access to the playlist background-color - they can only change the colors of track-rows - thus, there is currently no way to change the bg-color based on the selected color-scheme - unless i make every color-scheme a seperate fcs - i'm already maintaining 4 FCSs and that slows down updates quite alot (thats why i'm now "collecting" fixes and changes and then apply them all together in a new release).

In this way you can sort playlist from first song to last and also reverse mode.This is usefull when I want restore original playlist order after sorting by any columns.[a href="index.php?act=findpost&pid=274710"][{POST_SNAPBACK}][/a]

Hmm, but this would only work if the default sort-order for incoming files is also %_path_raw%, or not?

I'm not sure if this is possible with columns UI or not, but i'd like it of the album column and the title column resized together, kind of "maintaining aspect ratio" type thing. if i click the toggle area on the left of the side panel and the playlist expands, it would be cool if those two columns resized at the same rate. is this a possibility?

I'm not sure if this is possible with columns UI or not, but i'd like it of the album column and the title column resized together, kind of "maintaining aspect ratio" type thing. if i click the toggle area on the left of the side panel and the playlist expands, it would be cool if those two columns resized at the same rate. is this a possibility?[a href="index.php?act=findpost&pid=274907"][{POST_SNAPBACK}][/a]

Thats how it was at first, and i changed it before the release because it did look bad imho. Especially since the width for multiline-comments is fixed. You can change it yourself by going to the columns-tab, choosing the albummode-column, and then on the top right change the "resize" value to something else than 0.

Tracknumber-display in singlemode will be fixed in next version - i'm suprised that no one mentioned it yet.- Lyx

Just to comment on the date/time format stuff mentioned earlier in this thread:I suggest to stick to the ISO 8601. There's not realy a need to start using a different format again when there is a common and recommended format available already.[{POST_SNAPBACK}][/a]

Actually, the ISO 8601 standard allows for a variety of notations. The page you linked to is not the standard itself (you have to pay ISO to get that), it only gives examples. According to this [a href="http://hydracen.com/dx/iso8601.htm]report on the standard[/url] the letter "T" is optional:

Quote

The symbol "T" is used to separate the date and time parts of the combined representation. This may be omitted by mutual consent of those interchanging data, if ambiguity can be avoided.

Thus it seems to me that the proposed format does not violate the ISO 8601 standard; omitting the "T" also does not lead to ambiguity in this case (since the used components, precision and delimiters are fixed).Personally, I prefer to use a space instead of the "T" in a combined data/time format whenever possible, since the "T" joins the data and time portions into one solid, hard-to-read (for human eyes!) block of characters. The author(s) of the APEv2 tagging format apparently felt similar about this.

Well, the recommended format for play timestamps has already been decided upon, but perhaps this post can help you accept it.

The symbol "T" is used to separate the date and time parts of the combined representation. This may be omitted by mutual consent of those interchanging data, if ambiguity can be avoided.

[a href="index.php?act=findpost&pid=274934"][{POST_SNAPBACK}][/a]

Between the lines, we do already exactly that. Although it is not "officially" accepted and not part of the agreed tag-standard, exchanging the space with a T would probably not break anything, because:- when validating the format, we avoid checking the space - validation in the proposed code-snipped depends on the year-format and the appended dash, and the position of the first collon in the time-part. Thus, the tag would still validate even with a T in it.- when splitting up the timestamp, we also avoid touching the position where the space is.- when displaying either time or date only without reformating, we as well dont touch the position where the space is.

So, even if someone would "break" the agreed standard, then it still wouldn't break anything in the formatting/plugin - with the exception of sorting: having mixed versions of the tag (some with T, some with space) would mess up sorting(without reformatting).

Short version, it is strongly unrecommended to change anything to the format itself (except of appending stuff after the timestamp) - but in case someone would use the T, then it wouldn't make the world end ;-) But don't take this as a guarantee - while the example code-snippets don't depend on it, someone else may write code which depends on it.

well, i could change the default to dark-grey. Making it brighter would make dark-schemes look ugly. There's not much more i can do about it, because as i said, the strings have no access to the playlist background-color - they can only change the colors of track-rows - thus, there is currently no way to change the bg-color based on the selected color-scheme - unless i make every color-scheme a seperate fcs - i'm already maintaining 4 FCSs and that slows down updates quite alot (thats why i'm now "collecting" fixes and changes and then apply them all together in a new release).[a href="index.php?act=findpost&pid=274690"][{POST_SNAPBACK}][/a]

Why not just set the default exposed background color to match the default theme and then explain in the html file how to change it? I set mine to the darker stripe of the default theme, 55 60 85, and it looks great.

I've installed Navigator a couple days ago and I'm really impressed. It's been growing on me ever since. Great work.

major update - changelog as usual in the first-post - backup your custom color-schemes before upgrading

[span style='font-size:8pt;line-height:100%']Besides of many other changes, this version drops support for many exotic-tags. I guess an explanation is in order: When i began writing formattings - back to the days of "Gems" - it was my impression that the reason why so many different ways did exist to do the same thing was that users and developers were just in an ambigious situation or couldn't know better(everyone was a newbie once) - and that possibilities were missing to standardize things. In other words, that users and non-commercial devs were mostly innocent about the situation.

This was the reason why i began to support all kinds of different ways to mark stuff - users shouldn't have to live with incompatibility when it wasn't their fault. And so i began to write FCSs which would work no matter how the users does mark, name and sort his files. This made my formattings slower than those of others - but that imho was still better than incompatibility.

However - while i understood the "effect" quite well, i heavily underestimated the "cause": We have another installment of "overally, everyone gets what he/she deserves" here - the cause are the same people who are the "victims"(users as well as devs). This changes the entire fundament of why i initially began the "compatibility-with-everything"-approach. Thus, i see neither reason nor motivation to continue spending dozens of hours slowing down my FCS because and for the same people who are responsible for the ambigious situation.[/span]

------------

Comanche, i wanted to include your color-scheme, but because of the recent changes to the way colors are calculated, its now quite out of balance, sorry. Also, the special-color is very difficult to read on the background which you did choose. I'll include your color-scheme when you got some time to rebalance it.

Lyx, i don't know exactly what i did, but when i change Special_color nothing happens, just like something is missing in the code, so when i select some song on the playlist it gets too dark, the selected song only gets better when i use Light-theme.

In the colors i think i choose a mid-term for Light and Dark-theme and i can't figure out what side to choose