Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability to hide external UI #84

Open
riban-bw opened this issue Jul 7, 2024 · 3 comments
Open

Add ability to hide external UI #84

riban-bw opened this issue Jul 7, 2024 · 3 comments

Comments

@riban-bw
Copy link

riban-bw commented Jul 7, 2024

There is a command show_external_ui which shows the LV2 plugin's external UI. There should be the complementary function to hide the UI. There should also be a check as to whether the external UI is already showing before launching it, otherwise you can get orphaned displays.

riban-bw added a commit to riban-bw/mod-host that referenced this issue Jul 7, 2024
Check if external ui is running before allowing a new instance.
Add command hide_external_ui.
@riban-bw
Copy link
Author

riban-bw commented Jul 7, 2024

I have submitted a PR to fix this issue. Note that the external UI is actually not useable due to its idle function only being called when a command is received on its socket. (I will report that separately.)

@riban-bw
Copy link
Author

riban-bw commented Jul 8, 2024

I wonder whether supporting external UI is advantageous? It is not really the core functionality of mod-host and it doesn't currently work. A host that supports UI should really support more than the external UI (which few plugins provide) and adding wider UI support is a big task. It may be appropriate to remove the (currently broken) support for external UI and depend on other applications (or extensions) to provide that support.

@falkTX
Copy link
Member

falkTX commented Jul 8, 2024

external ui is in use for https://github.com/moddevices/mod-desktop.
there is no need for a "hide" call because the window that appears will be closable by the user.

on the oddities around it and the idle function yeah, this still needs work. specially on windows and macOS where such "idle" functions are only allowed on the main message thread, so this is broken as-is in many ways.

the way to go is probably to plug into the main event loop on windows and mac, and spawn a new thread everywhere else.
that will keep the event loop going independently of the socket connection, but then likely a mutex is needed to prevent data races.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants