Today to implement window.Window you must provide a string-based clipboard implementation as well:
// Window represents a single window that graphics can be rendered to. The
// window is safe for use concurrently from multiple goroutines.
type Window interface {
...
// SetClipboard sets the clipboard string.
SetClipboard(clipboard string)
// Clipboard returns the clipboard string.
Clipboard() string
...
}
This is unfortunate because one might be able to implement a Window in places where implementing a clipboard is not doable or easy. We could separate clipboard features into a separate interface, however:
type Clipboard interface {
// SetClipboard sets the clipboard string.
SetClipboard(clipboard string)
// Clipboard returns the clipboard string.
Clipboard() string
}
Then to test if a window.Window supports modifying the clipboard, you can simply:
cb, ok := win.(window.Clipboard)
if ok {
// We have clipboard access.
cb.SetClipboard("Hello World!")
}
This is also a good way that we could provide access to further clipboard data types (for example window.ClipboardImage, for image data perhaps).
Issue by slimsag Wednesday Nov 26, 2014 at 00:35 GMT Originally opened as https://github.com/azul3d/gfx/issues/51
Today to implement
window.Window
you must provide a string-based clipboard implementation as well:This is unfortunate because one might be able to implement a Window in places where implementing a clipboard is not doable or easy. We could separate clipboard features into a separate interface, however:
Then to test if a
window.Window
supports modifying the clipboard, you can simply:This is also a good way that we could provide access to further clipboard data types (for example
window.ClipboardImage
, for image data perhaps).