AUTHORS, CONTRIBUTORS: still useful, add people from git log, clean up.
LICENSE: Google doesn't really grant you shit anymore. The EU doesn't
have software patents either, so it doesn't affect me directly.
README, doc.go: erase mentions of unmaintained xgbutil.
* Added minimal support for switch fields.
* Changed the way Size is calculated to accomodate for lists inside structs
(added to randr)
* Removed heuristic to place alignment gaps, they are now explicitly
described in xml
Some field values in the Xauthority file have special meanings:
- a value of 65535 in the 'family' field means that the entry will
match a connection of any family on any address
- an empty string in the 'display number' field means that the entry
will match a connection on any display number
This behaviour is documented at:
https://cgit.freedesktop.org/xorg/lib/libXau/tree/AuGetBest.c#n109
NewRequest says you can avoid reallocating a new buffer for each request by calling it directly.
This is not true if req.seq is closed before req.buf is read.
Fixes#9.
This makes shutdown a little more graceful, but there's more
work to be done here. Namely, all outstanding cookies need to
be given the error, otherwise they will block forever.
Just enabling or disabling logging falls short of the power of
interfaces of go. A user is forced to either accept the logging to
stderr in the format defined by xgb or disable logging alltogether. By
exporting the logger, we can actually let the user decide where to log
in what format.
goofing here.
What I'd personally like to do is just use an "infinite" channel. That
is, push the limit of how many events can be processed to the machine
and not set an artificial limit in XGB. Some day...
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
Přemysl Eric Janouch
aarzilli
Rabin Vincent
Andrew Gallant
Bryan Matsuo
fangyuanziti
snyh
Axel Wagner
Andrew Gallant (Ocelot)
Paul Sbarra