vanja/yabridge
1
0
Fork 0
mirror of https://github.com/robbert-vdh/yabridge.git synced 2026-06-25 13:27:26 +02:00
Code Issues Packages Projects Releases Wiki Activity

Reword changelog

Browse Source
This commit is contained in:
Robbert van der Helm
2021-07-31 21:26:28 +02:00
parent c267175a60
commit aff0e38e1f
2 changed files with 44 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CHANGELOG.md
+40 -41
View File
@@ -10,54 +10,53 @@ Versioning](https://semver.org/spec/v2.0.0.html).
### Added ### Added
- Added the ability to directly focus the plugin's editor instead of allowing - You can now directly focus the plugin's editor instead of allowing the host to
the host to also process keyboard events by holding down the <kbd>Shift</kbd> process keyboard events by holding down the <kbd>Shift</kbd> key while
key while entering the plugin's GUI with your mouse. Certain hosts like entering a plugin's GUI with your mouse. Certain hosts like **Bitwig Studio**
**Bitwig Studio** normally still respond to the common key presses like Space normally still respond to common key presses like <kbd>Space</kbd> for
for play/pause while interacting with a plugin. This does mean that it becomes play/pause while interacting with a plugin. That in turn can make it
impossible to type a space character in those hosts, which can become a impossible to type a space character in those hosts, which may become a
problem when naming presets. With this feature you can temporarily override problem when searching for or naming presets. With this feature you can
this behaviour, and allow all keyboard input to go directly to Wine. This can temporarily override this behaviour and allow all keyboard input to go
also be useful for _Voxengo_ plugins, which don't grab keyboard focus in their directly to Wine. This can also be useful for _Voxengo_ plugins, which don't
settings and license dialogs. grab input focus in their settings and license dialogs.
### Changed ### Changed
- Added more tracing for input focus handling when using the `+editor` - Added more tracing for the input focus handling when using the `+editor`
`YABRIDGE_DEBUG_LEVEL` flag. `YABRIDGE_DEBUG_LEVEL` flag.
- In addition to the other editor and event handling related changes mentioned - Yabridge will now handle X11 events from within the Win32 message loop. What
in the fixes section below, yabridge will now handle X11 events from within this means is that X11 events are now handled even when the plugin is blocking
the Win32 event loop. What this means is that X11 events are now handled even the GUI thread, which can potentially increase responsiveness and help with
when the plugin is blocking the GUI thread, which could potentially increase graphical issues in certain situations (although at the moment there aren't
responsiveness and help with graphical issues in certain situations (although any known situations where the old approach caused any issues).
at the moment there aren't any known situations where the old approach caused
any issues).
### Fixed ### Fixed
- Reverted the workaround for _Nimble Kick_ freezing added in yabridge 3.5.0. - Reverted the workaround for the _Nimble Kick_ plugin freezing added in
This could cause VST3 plugins in **Bitwig Studio** and **Ardour** to have yabridge 3.5.0. This could cause VST3 plugins in **Bitwig Studio** and
frozen, nonfunctional editors when using multiple instances of the plugin **Ardour** to have frozen, nonfunctional editors when using multiple instances
unless you opened every plugin instance's editor. Since the plugin would also of a plugin unless you opened every plugin instance's editor. Since the plugin
cause the native Windows version of Bitwig Studio to crash, we should thus would also cause the native Windows version of Bitwig to crash, we will thus
just simply revert this change. simply revert this change.
- Changed how input focus releasing works by more specifically ignoring events - Fixed a regression from yabridge 3.5.0 where clicking inside of a plugin GUI
where the mouse pointer is still hovering over a Wine window instead of while the window is already open in the background would not give keyboard
ignoring a wider class of events. This should fix some edge cases where input focus to the plugin.
focus would not be given back to the host, or where dropdown menus could close - Changed how input focus releasing works by more selectively filtering out
immediately when moving your mouse outsdie of them. The first case would in mouse pointer leave events where the pointer is still hovering over a Wine
practice only happen when using a touchscreen or drawing tablet, since that window instead of ignoring an entire wider class of events. This should fix
would require the mouse to instantly move from the plugin GUI to another some edge cases where input focus would not be given back to the host, or
window without going over the window's borders. where dropdown menus could close immediately when hovering over and them
- Similarly, the filter in the Wine->X11 drag-and-drop implementation for leaving them with your mouse. The first case would in practice only happen
distinguishing between Wine windows and other windows (so that we won't when using a touchscreen or drawing tablet, since it would require the mouse
interfere with Wine's own internal drag-and-drop mechanism) has also been made to instantly move from the plugin GUI to another window without first going
more specific. Before this change we might use our own XDND implementation over the window's borders.
when dragging from a plugin to a standalone Wine application running within - Similarly, the filter in yabridge 3.5.0's Wine->X11 drag-and-drop
the same Wine prefix. implementation for distinguishing between Wine windows and other windows (so
- Fixed an edge case where clicking inside of a plugin GUI in **REAPER** while that we won't interfere with Wine's own internal drag-and-drop mechanism) has
the FX window already open in the background would not give keyboard focus to also been made more specific. Before this change we might use our own
the plugin. XDND-based drag-and-drop implementation when dragging files from a plugin to a
standalone Wine application running within the same Wine prefix.
## [3.5.0] - 2021-06-23 ## [3.5.0] - 2021-06-23
README.md
+4 -4
View File
@@ -207,10 +207,10 @@ Yabridge tries to be clever about the way grabbing input focus for a plugin and
subsequently giving it back to the host works. One important detail here is that subsequently giving it back to the host works. One important detail here is that
when grabbing input focus, yabridge will always focus the _parent window_ passed when grabbing input focus, yabridge will always focus the _parent window_ passed
by the host for the plugin to embed itself into. This means that hosts like by the host for the plugin to embed itself into. This means that hosts like
Bitwig Studio can still process common keys like Space for play/pause even while Bitwig Studio can still process common keys like <kbd>Space</kbd> for play/pause
interacting with a plugin's GUI. The downside of this approach is that this also even while interacting with a plugin's GUI. The downside of this approach is
means that in those hosts you simply cannot type a space character, as the key that this also means that in those hosts you simply cannot type a space
will always go to the host. character, as the key will always go to the host.
For the very specific situations where you may want to focus the plugin's editor For the very specific situations where you may want to focus the plugin's editor
directly so that all keyboard input goes to Wine, you can hold down the directly so that all keyboard input goes to Wine, you can hold down the