The metadb_display_hook API is deprecated from now on and should not be used in new components. A new API will be introduced with foobar2000 0.9.5.2 to allow components to provide a set of fields – but not functions – for title formatting tracks. In a later version, the core and official components will stop using the metadb_display_hook API.

The new API requires a component to provide a list of the names of the provided fields. This will allow the title formatting engine to do more efficient look-up of fields compared to the old API. It will also allow the operating system to page out code for unused fields, reducing foobar2000's memory usage with lots of components loaded.

The reason why there will not be a replacement API that allows components to provide functions for use in title formatting code is that we, the foobar2000 developers and forum staff, do not like the style of title formatting use that has emerged since and due to the introduction of the metadb_display_hook API and the effect this has on the reputation of foobar2000. The title formatting language is not a full-blown scripting language, and we strongly believe it should not be used as such. While we have tried to reduce the amount, size and complexity of title formatting code in the official components to make foobar2000 easier to use, a contrary development has taken place with third-party components. As a first step to emphasize our position on this matter, we have decided to stop official support for an API that has been vital in this development. Third-party developers are free to choose their own position in this matter.

Consequences for developers

If you wish to support fields and functions provided through metadb_display_hooks in your component, you will need to implement a titleformat_hook that calls the metadb_display_hook instances. There should be no problems, if you already do this before the core stops using metadb_display_hooks except for a possible performance loss.

Consequences for users

The metadb_display_hook API is used to provide additional fields and functions when title formatting tracks. Removing support for this in the core will have the following effects on official components and on third-party components that do not add explicit support for the metadb_display_hook API:

• Additional fields will only be usable, if the component providing the fields is ported to (also) implement the new API.
• Additional functions will not be usable.

Are there any plans to provide a scripting language in foobar or as an official component when or before the metadb_display_hook API is removed?

No, there is no plan to provide a scripting engine at this point.

Are there plans for additions to the functions provided in foobar titleformatting in order to provide some or all of the functions in the components which will not work?

Many of the functions in the additional components seem entirely valid for inclusion in a title formatting language, e.g color, font setting, alignment and drawing commands, $eval, date and time processing (e.g. $cwb-hms), string handling (e.g. $cwb_removethe) etc.

I always thought the title formatting language is made for text processing, i.e. you give some text values in and then get the text result out. Therefore I believe that "drawing commands" and other presentation related functions don't belong there.

Agree completely. Nevertheless, there are still functions like computing the difference between two dates that deserves to be part of the official language (as its done so frequently).

I didn't wrote anything about the additional date/time or string processing functions on purpose, I can imagine how they could be useful, even if not for me.
Perhaps it might be useful if someone made a public maintained list of the most wanted missing functions, together with real-life usage scenarios, well-thought syntax and functionality, so that they could be easily reviewed and considered for implementation by the core development team.

Title formatting means more than just passing text in and getting text out - that's just string handling. In order to format titles you need colors and alignment, etc. etc.

Does the name of the script language matter so much that it should determine what happens within it? If so, why not call it "foobar functions" rather than "title formatting"?



My question remains, though, whether or not any review or the language is planned?

Sorry, but aside from your personal opinion, the fact remains that title formatting is implemented as text-processing only. This is not imposed on us by the name that was chosen, but by how it has been designed by the foobar2000 developer. If at all, the name can be said to reflect his intentions, which ultimately matter in this decision.

Please do also keep in mind that title formatting is not only used to draw text on the screen, but also to format tags, filenames, sort tracks in the playlist, determine how albums are grouped by shuffle or replaygain, and so on. Coloring functions and $tab() were the only official additions that hinted at drawing text, and for the most part, they have been removed from official components by now.

Now about text-processing functions:


I think the point that you are missing is that the functionality you are after does not necessarily have to be implemented at the level of title formatting, or with title formatting at all.

What has happened throughout the years is that some users kept pushing the limits of title formatting forward to the extent that they have lost the ability to express what they actually want, as well as to recognize and accept that some feature has yet to be considered, thought through, and implemented in a reasonable and usable manner.

So for example, instead of stating that they would like to have a playlist of tracks added or played during the last two weeks, users urged component developers to add yet another variable or function to somehow knock it together. And while they were able to claim that foobar2000 offered a certain feature afterwards, it would remain completely undiscoverable for most users. Guiding them through the necessary steps of creating such a playlist would have resulted in the notion that the program was utterly complicated. That is what we have in mind when we refer to its reputation.

So instead of making lists of functions that would break and demanding them to be added back, we would like to ask you to break out of this way of thinking, and to request actual features instead of difficult-to-discover additions to title formatting.


From what I can tell, it will certainly not evolve in the direction you are aiming at.

