Introducing foobar2000 SDK with libPPUI
Download: https://www.foobar2000.org/SDKNow available on the main website - old SDK available as the 'backwards compatible version'What is libPPUI?
libPPUI consists of:
- All code from "SDK helpers" modules in old foobar2000 SDK versions that was not in any way specific to foobar2000.
- Never-published-before utility code from Default User Interface, including full source code of CListControl which is used to implement the default playlist view.
Unlike old foobar2000 SDK helpers, libPPUI can be easily used in any C++ program for Windows desktop.
libPPUI is available under a non-restrictive license (zlib license), can be reused in free or commercial programs, open or closed source, without copyright disclaimers - as long as you don’t redistribute source claiming that you wrote it.Compatibility with existing source code
Because code from old "helpers" got moved to new locations, your existing code will likely require editing. In most cases, fixing #include paths will be enough.Compatibility with old foobar2000 releases
Nothing changed here, this SDK can produce components compatible with 1.3 series and newer.Highlights of interesting classes for reuse in other apps:
CListControl - Win32 list control with embedded editboxes, buttons, group headers, etc. This is the class that drives the default playlist view of foobar2000 0.9.5 and newer.
CMiddleDragImpl - Implementation of middle click scroll for any win32 control (treeview, listview, custom controls).
CEditWithButtons - Embed buttons in an editbox.
Note that foo_sample component has been fully updated for libPPUI; a CListControl demo has been added.
Hm... I'm a bit confused with new `metadb_handle::get_info_ref` method.
It seems that info that info returned by `metadb_handle::get_info_ref` is:
1. Constant: can't be modified via `set_*` methods.
2. Non-updateable: data will remain the same, even if some tags were modified.
Since `metadb_handle::get_info` was declared as `deprecated`, I'm trying to replace it with the new API, but I'm not sure how to workaround these two new characteristics.
The scenarios I'm trying to (re-)implement:
1. Modify associated file tags in metadb_handle (via `file_info::meta_*` methods).
2. Keep the same behavior as it was previously for the `file_info` constness (I'm might be mistaken though that `file_info` from `get_info` was actually dynamic).
Thanks in advance! =)
get_info_ref() is old subject really, 1.3 era change.
It accesses metadb-managed file_info instances in a lockless/noncopying way.
With get_info(), a lock+copy cycle occurred - slow for lots of items.
With get_info_locked(), caller had to ensure metadb lock for the duration of whatever the caller does with the data.
Both were problematic for multi-threaded processing of metadb info.
With the new function, you can efficiently obtain a reference to a snapshot of the current state, which can be then accessed without any locking or copying, from any thread.
Not sure how/why you want to modify metadb contents. None of these functions were ever meant for this.
Not sure how/why you want to modify metadb contents.
It was used to modify metadata tags. Same usage as "Properties" context menu for track in the playlist.
Is there a better/proper API?
Sample code please, I'm not sure if I understand correctly what you did before.
^ this is just an example, and not the code that is actually used in my component.
The method in my component works on handle list and can update arbitrary number of meta tags, but the fb2k API usage is mostly the same.
file_info_impl fileInfo = handle->get_info_ref()->info();
... and the rest doesn't need changing.
The result is the same as before, only with better performance if used in multiple threads due to less locking.
Yep, I'm dumb, it's official now. Thanks! >_<
I blame my general lack of sleep though =)
No problem, happens to all of us...
The reasoning of this change is non obvious, until you dig into specific usage cases... Selection Properties and Library Search which need to go over lots of info - preferably in multiple threads - benefit the most.
Frankly the old API still works and will probably never stop working.... as it would make some of existing >10 year old DLLs in circulation stop working.
New version posted: SDK 2019-07-08 ( see first post )
Added Tree View multi-selection tool from Album List.
CListControl improvements, added new ready-to-use CListControl flavours that do not need subclassing.
Added two new CListControl use demos to foo_sample.
, FYI: latest SDK contains an empty ATLHelpers folder
New version posted, with bug fixes in libPPUI classes and dynamic main menu item example in foo_sample.
Thanks for the sample!