Add getContentsAsync methods to Clipboard #2650
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Obtaining data from the clipboard is fundamentally an asynchronous operation, the event loop, at least at the OS level, needs to run for the data to become available. This PR proposes new API that provides asynchronous equivalents of getContents methods called getContentsAsync that return CompleteableFutures. This new API will allow SWT API consumers to interact better with the clipboard when the OS (window system) API is actually implemented in an asynchronous manner. GTK3 and cocoa provides API that spins the event loop as needed so that a synchronous looking API can be provided to the user of the API. For example, in SWT we use gtk_clipboard_wait_for_contents which spins the loop in the GTK library itself [here](https://gitlab.gnome.org/GNOME/gtk/-/blob/716458e86a222f43e64f7a4feda37749f3469ee4/gtk/gtkclipboard.c#L1436) GTK4 does not provide such an API and leaves it to the user of the API to spin the event loop. Win32 is somewhat of a hybrid. The API appears synchronous, but SWT needs to spin in a couple of places, such as [getData](https://github.com/eclipse-platform/eclipse.platform.swt/blob/63e8925dc77db3b93ef521dc6cf2bd6ded7bab64/bundles/org.eclipse.swt/Eclipse%20SWT%20Drag%20and%20Drop/win32/org/eclipse/swt/dnd/Transfer.java#L46) Part of eclipse-platform#2598 and eclipse-platform#2126
jonahgraham
force-pushed
the
clipboard-async
branch
from
b2a899f to
1987581
Compare
|
One aspect I am unsure of is the naming here. We can't simply overload Am I overthinking this, is |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Obtaining data from the clipboard is fundamentally an asynchronous operation, the event loop, at least at the OS level, needs to run for the data to become available.
This PR proposes new API that provides asynchronous equivalents of getContents methods called getContentsAsync that return CompleteableFutures.
This new API will allow SWT API consumers to interact better with the clipboard when the OS (window system) API is actually implemented in an asynchronous manner.
GTK3 and cocoa provides API that spins the event loop as needed so that a synchronous looking API can be provided to the user of the API. For example, in SWT we use gtk_clipboard_wait_for_contents which spins the loop in the GTK library itself
here
GTK4 does not provide such an API and leaves it to the user of the API to spin the event loop.
Win32 is somewhat of a hybrid. The API appears synchronous, but SWT needs to spin in a couple of places, such as
getData
Part of #2598 and #2126