[quote name='Kiteroa' post='557108' date='Apr 5 2008, 02:44']My question remains, though, whether or not any review or the language is planned?[/quote]
From what I can tell, it will certainly not evolve in the direction you are aiming at.
[/quote]


So will there be any additional functions added ?

Can you explain who are these people ? I know Peter, the main developer, you (as the second developer ?). I've discovered Frank since new UI with his "facets" component.
But I don't know the others, and it's not written in foobar2000 home page.

In fact, I'd like to know who are the people who take decisions, have access to SDK and have others advantages.

Peter, Frank and me are responsible for this decision.

Edit: Typo.

I'm wondering, isn't this also going to affect musicmusic's UI?
Like functions $set_global() and $set_style() that are almost necessary for customization.
Are color functions also going to be removed at some point in the future?

In the first post, foosion wrote:
I understand it as that if some component will want to give user an extra set of fields/functions for a titleformatting string evaluated by itself, it can - even by asking all the old & deprecated components if they handle the found functions. (Now I don't know what those $set_global/style() functions do and where they are used, but if they are evaluated by Columns UI itself, this should work after a few minor changes.)

What will be different is the default behavior, i.e. the core/default parts of foobar2000 and the components which won't do this work themselves won't automatically get access to the fields/functions provided by metadb_display_hooks any more.

For additional globally visible fields, the new better API is being created. For additional functions, no similar functionality will be introduced.

(Please correct me if I'm wrong, anybody.)

There is another way for components to provide additional fields and functions for title formatting. When a component evaluates a title formatting script, it can provide additional fields and functions locally. As far as I know this is what Columns UI does for the aforementioned functions, so it will continue to work without changes.

The problem with the metadb_display_hook API is that it was designed assuming that people who use the SDK read the documentation/specifications and think about consequences of what they create. Clearly that was a horrible mistake.
Nearly all the people implementing this API haven't read the documentation at all or are intentionally ignoring what the documentation says and creating halfworking crap to keep users requesting new title formatting functions happy.
In my opinion, title formatting has became a disease that eats people's brains out. Nuking of component-provided title formatting functions is necessary so we can evaluate what it is that people need those functions for and perhaps provide properly working means to achieve the same, without halfworking hacks such as title formatting functions to control playback / playlist switching / etc involved (clearly forbidden by the metadb_display_hook specification but implemented by circulating components anyway).

I see that some features of Panels UI depend on metadb_display_hook too. This is another example of component author's incompetence and ignoring what the specification says - metadb_display_hook is not meant for implementing context-specific features such as variables, for an example, Columns UI is completely unaffected by this change just because its author knows what he is doing.

Finally, I'd like to point that it's very easy to add entirely new APIs to foobar2000's component interaction model. Component authors could have easily created a new API for providing extensible script-like functions as well as dealing with the refreshability problem and set the rules regarding what is legit and what is not themselves BUT NOOO it's so much more fun to bend the existing thing and break the rules, creating security holes or other possible crashes on invalid user input etc.


EDIT:
Having lots of metadb_display_hook implementations murders title formatting performance, even for components that don't care about provided functionality.
No metadb_display_hook installed: Album List refreshed in: 0:00.131706
Playback Statistics component only: Album List refreshed in: 0:00.134599
Playback Statistics component + 10 stub metadb_display_hooks that perform random strcmps: Album List refreshed in: 0:00.221873
This isn't exactly news, the documentation said to stay away from installing display hooks whenever possible because of performance issues.
There's no such problem with the new API, impact on performance of title formatting operations that don't reference added fields is nonexistent.

+1 totally agree, the foobar devs put in far too much hard work for someone else to be lazy and not implement their components properly...

big thx to all the great new stuff you guys keep adding in standard foobar, specifically the added tag, now that i have this I do not need any crazy scripting / hooks components.. phew..

One more thing: all kinds of components pass title formatting strings around and evaluate them without any kind of trust rules or input sanitization. If title formatting strings can trigger arbitrary commands (which is where recent development of foo_cwb_hooks, foo_func and such was leading), somebody will eventually create title formatting based malware and embed it in some kind of downloadable visual scheme files passed between users.

If title formatting abuse was allowed to continue, someday we'd probably need to implement "are you sure you want to open this file?" security popups when loading visual scheme files, as title formatting strings contained in those typically get immediately processed, even when just previewing the layout.
Which would look highly idiotic, but it's not really more idiotic than what has already been done.

I'd like to say that I totally agree with the direction taken by developers for foobar2000.
The new DefaultUI is so, in one word, coherent (well there is also easy-to-configure). Exactly at the opposite of PanlesUI !

Just a request : to make the UI Elements SDK available as soon as possible because inserting components in the DefaultUI like CoverFlow or LyricShow would be very useful.

Thanks for the great work!