You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a type (a graphical widget) that implements screen.Buffer, which I've been using happily with gldriver, under darwin. The documentation is here, and there is an example program sigint.ca/graphics/editor/example/multi if you are interested.
The widget is implemented as a type Editor which implements screen.Buffer, and is drawn to a shiny window as follows:
Unlike gldriver, methods implemented by x11driver assume that any screen.Buffer, screen.Texture, etc. passed to them are the implementations provided by x11driver, and panic when they are not.
Is this restriction necessary? Should I rethink my strategy? Why provide an interface if it's not allowed to be implemented?
The text was updated successfully, but these errors were encountered:
The interface is provided because the screen package is not specific to any one driver: the x11driver buffer implementation is not the same as the gldriver buffer implementation. Nonetheless, the Screen.NewBuffer method has to return a type - an abstract, driver-indepentent type - and in Go, abstract types are interface types.
The foodriver Window is not expected to handle any Buffer implementations other than the foodriver Buffer implementation.
You will need to rethink your strategy. Your Editor should not be a Buffer. It should be able to render itself onto a Buffer (one provided by Screen.NewBuffer).
This makes gldriver behave the same as windriver and x11driver,
making it less likely for an app to 'work' on one driver but not
another.
Updates golang/go#14026.
Change-Id: Id795f6b9f43a67faa954653404a23ae5783f8261
Reviewed-on: https://go-review.googlesource.com/18791
Reviewed-by: David Crawshaw <crawshaw@golang.org>
I have a type (a graphical widget) that implements screen.Buffer, which I've been using happily with gldriver, under darwin. The documentation is here, and there is an example program sigint.ca/graphics/editor/example/multi if you are interested.
The widget is implemented as a type Editor which implements screen.Buffer, and is drawn to a shiny window as follows:
However, when I tested my code on linux recently, I quickly ran into a problem:
Unlike gldriver, methods implemented by x11driver assume that any screen.Buffer, screen.Texture, etc. passed to them are the implementations provided by x11driver, and panic when they are not.
Is this restriction necessary? Should I rethink my strategy? Why provide an interface if it's not allowed to be implemented?
The text was updated successfully, but these errors were encountered: