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

x/exp/shiny: x11driver makes it impossible to implement screen.Buffer #14026

Closed
jnjackins opened this issue Jan 20, 2016 · 3 comments
Closed

Comments

@jnjackins
Copy link
Contributor

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:

widget := editor.NewEditor(size, font, nil)
...
win.Upload(image.ZP, widget, widget.Bounds())

However, when I tested my code on linux recently, I quickly ran into a problem:

func (w *windowImpl) Upload(dp image.Point, src screen.Buffer, sr image.Rectangle) {
    src.(*bufferImpl).upload(w, xproto.Drawable(w.xw), w.xg, w.s.xsi.RootDepth, dp, sr)
}

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?

@jnjackins
Copy link
Contributor Author

FYI @nigeltao @crawshaw

@nigeltao
Copy link
Contributor

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).

@gopherbot
Copy link

CL https://golang.org/cl/18791 mentions this issue.

gopherbot pushed a commit to golang/exp that referenced this issue Jan 21, 2016
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>
@golang golang locked and limited conversation to collaborators Jan 23, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants