Add DnD of OSC paths from plugins?
- Dominant language
- C++
- Stars
- 10.4k
- Forks
- 1.3k
- Avg merge
- 2d 13h
- Merged PRs (30d)
- 7
Description
### Enhancement Summary
Refactor functionality from the SPA plugin PR (#4662) into a separate PR. It's about drag-dropping OSC paths from (external) plugins onto LMMS controllers/automation. I can add it almost immediately, and it will be non-reachable code on master for now.
#### Justification
It's an independent split-feature from the SPA PR that could, in theory, be used generically. It could be used by any plugin that support DnD of osc paths. Though, there's no evidence it will ever be used, and it will not be useful for Lv2 (DnD mimetypes/data are not a part of the Lv2 specs and probably won't be too soon).
Also #5592 .
#### Mockup
It would work like this:
1. All (external) plugins can register with a port. The mapping port->plugin is stored in the Engine.
2. When a drag from an (external) plugin drops on an LMMS automation pattern, the clipboard for this drag-drop-action will contain something like:
1. mime type: application/x-osc-stringpair
2. data: osc.udp://127.0.0.1:udpport/path/to/oscport
3. LMMS looks up the plugin by passing the udpport in the Engine.
4. The plugin class gets a new "model at path" virtual function. LMMS passes "/path/to/oscport" there to get a pointer to the corresponding model from the plugin.
5. If the model does not yet exist, the plugin creates it now.
6. LMMS now has both a model from the plugin and the controller/automation, so it can connect the two.
#### Question
There are disadvantages:
1. It will be non-reachable code on master branch (tested by me on the SPA branch, but not tested and not reachable on master)
2. The code might never be used on master and confuse other devs ("what is this used for?")
Should we add this feature as non-reachable code?
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing the SPA plugin PR referenced as #4662 and the related issue #5592 to understand the proposed split. Resolve whether non-reachable OSC drag-and-drop support should be added to master; the issue does not name implementation files or tests, so a maintainer decision is needed before coding can begin.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- desktop
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100