Andrew Gallant (Ocelot) 6bdfd1d1b1 A more idiomatic way of trying a non-blocking send on a buffered channel
and falling back to a blocking send inside a goroutine.

This really needs to be fixed. The situation only arises when events are
sent and aren't pulled off the channel using {Wait,Poll}ForEvent.
Namely, if the event send blocks, the entire program will deadlock.

Using a goroutine is not ideal because we lose a guarantee of order:
that events are processed in the order of their arrival. However, it
seems OK as a temporary band-aide for a situation that probably doesn't
arise too often.

What I need to do is implement a dynamic queue. Here is a reference
implementation: http://play.golang.org/p/AiHBsxTFpj
2012-05-12 21:55:57 -04:00
..
2012-05-12 21:36:31 -04:00
2012-05-12 21:36:31 -04:00
2012-05-11 02:01:29 -04:00
2012-05-12 21:36:31 -04:00
2012-05-11 02:01:29 -04:00
2012-05-12 21:36:31 -04:00

XGB is the X Go Binding, which is a low-level API to communicate with the
core X protocol and many of the X extensions. It is closely modeled after
XCB and xpyb.

It is thread safe and gets immediate improvement from parallelism when
GOMAXPROCS > 1. (See the benchmarks in xgb_test.go for evidence.)

Please see doc.go for more info.

Note that unless you know you need XGB, you can probably make your life
easier by using a slightly higher level library: xgbutil.

Quick Usage
===========
go get github.com/BurntSushi/xgb
go run go/path/src/github.com/BurntSushi/xgb/examples/create-window/main.go

BurntSushi's Fork
=================
I've forked the XGB repository from Google Code due to inactivty upstream.

Godoc documentation can be found here:
http://godoc.burntsushi.net/pkg/github.com/BurntSushi/xgb/

Much of the code has been rewritten in an effort to support thread safety
and multiple extensions. Namely, go_client.py has been thrown away in favor
of an xgbgen package.

The biggest parts that *haven't* been rewritten by me are the connection and
authentication handshakes. They're inherently messy, and there's really no
reason to re-work them. The rest of XGB has been completely rewritten.

I like to release my code under the WTFPL, but since I'm starting with someone
else's work, I'm leaving the original license/contributor/author information
in tact.

I suppose I can legitimately release xgbgen under the WTFPL. To be fair, it is
at least as complex as XGB itself. *sigh*

What follows is the original README:

XGB README
==========
XGB is the X protocol Go language Binding.

It is the Go equivalent of XCB, the X protocol C-language Binding
(http://xcb.freedesktop.org/).

Unless otherwise noted, the XGB source files are distributed
under the BSD-style license found in the LICENSE file.

Contributions should follow the same procedure as for the Go project:
http://golang.org/doc/contribute.html