shyrobbiani / x-go-binding Goto Github PK

What steps will reproduce the problem?
1. Clone the source
2. Ensure the Go tree is fully updated
3. run 'make' in the source directory

What is the expected output? What do you see instead?
expected: build completes successfully
actual: build fails with 'Makefile:5: /home/sp/injections/go/src/Make.amd64: No 
such file or directory'

What version of the product are you using? On what operating system?
Git revision 41a04f6ccbac83590d96d4ddf0761f5eef761f99; Gentoo Linux amd64

Please provide any additional information below.
According to http://golang.org/doc/devel/release.html, as of 2010-09-06, 
Make.amd64, Make.386, and Make.arm have been deleted and replaced by Make.inc; 
to fix, simply replace "include $(GOROOT)/src/Make.$(GOARCH)"  on line 5 of the 
Makefile with "include $(GOROOT)/src/Make.inc"

Currently it accepts raw X11 protocol data as []byte slice.

What steps will reproduce the problem?
Use ChangeProperty e.g. with 32 bit format

What is the expected output? What do you see instead?
expected: sets property correctly.
observed: dumps core

What version of the product are you using? On what operating system?
linux, revision 7

Please provide any additional information below.
The attached patch fixes the issue.

I see several tickets open (some from 2 years ago) with seemingly no input from 
the maintainers of this project. The last 2 years of commits appear mostly to 
be maintenance with respect to tracking upstream golang changes.

So, like, is anyone actively maintaining this? If not, I'm content to fork it 
and move on. Let me know :)

I've attached a patch that will provide support for the xinerama extension.

The xinerama.go file is automatically generated using 'python2 go_client.py 
/usr/share/xcb/xinerama.xml'.

My approach was actually to make extensions, in general, work. However, that 
task was a bit harder than I thought it would be. I tried generating the randr 
and render extension files, but they failed miserably. I don't think I'll 
attempt that again until go_client.py is cleaned up (which I may do). 
Personally, I think we should look at c_client.py for XCB and try to model it 
after that. In particular, generating extensions introduces a host of new 
problems---with type definitions missing, unions missing (yuck), and functions 
like 'parseEvent' being re-declared. It needs a lot of work.

At least with Xinerama, xgb can be aware of multiple monitors. Which is 
important. (Because I have three monitors :P)

In order to use it...

    conn, _ := xgb.Dial("")
    conn.RegisterExtension("xinerama")
    screens, _ := conn.XineramaQueryScreens()
    fmt.Println(screens)

N.B. I've also removed those god-forsaken tabs from go_client.py and run 
xproto.go and xinerama.go through gofmt.

What steps will reproduce the problem?
1. Run nested X server.
2. Write simple application that just connect to server.
3. Compile and run it.

What is the expected output? What do you see instead?
Dial functions returns EOF error. 

What version of the product are you using? On what operating system?
Go weekly.2011-12-06
x-go-binding 37c5ad0262b6 tip
x86_64 GNU/Linux

Please provide any additional information below.
The EOF error occurs during reading .Xauthority file, in readAuthority(c.host, 
c.display) call.

I think one desirable characteristic of XGB is thread safety. It allows for 
truly parallel tasks that both perform X actions.

One example use is in my window manager. When I manage a new client, there are 
a few images that need to be converted to pixmaps. It's an ideal task to 
background. With thread safety in XGB, I can now do something like this and be 
reasonably confident things will be ok:

  manage(client) {
    go func() {
      // generate some images; they may be large!
    }

    // do non-cpu intensive stuff to manage client
  }

Obviously, there are tons of other places where this might be useful---but I 
think stuff related to image manipulation/painting are the most likely 
candidates.

My approach to thread safety was to encapsulate replies in goroutines. This 
seemed like the most obvious approach (to one who is inexperienced with 
goroutines and channel usage), but incurs the overhead of channels and 
goroutines every time a request requires a reply. However, I've been told that 
goroutines are quite cheap :-)

I haven't done much testing yet, but it has survived some non-trivial stress 
testing with my window manager.

I'm still not completely happy with everything, but comments and criticisms are 
welcome.

My threadsafe branch is here: 
http://code.google.com/r/jamslam-x-go-binding/source/browse/?name=threadsafe#hg%
2Fxgb

What steps will reproduce the problem?
1. Select any event.
2. Use SendEvent to generate the event from another client.

What is the expected output? What do you see instead?
Expected: the event is properly recognized and flagged as originating from
a SendEvent request.
Observed: the event is not recognized

What version of the product are you using? On what operating system?
revision 7 on linux

Please provide any additional information below.
the attached patch is a quick fix for the problem. However, a mechanism to
flag the event as originating from a SendEvent request remains to be added.

What steps will reproduce the problem?

Read 
http://groups.google.com/group/golang-nuts/browse_thread/thread/7c5689e1e2fe531d

What steps will reproduce the problem?
1. clone latest go trunk
2. clone latest x-go-binding trunk
3. try to build

What is the expected output? What do you see instead?
/home/user/bin/8g -o _go_.8 auth.go xgb.go xproto.go 
xgb.go:382: first argument to copy should be slice; have *[20]uint8
make: *** [_go_.8] Error 1

What version of the product are you using? On what operating system?
linux (ubuntu) i386
trunk of both (as of 9:15 AM EST Jun 9, 2010)

Please provide any additional information below.
didn't happen yesterday, so something in the last set of revisions borkd it

I was wondering if there was a planned road map for this project? Is it still 
alive?

At some point, I'd like to develop yet another window manager with Go (sounds 
like fun), and xgb will have to be its crux. If this project is dead, I'd be 
happy to maintain it.

Here are a few ideas that I have:

1) Find a way to combine sendRequest and sendBytes so that request lengths can 
be automatically computed. This simplifies weird exceptions like ChangeProperty 
requests in which the "data_len" field doesn't correspond to bytes. (But 
rather, format units.)

2) Add support for extensions. (Shape, Render, Damage, Composite, etc...)

3) Compute Xauth protocol information when a ~/.Xauthority file is not present. 
Right now, xgb dies. (Xlib and XCB do this, but it appears complex.)

4) go_client.py could probably use some cleaning up. Especially some PEP8 love.

5) xgb, unlike its siblings xpyb and xcb, does not allow for issuing multiple 
requests in one batch. Namely, in each protocol request function in xproto.go, 
the requests are wrapped in calls to 'waitForReply'. This forces each protocol 
request to block and wait for a reply. One of the key features of XCB is that 
you shouldn't have to do this. Although waiting and blocking for a reply is 
probably the most frequent use case, xgb currently disallows something like 
this completely:

    // Issue a bunch of requests, but don't ask for replies
    req[0] = InternAtom("Some atom...")
    req[1] = InternAtom("Some atom...")
    .
    .
    req[n] = InternAtom("Some atom...")

    // Now get the replies
    resp := make([]InternAtomReply, n)
    for i, r := range req {
        resp[i] = r.reply()
    }

Where some 'reply()' method would be defined on the InternAtomCookie type. 
(Where we would need a new Cookie type for each request. This is how xpyb does 
it.)

6) There are also several issues that need attention: 1, 2, 5 and 7.

Thanks!

Could the powers that be please declare this project as abandoned? I suggest 
that my fork at https://github.com/BurntSushi/xgb be recommended instead. It 
supports several extensions, has a more complete API, and is actively 
maintained. It has been used in at least two window managers. (Even the 
maintainer of x-go-binding is using it in his WM! 
https://code.google.com/p/taowm)

I only bring this up because people are still trying to use x-go-binding when 
there is really no good reason to.

Thanks