Hello!

I plan to implement a Foobar2000 plugin with the following features:
From the currently selected playlist the marked items (1 or more) should be added through a double click to another playlist:
1.) Add to the hardcoded playlist e.g. Default
2.) Add to the hardcoded playlist queue e.g. Playlist Queue
3.) Add to the current playing playlist.

1.) with context menu is already implemented, but I don't know how to hook the double click. Any hints for the API calls?

BTW: Can someone explain the differences between a playlist queue vs. normal playlist. How is the order of playment.

Thnx.

Wiesl

What you are proposing is Not Allowed. See the SDK license for details.

The only way to do this is to request the authors of the current playlist plugins (AFAIK columns_ui and single column playlist) and request that they add this option.

So that must come from the following license part:
Usage restrictions:
It is illegal to use this SDK as a part of foobar2000 components that operate outside of legally documented programming interfaces (APIs), such as using window procedure hooks to modify user interface behaviors. We believe components doing so to be harmful to our userbase by introducing compatibility issues and dependencies on undocumented behaviors of our code that may change at any time without any notice or an update to the SDK which would reflect the change.

Correct?

So aren't there any documented methods which can be used as API for the double click feature?

BTW: Why is it allowed for the authors of columns_ui and single column playlist to use such hooks?

Wiesl

No, there aren't. You can override the default action for a specific playlist in a playlist lock. Obviously this will only work for playlists that have your special lock installed, and you should not install locks on arbitrary playlists without the user's command.


They don't need to hook into another component as they can do whatever they like in response to a double-click in their own playlist view. (Although it is recommended to use the playlist manager API to execute the default action.)

Ad 1.)
Yes, I saw that with locked playlists. What's exactly a locked playlist in the context of the API? Does it mean read only?

Ad 2.)
Yes, but they also need Windows API hooks to do so. And that's outside of the SDK API which is IHMO forbidden ...

Thnx.

Wiesl

It means that all requests to alter the playlist have to be accepted by the installed lock. For example, you can make the playlist content read-only (like the "Read-only" function in foo_utils), or you can set the playlist content based on some filter criteria (like foo_autoplaylist) by only letting your own requests through. Effectively, you get to control the playlist content and how the user can modify it.


No, you don't get it. They don't need special hooks. These windows get the input events directly from the message queue (via the message loop).

The foobar2000 SDK prohibits hooking and modifying windows from other components, as this can break at any time when the implementation of the other component changes, but you are free to handle events in the windows of your own component as you see fit.

The author of a component can hook his own window(s) if he feels so inclined. There is no specific ban on using hooks, you just can't interfere with another component's window.

Im going to reply to your post from Columns UI thread here since this is where most of the discussion is (and its pretty much same as a post above).
Yes its possible to make such an API. But it gets complicated: as already mentioned a playlist lock can already override this. Now you would want those to behave as expected. Then also you have the fact that your component will depend on specific UI/playlist view modules. It is possible for the first issue to be worked around, although personally I prefer to leave custom actions like these to e.g. middle click. There's another issue, you mention "1 or more" items but you should know that double clicking an item will select it exclusively.

Now there is no API to do it, but a 'hook' on playlist_manager::playlist_execute_default_action will at least remove the UI module dependency (up to the active playlist view being well written).

BTW at least in the Columns UI playlist switcher you can disable the activation of the target playlist when dropping items on it. So sending tracks to some playlist should be fairly painless with drag and drop. You also won't have to change a setting depending on which playlist you wish to send the items to (!)


Well for a start there's no hooking involved. The active UI is the component that provides the playlist view (it could be implemented in another component though). The default Columns UI playlist view uses a custom control so it receives its own double click notifications. But even if it was using a list box/view control, those send double click notifications so still there's no hooking involved.

Even if it did want to hook its own list control that would be OK because it's its own window. Remember its equally outside of the foobar2000 API to call CreateWindow to create the list control in the first place! As mentioned the comment in the SDK refers to messing with other components outside of their or foobar2000's documented APIs.

Ok, I tried to code something with the following concept with locked playlists:
1.) Make hooks for the playlists (pm->register_callback())
2.) On the hooked playlists: on_playlist_created(), on_playlists_removing(), on_playlists_reorder() remember the playlists an lock them with pm->playlist_lock_install().
3.) On playlist_lock: Hook execute_default_action() to another action.

Is the concept ok?

Coding is complete, but I'm having the following problem:

context_playlist_default::context_playlist_default()
{
static_api_ptr_t<playlist_manager> pm; // Crash here
}

static contextmenu_item_factory_t<context_playlist_default> foo;

It crashes on the constructor. Calling it later in the context menu is ok.

Any other ideas for better initialization or startup code?

Thnx.

Wiesl

No, if you are blindly trying to lock every playlist that is created then it is definitely not okay. The playlist lock mechanism is intended to alter the behavior of selected playlists, it is not a means to alter the general behavior of playlists.


You cannot use foobar2000 services in the constructor of static objects. What are you trying to do in the constructor that requires the playlist manager API?

Ok, what better concept possibilities are available?

Constructor crash:
I want to install the hooks for the playlist register callback: pm->register_callback()

What's the best method for this?

Wiesl

You should use a class derived from playlist_callback_static and define a static service_factory_single_t object for it. Note that you cannot implement multiple services on a single class, so you cannot add this to you context_playlist_default class.

Ok, I implemtented the stuff. But it looks like that columns UI has already locked all playlists ...
So the only solution is that columns UI authors implement something ...

Columns UI currently has the following options in playlist view:
1.) double click on empty playlist area (where all functions can be selected)
2.) Action to perform when middle clicking on playlist item (only Remove from playlist and Add to playback queue can be selected, no custom function).

My suggestions are:
Action to perform when middle clicking on playlist item: Full function list
Action to perform when double clicking on playlist item: Full function list

BTW: Is it planned to make columns UI an open source project?

Wiesl