Git Product home page Git Product logo

gxui's Introduction

GXUI - A Go cross platform UI library.

Join the chat at https://gitter.im/google/gxui Build Status GoDoc

Notice:

Unfortunately due to a shortage of hours in a day, GXUI is no longer maintained.

If you're looking for a GUI library for your next Go project, check out these alternatives.

Disclaimer

The code is mostly undocumented, and is certainly not idiomatic Go.

This is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google.

Dependencies

Linux:

In order to build GXUI on linux, you will need the following packages installed:

sudo apt-get install libxi-dev libxcursor-dev libxrandr-dev libxinerama-dev mesa-common-dev libgl1-mesa-dev libxxf86vm-dev

Common:

After setting up GOPATH (see Go documentation), you can then fetch the GXUI library and its dependencies:

go get -u github.com/google/gxui/...

Samples

Samples can be found in gxui/samples.

To build all samples run:

go install github.com/google/gxui/samples/...

And they will be built into GOPATH/bin.

If you add GOPATH/bin to your PATH, you can simply type the name of a sample to run it. For example: image_viewer.

Web

gxui code is cross platform and can be compiled using GopherJS to JavaScript, allowing it to run in browsers with WebGL support. To do so, you'll need the GopherJS compiler and some additional dependencies:

go get -u github.com/gopherjs/gopherjs
go get -u -d -tags=js github.com/google/gxui/...

Afterwards, you can try the samples by running gopherjs serve command and opening http://localhost:8080/github.com/google/gxui/samples/ in a browser.

Fonts

Many of the samples require a font to render text. The dark theme (and currently the only theme) uses Roboto. This is built into the gxfont package.

Make sure to mention this font in any notices file distributed with your application.

Contributing

GXUI was written by a couple of Googlers as an experiment and is now unmaintained.

Contributions, however small, will require the author to have signed the Google Individual Contributor License Agreement.

The CLA is necessary mainly because you own the copyright to your changes, even after your contribution becomes part of our codebase, so we need your permission to use and distribute your code. We also need to be sure of various other things—for instance that you'll tell us if you know that your code infringes on other people's patents. You don't have to sign the CLA until after you've submitted your code for review and a member has approved it, but you must do it before we can put your code into our codebase. Before you start working on a larger contribution, you should get in touch with us first through the issue tracker with your idea so that we can help out and possibly guide you. Coordinating up front makes it much easier to avoid frustration later on.

gxui's People

Contributors

abadojack avatar andrewseidl avatar ben-clayton avatar bfontaine avatar chai2010 avatar crawshaw avatar danmondy avatar dj2 avatar dmitshur avatar drahoslove avatar dskinner avatar hajimehoshi avatar mattn avatar pborreli avatar sbinet avatar shawnmilo avatar tones111 avatar yofu avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

gxui's Issues

unify font Draw and DrawRunes

I don't think the small allocation savings from supporting two code paths is worthwhile. It translates into a lot of API surface down the road.

But in trying to get rid of one, I discovered they work differently. LayoutRunes+DrawRunes produces different (seemingly incorrect) results compared to Draw. Is this on purpose, @ben-clayton? If not, I'll make LayoutRunes+DrawRunes behave like Draw now and remove Draw.

Clean up the code

There is lots of code that is not clean, and is certainly not a good example of idiomatic-go code.
This is a tracker for work in cleaning up the source.

panic: APIUnavailable: GLX: GLX version 1.3 is required [Ubuntu]

While running any of the sample application, I am getting below error

GLFW: An uncaught error has occurred: PlatformError: X11: RandR gamma ramp support seems broken
GLFW: Please report this bug in the Go package immediately.
panic: APIUnavailable: GLX: GLX version 1.3 is required

goroutine 1 [running, locked to thread]:
github.com/google/gxui/drivers/gl.StartDriver(0x90ced0)
        /home/anindya/codebase/gopath/src/github.com/google/gxui/drivers/gl/driver.go:36 +0x87
main.main()
        /home/anindya/codebase/gopath/src/github.com/google/gxui/samples/lists/main.go:150 +0x2f

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
        /home/anindya/Applications/go/src/runtime/asm_amd64.s:2232 +0x1

And here is the system details

Ubuntu 14.04.2 LTS - 64bit
OpenGL version string: 2.1 Mesa 10.1.3
go version go1.4.2 linux/amd64

Investigation: Font glyph rendering doesn't seem quite right.

I've spent a few days looking into what exactly I'm finding disagreeable, and I have a few theories starting from most likely to least:

  • By dropping the integer-pixel offsets, I've screwed up the hinting. I would have thought this would be simple to confirm by comparing glyphs I've rendered to glyphs produced by another application - I tried, and I couldn't really convince myself that this was the problem.
  • Gamma isn't quite right. I had a play trying to compensate the curve in the shader used to display the rasterized glyphs - nothing I tried made it look significantly better.
  • It's in my head. I've spent so long with my retina MBP looking at the lovely smooth fonts, that all other displays just look crap.

I will need to spend a bit more time investigating what isn't quite right here.

Rework control layout

Control.Layout is handed a math.Rect to position the control relative to the parent and set its scale. The position aspect of this is irrelevant - it's the responsibility of the parent Container to draw the control at the right offset, and there is no good need for the control to know where it is relative to the parent.

I propose:

I believe this will dramatically simplify the logic of most layouts, removing the filthy Bounds().Size() calls that are made at the top of nearly every layout function.

samples/image_viewer panic: open : no such file or directory

All other samples work great but image_viewer sample gives following error:

selection_061

panic: open : no such file or directory

goroutine 4 [running]:
runtime.panic(0x6a6ac0, 0xc21006b000)
    /usr/lib/go/src/pkg/runtime/panic.c:266 +0xb6
main.appMain(0x7f6bed85a280, 0xc210048060)
    /home/haisum/gxgui/src/github.com/google/gxui/samples/image_viewer/main.go:26 +0x89
created by github.com/google/gxui/drivers/gl.StartDriver
    /home/haisum/gxgui/src/github.com/google/gxui/drivers/gl/driver.go:46 +0x14e

goroutine 1 [runnable]:
github.com/go-gl/glfw/v3.1/glfw._Cfunc_glfwWaitEvents(0x48b94f)
    github.com/go-gl/glfw/v3.1/glfw/_obj/_cgo_defun.c:967 +0x31
github.com/go-gl/glfw/v3.1/glfw.WaitEvents()
    /home/haisum/gxgui/src/github.com/go-gl/glfw/v3.1/glfw/window.go:642 +0x1a
github.com/google/gxui/drivers/gl.(*Driver).run(0xc210048060)
    /home/haisum/gxgui/src/github.com/google/gxui/drivers/gl/driver.go:90 +0x6f
github.com/google/gxui/drivers/gl.StartDriver(0x7f4a98)
    /home/haisum/gxgui/src/github.com/google/gxui/drivers/gl/driver.go:47 +0x15e
main.main()
    /home/haisum/gxgui/src/github.com/google/gxui/samples/image_viewer/main.go:53 +0x2c

goroutine 3 [syscall]:
runtime.goexit()
    /usr/lib/go/src/pkg/runtime/proc.c:1394

panic: Cannot create a label with a nil font

I was able to succesfully build the progress_bar binary from the samples folder using the Dockerfile described in #7. However, when I run the binary on my machine I receive the following panic:

$ ./progress_bar 
Warning: Failed to load default font - Unable to find font 'Arial.ttf'
panic: Cannot create a label with a nil font

goroutine 5 [running]:
github.com/google/gxui/mixins.(*Label).Init(0xc20807e000, 0x7f9925c2cdd8, 0xc20807e000, 0x7f9925c2cd20, 0xc20807c000, 0x0, 0x0, 0x3f4ccccd3f4ccccd, 0x3f8000003f4ccccd)
    /go/src/github.com/google/gxui/mixins/label.go:32 +0x6f
github.com/google/gxui/themes/dark.CreateLabel(0xc20807c000, 0x0, 0x0)
    /go/src/github.com/google/gxui/themes/dark/label.go:15 +0x141
github.com/google/gxui/themes/dark.(*Theme).CreateLabel(0xc20807c000, 0x0, 0x0)
    /go/src/github.com/google/gxui/themes/dark/theme.go:130 +0x3a
main.appMain(0x7f9925c2cc40, 0xc20803a3c0)
    /go/src/github.com/google/gxui/samples/progress_bar/main.go:22 +0x85
created by github.com/google/gxui/drivers/gl.StartDriver
    /go/src/github.com/google/gxui/drivers/gl/driver.go:52 +0x20a

goroutine 1 [runnable, locked to thread]:
github.com/go-gl/glfw/v3.1/glfw._Cfunc_glfwWaitEvents()
    /go/src/github.com/go-gl/glfw/v3.1/glfw/:874 +0x45
github.com/go-gl/glfw/v3.1/glfw.WaitEvents()
    /go/src/github.com/go-gl/glfw/v3.1/glfw/window.go:642 +0x1b
github.com/google/gxui/drivers/gl.(*Driver).run(0xc20803a3c0)
    /go/src/github.com/google/gxui/drivers/gl/driver.go:95 +0x81
github.com/google/gxui/drivers/gl.StartDriver(0x0, 0x0, 0x9077a0)
    /go/src/github.com/google/gxui/drivers/gl/driver.go:53 +0x21a
main.main()
    /go/src/github.com/google/gxui/samples/progress_bar/main.go:54 +0x48

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/src/go/src/runtime/asm_amd64.s:2232 +0x1

Errors running `go get`

I'm having issues running go get on Yosemite:

$ brew list glew
/opt/boxen/homebrew/Cellar/glew/1.11.0/bin/glewinfo
/opt/boxen/homebrew/Cellar/glew/1.11.0/bin/visualinfo
/opt/boxen/homebrew/Cellar/glew/1.11.0/include/GL/ (3 files)
/opt/boxen/homebrew/Cellar/glew/1.11.0/lib/libGLEW.1.11.0.dylib
/opt/boxen/homebrew/Cellar/glew/1.11.0/lib/libGLEWmx.1.11.0.dylib
/opt/boxen/homebrew/Cellar/glew/1.11.0/lib/pkgconfig/ (2 files)
/opt/boxen/homebrew/Cellar/glew/1.11.0/lib/ (6 other files)
$  go get ./...
# github.com/go-gl-legacy/gl
In file included from ../../go-gl-legacy/gl/attriblocation.go:7:
./gl.h:2:10: fatal error: 'GL/glew.h' file not found
#include <GL/glew.h>
         ^
1 error generated.

Custom Graphical Elements?

With the available graphical elements all created via the theme interface it seems that applications wanting/needing to provide custom elements will be difficult. Is it possible for a client to design their own widget, add it to a layout, and have it rendered? I haven't yet wrapped my head around the mixin architecture enough to determine if a compliant object just needs to meet a set of interfaces. If it's possible, this might make for a good, simple example.

Sample applications just keep black screen - Ubuntu 14.04

Hi there,

I built all samples successfully, but when running them it's just a black screen, like this:
image

I run it on Ubuntu 14.04, and:
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) 945GM x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 10.3.2
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 10.3.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
OpenGL ES profile extensions:

windows minimize panic.

run the samples, when minimize the windows, then panic.

panic: Canvas width and height must be positive. Size: {0 0}

drop down list is blank/empty

It could be that I'm not using it correctly, but if I modify the list sample to create a drop down list in place of the existing list (and comment out the call to SetOrientation) it doesn't render the list. I see an empty box in place of the list but clicking on it doesn't show the list of items from the adapter.

Could you add an example of a drop down list to the lists sample please?

windows: panic when using race detector

Similar to #70, but happens immediately instead of on first event under race detection. It may just be that an event is fired by windows on window open.

Panic output on polygon sample:

Exception 0xc0000005 0x0 0x0 0x40b137
PC=0x40b137
signal arrived during cgo execution

github.com/go-gl/glfw/v3.1/glfw._Cfunc_glfwWaitEvents()
        ??:0 +0x63
github.com/go-gl/glfw/v3.1/glfw.WaitEvents()
        P:/go/src/github.com/go-gl/glfw/v3.1/glfw/window.go:642 +0x34
github.com/google/gxui/drivers/gl.(*driver).run(0xc0820046e0)
        P:/go/src/github.com/google/gxui/drivers/gl/driver.go:88 +0xa9
github.com/google/gxui/drivers/gl.StartDriver(0x9e3208)
        P:/go/src/github.com/google/gxui/drivers/gl/driver.go:45 +0x309
main.main()
        P:/go/src/github.com/google/gxui/samples/polygon/main.go:83 +0x3f

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
        C:/go-tip/src/runtime/asm_amd64.s:2466 +0x1

goroutine 5 [chan receive]:
github.com/google/gxui.EventLoop(0x1834498, 0xc0820046e0)
        P:/go/src/github.com/google/gxui/event_loop.go:8 +0x7a
main.appMain(0x1834498, 0xc0820046e0)
        P:/go/src/github.com/google/gxui/samples/polygon/main.go:79 +0x661
created by github.com/google/gxui/drivers/gl.StartDriver
        P:/go/src/github.com/google/gxui/drivers/gl/driver.go:44 +0x2fb
rax     0x40b130
rbx     0x555e87
rcx     0x0
rdi     0x219072e
rsi     0x0
rbp     0x3016f90
rsp     0x23f820
r8      0x18
r9      0x1320000
r10     0x1540060
r11     0x206
r12     0x23f878
r13     0x1540180
r14     0x1540060
r15     0x23f930
rip     0x40b137
rflags  0x10202
cs      0x33
fs      0x53
gs      0x2b

feature request: Improved resize / placement support

I'm finding it difficult to mock up a ui that handles window resizing or allowing fill space between components. For example, there doesn't seem to be a mechanism to have some components at the top of the window, with a status bar across the bottom. Enabling the layout border to be drawn it can be seen that the layout size is not adapting to changes in the window size. Attempting to fill space with an invisible component (ex: a label with no text) and a large maximum desired size doesn't seem to absorb the extra space either.

darwin: panic during event loop under race detector

While discovering #69, I found that in a binary build for race detection, the program will crash upon processing the first event that fires (eg: mouse move).

For example, running the polygon demo and moving the mouse gives the following panic:

fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x0 pc=0x4005ade]

runtime stack:
runtime.throw(0x454aa10, 0x2a)
    $GOPATH/go/src/runtime/panic.go:543 +0xa0
runtime.sigpanic()
    $GOPATH/go/src/runtime/sigpanic_unix.go:12 +0x62

goroutine 1 [syscall, locked to thread]:
runtime.cgocall_errno(0x4034c90, 0xc208171ec0, 0x0)
    $GOPATH/go/src/runtime/cgocall.go:125 +0xd0 fp=0xc208171ea0 sp=0xc208171e78
github.com/go-gl/glfw/v3.1/glfw._Cfunc_glfwWaitEvents()
    ??:0 +0x5c fp=0xc208171ec0 sp=0xc208171ea0
github.com/go-gl/glfw/v3.1/glfw.WaitEvents()
    $GOPATH/src/github.com/go-gl/glfw/v3.1/glfw/window.go:642 +0x2d fp=0xc208171ed0 sp=0xc208171ec0
github.com/google/gxui/drivers/gl.(*driver).run(0xc20800e100)
    $GOPATH/src/github.com/google/gxui/drivers/gl/driver.go:88 +0xa2 fp=0xc208171f10 sp=0xc208171ed0
github.com/google/gxui/drivers/gl.StartDriver(0x45c3040)
    $GOPATH/src/github.com/google/gxui/drivers/gl/driver.go:45 +0x302 fp=0xc208171f88 sp=0xc208171f10
main.main()
    $GOPATH/src/github.com/google/gxui/samples/polygon/main.go:83 +0x38 fp=0xc208171f98 sp=0xc208171f88
runtime.main()
    $GOPATH/go/src/runtime/proc.go:88 +0x1cb fp=0xc208171fe0 sp=0xc208171f98
runtime.goexit()
    $GOPATH/go/src/runtime/asm_amd64.s:2466 +0x1 fp=0xc208171fe8 sp=0xc208171fe0

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    $GOPATH/go/src/runtime/asm_amd64.s:2466 +0x1

goroutine 5 [chan receive]:
github.com/google/gxui.EventLoop(0x5604740, 0xc20800e100)
    $GOPATH/src/github.com/google/gxui/event_loop.go:8 +0x73
main.appMain(0x5604740, 0xc20800e100)
    $GOPATH/src/github.com/google/gxui/samples/polygon/main.go:79 +0x65a
created by github.com/google/gxui/drivers/gl.StartDriver
    $GOPATH/src/github.com/google/gxui/drivers/gl/driver.go:44 +0x2f4

All rights reserved

Copyright (c) 2015 The Go Authors. All rights reserved.

Which means that nobody can't do anything to this without your explicit permission....

You should really go with a GPL or BSD style license if you want anyone to use this library. That would also remove the need for a CLA.

example: progress_bar crashed by occasionally under OS X

os: OS X 10.10
go version: go1.4.2 darwin/amd64

when the example: progress_bar is running, click the close button, it's crashed by occasionally with output as follows:

➜ progress_bar git:(master) go run main.go
panic: Attempting to render a destroyed Viewport

goroutine 1 [running, locked to thread]:
github.com/google/gxui/drivers/gl.(_Viewport).render(0xc20819e000)
/Users/liu/Sources/go/the3rd/src/github.com/google/gxui/drivers/gl/viewport.go:244 +0x86
github.com/google/gxui/drivers/gl.func·044()
/Users/liu/Sources/go/the3rd/src/github.com/google/gxui/drivers/gl/viewport.go:308 +0xae
github.com/google/gxui/drivers/gl.(_Driver).flush(0xc20801e040)
/Users/liu/Sources/go/the3rd/src/github.com/google/gxui/drivers/gl/driver.go:73 +0x5e
github.com/google/gxui/drivers/gl.func·013()
/Users/liu/Sources/go/the3rd/src/github.com/google/gxui/drivers/gl/driver.go:113 +0xcc
github.com/google/gxui/drivers/gl.(*Driver).run(0xc20801e040)
/Users/liu/Sources/go/the3rd/src/github.com/google/gxui/drivers/gl/driver.go:85 +0x75
github.com/google/gxui/drivers/gl.StartDriver(0x44dee00)
/Users/liu/Sources/go/the3rd/src/github.com/google/gxui/drivers/gl/driver.go:47 +0x1e5
main.main()
/Users/liu/Sources/go/the3rd/src/github.com/lewgun/gxui/samples/progress_bar/main.go:50 +0x2a

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:2232 +0x1

goroutine 5 [chan receive]:
github.com/google/gxui.EventLoop(0x47b4cc8, 0xc20801e040)
/Users/liu/Sources/go/the3rd/src/github.com/google/gxui/event_loop.go:8 +0x65
main.appMain(0x47b4cc8, 0xc20801e040)
/Users/liu/Sources/go/the3rd/src/github.com/lewgun/gxui/samples/progress_bar/main.go:46 +0x568
created by github.com/google/gxui/drivers/gl.StartDriver
/Users/liu/Sources/go/the3rd/src/github.com/google/gxui/drivers/gl/driver.go:46 +0x1d5
exit status 2

Ubuntu 14.10 missing include files errors in go get github.com/go-gl/gl/v3.2-core/gl

While doing go get github.com/go-gl/gl/v3.2-core/gl on Ubuntu I got error of missing GL/glx.h header file. After fixing include error, I got following error:

/usr/bin/ld: cannot find -lGL
/usr/bin/ld: cannot find -lGL
collect2: error: ld returned 1 exit status

selection_056

Fixed both errors by doing sudo apt-get install mesa-common-dev libgl1-mesa-dev.

Hope it helps someone else and documentation should be updated.

Material design

Are there any plans to have a material design theme? Maybe it also should be the default theme because right now the components are not touchscreen friendly and making a modern looking UI is not so easy.
It's also good to see whats missing in gxui to support the material design spec.

list item reuse?

I tried giving the code a quick look over, specifically mixings/list.go and it looks like item controls are recreated during scroll so that a list of 10,000 items of the same control would end up creating 10,000 unique controls over the course of scrolling while only keeping the visible ones in memory (so lots of garbage).

Did I read this right? Instead of simply deleting the old control tied to a given item id, it should be reused to reduce the amount of garbage. This also implies a create + bind phase for adapter implementations instead of just a create phase.

Along those same lines since this would change storage of controls by their view type instead of adapter id, it'd be nice if adapter item ids weren't required to be unique.

Thanks!

panic: send on closed channel

When running the progress_bar sample, everything works, but when closing the windows, this happens:

panic: send on closed channel

goroutine 422 [running]:
github.com/google/gxui/themes/dark.func·011()
    /home/alexander/go/src/github.com/google/gxui/themes/dark/progress_bar.go:31 +0xf1
created by time.goFunc
    /usr/lib/go/src/time/sleep.go:129 +0x4b

goroutine 1 [syscall, locked to thread]:
github.com/go-gl/glfw/v3.1/glfw._Cfunc_glfwTerminate()
    /home/alexander/go/src/github.com/go-gl/glfw/v3.1/glfw/:868 +0x45
github.com/go-gl/glfw/v3.1/glfw.Terminate()
    /home/alexander/go/src/github.com/go-gl/glfw/v3.1/glfw/glfw.go:48 +0x20
github.com/google/gxui/drivers/gl.StartDriver(0x8fbef8)
    /home/alexander/go/src/github.com/google/gxui/drivers/gl/driver.go:48 +0x1e6
main.main()
    /home/alexander/go/src/github.com/google/gxui/samples/progress_bar/main.go:50 +0x2a

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/lib/go/src/runtime/asm_amd64.s:2232 +0x1

Using latest commit on master (4c80f4e)
go version go1.4.2 linux/amd64
64-bit Arch Linux

Best regards,
Alexander F Rødseth

Continuous intergration

Are you planning adding continuous intergration into this project? Would be good...great to know when I'm breaking the build

feature request: notices widget

(low priority)

A program that includes open source software should be distributed with notices, describing the open source software that is bundled. For example: "chrome://credits". An application built with GXUI includes two notices from this repository, the first is the BSD licensed gxui package, the second is the Apache-licensed Roboto font in gxfont.

The gl driver has other copyright holders, but I haven't audited it.

An easy to embed menu widget that displays these would make it easy for people using gxui to include notices.

run and stop progress_bar,then panic!

C:\Projects\go\bin>progress_bar.exe
panic: Attempting to render a destroyed viewport

goroutine 1 [running, locked to thread]:
github.com/google/gxui/drivers/gl.(_viewport).render(0x12bb0000)
C:/projects/go/src/github.com/google/gxui/drivers/gl/viewport.go:251 +0x61
github.com/google/gxui/drivers/gl.func路045()
C:/projects/go/src/github.com/google/gxui/drivers/gl/viewport.go:306 +0xb2
github.com/google/gxui/drivers/gl.func路014()
C:/projects/go/src/github.com/google/gxui/drivers/gl/driver.go:145 +0x240
github.com/google/gxui/drivers/gl.(_driver).driverLoop(0x12a4a320)
C:/projects/go/src/github.com/google/gxui/drivers/gl/driver.go:82 +0x68
github.com/google/gxui/drivers/gl.StartDriver(0xb486f8)
C:/projects/go/src/github.com/google/gxui/drivers/gl/driver.go:51 +0x24d

main.main()
C:/projects/go/src/github.com/google/gxui/samples/progress_bar/main.go:50 +0x29

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
c:/go/src/runtime/asm_386.s:2287 +0x1

goroutine 5 [chan receive]:
github.com/google/gxui/drivers/gl.(*driver).applicationLoop(0x12a4a320)
C:/projects/go/src/github.com/google/gxui/drivers/gl/driver.go:99 +0x4b
created by github.com/google/gxui/drivers/gl.StartDriver
C:/projects/go/src/github.com/google/gxui/drivers/gl/driver.go:50 +0x23d

goroutine 7 [runnable]:
github.com/google/gxui/themes/dark.func路011()
C:/projects/go/src/github.com/google/gxui/themes/dark/progress_bar.go:34+0x75
created by github.com/google/gxui/themes/dark.func路012
C:/projects/go/src/github.com/google/gxui/themes/dark/progress_bar.go:39+0x103

No errors.

I built gxui on windows. It works fine without one thing. I must apply small patch to go-gl-legacy.

https://gist.github.com/mattn/827bc949adf45e9e4df5

There seems to be some versions which returns No errors. from glGetProgramInfoLog/glGetShaderInfoLog.
So I suggues that ignore No errors. at below:

if err != "" {

if err != "" {

If you are okay, I'll send PR to you.

additional comment
Or remove checking

missing data/xyz.ttf resources

hi,

trying to run the samples apps, I get:

$ go run ./progress_bar/main.go 
panic: open data/SourceCodePro-Regular.ttf: no such file or directory

goroutine 5 [running]:
github.com/google/gxui/drivers/gl.(*Driver).CreateFont(0xc20803a3c0, 0x75a1d0, 0x19, 0xc, 0x0, 0x0)
    /home/binet/tmp/go/src/github.com/google/gxui/drivers/gl/driver.go:166 +0x17d
github.com/google/gxui/themes/dark.CreateTheme(0x7f14ee8b2b40, 0xc20803a3c0, 0x0, 0x0)
    /home/binet/tmp/go/src/github.com/google/gxui/themes/dark/theme.go:43 +0x76
main.appMain(0x7f14ee8b2b40, 0xc20803a3c0)
    /home/binet/tmp/go/src/github.com/google/gxui/samples/progress_bar/main.go:19 +0x61
created by github.com/google/gxui/drivers/gl.StartDriver
    /home/binet/tmp/go/src/github.com/google/gxui/drivers/gl/driver.go:50 +0x20a

goroutine 1 [runnable, locked to thread]:
github.com/go-gl/glfw/v3.1/glfw.WaitEvents()
    /home/binet/tmp/go/src/github.com/go-gl/glfw/v3.1/glfw/window.go:641
github.com/google/gxui/drivers/gl.(*Driver).run(0xc20803a3c0)
    /home/binet/tmp/go/src/github.com/google/gxui/drivers/gl/driver.go:93 +0x81
github.com/google/gxui/drivers/gl.StartDriver(0x725070, 0x4, 0x7b2920)
    /home/binet/tmp/go/src/github.com/google/gxui/drivers/gl/driver.go:51 +0x21a
main.main()
    /home/binet/tmp/go/src/github.com/google/gxui/samples/progress_bar/main.go:52 +0x48

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/lib/go/src/runtime/asm_amd64.s:2232 +0x1
exit status 2

could these files (or a recipe to get them) be included?

-s

Gitter

Can we create a gitter room? Would be fantastic for more general chat rather than raising issues all the time

https://gitter.im

Panics on integrated graphics card.

When running on a machine with an integrated graphics card, I get the following panic.

I don't intend to install nvidia graphics yet, I was hoping to be able to run it on the intel integrated card.

Xlib:  extension "GLX" missing on display ":0".
Xlib:  extension "GLX" missing on display ":0".
panic: APIUnavailable: GLX: GLX extension not found

goroutine 1 [running, locked to thread]:
github.com/google/gxui/drivers/gl.StartDriver(0x0, 0x0, 0x90cf10)
    /home/jakob/tmp/src/github.com/google/gxui/drivers/gl/driver.go:41 +0x87
main.main()
    /home/jakob/tmp/src/github.com/google/gxui/samples/lists/main.go:152 +0x48

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/lib/go/src/runtime/asm_amd64.s:2232 +0x1

Dockerfile request

Regarding the compile issues described in issue #2:

If someone is able to get an environment set up that enables them to build the project, and is feeling generous, please create a Dockerfile that builds it, perhaps using the official "golang" Docker image as the base.

This would allow more people to contribute to the project, especially those who have trouble dealing with the dependencies, or simply don't want to add the various dependencies to their own machines.

arm-linux-androideabi-gcc: error: unrecognized command line option '-m64'

oldfeel@oldfeel:~$ go get github.com/go-gl/gl/v3.2-core/gl
# github.com/go-gl/gl/v3.2-core/gl
arm-linux-androideabi-gcc: error: unrecognized command line option '-m64'
oldfeel@oldfeel:~$ go get github.com/go-gl/glfw/v3.1/glfw
# github.com/go-gl/glfw/v3.1/glfw
arm-linux-androideabi-gcc: error: unrecognized command line option '-m64'

by ubuntu 14.04 64

Allow loading default system font

I have no opinion on where this would be exposed but usage would most likely be confined to themes. This would assist a theme attempting to maintain a uniform look across unrelated toolkits with similarly styled themes on a given system.

Incorrect tree searching with collapsed nodes

It appears the tree node search algorithm doesn't work when attempting to search down a collapsed node.

To reproduce:
Add a fmt.Println statement in samples/file_dlg/main.go immediately before the directories.Show(path) line in the enter key handler.
build and run the file_dlg sample application
find a collapsed node and edit the fullpath text box to that path plus some additional directory name that doesn't exist (ex: /home/username/junk)
Notice that the printout is displayed, indicating that directories.Select returned true

This contradicts the tree.go Select documentation in two ways:

  1. Select is supposed to return false when the tree does not contain the specified item
  2. The tree's appearance is modified during the Select with the collapsed directory now expanded.

Note that entering an invalid path from an expanded node appears to work correctly (no print out and the tree's appearance is unchanged).

x/mobile driver

It's not clear that GXUI will ever be ideal for mobile devices, but it's worth an experiment.

Run sample error on windows

$ go run main.go
panic: Failed to initialize gl: glGetBufferParameteri64v

goroutine 1 [running, locked to thread]:
github.com/google/gxui/drivers/gl.CreateViewport(0xc08200a380, 0x320, 0x258, 0x7
537d0, 0x5, 0xc082023e88)
C:/Go/src/github.com/google/gxui/drivers/gl/viewport.go:68 +0x2ab
github.com/google/gxui/drivers/gl.func路016()
C:/Go/src/github.com/google/gxui/drivers/gl/driver.go:142 +0x68
github.com/google/gxui/drivers/gl.func路011()
C:/Go/src/github.com/google/gxui/drivers/gl/driver.go:57 +0x36
github.com/google/gxui/drivers/gl.(*Driver).run(0xc08200a380)
C:/Go/src/github.com/google/gxui/drivers/gl/driver.go:85 +0x7c
github.com/google/gxui/drivers/gl.StartDriver(0x8fc090)
C:/Go/src/github.com/google/gxui/drivers/gl/driver.go:47 +0x1ec
main.main()
E:/golang/app/UI/main.go:164 +0x31

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
c:/go/src/runtime/asm_amd64.s:2232 +0x1

goroutine 5 [chan receive]:
github.com/google/gxui/drivers/gl.(_Driver).syncDriver(0xc08200a380, 0xc08218cd2
0)
C:/Go/src/github.com/google/gxui/drivers/gl/driver.go:58 +0x137
github.com/google/gxui/drivers/gl.(_Driver).CreateViewport(0xc08200a380, 0x320,
0x258, 0x7537d0, 0x5, 0x0, 0x0)
C:/Go/src/github.com/google/gxui/drivers/gl/driver.go:147 +0x1e1
github.com/google/gxui/mixins.(_Window).Init(0xc08201b8c0, 0x3694f0, 0xc08201b8c
0, 0x361fd8, 0xc08200a380, 0x320, 0x258, 0x7537d0, 0x5)
C:/Go/src/github.com/google/gxui/mixins/window.go:71 +0x326
github.com/google/gxui/themes/dark.CreateWindow(0xc08219e000, 0x320, 0x258, 0x75
37d0, 0x5, 0x0, 0x0)
C:/Go/src/github.com/google/gxui/themes/dark/window.go:19 +0x119
github.com/google/gxui/themes/dark.(_Theme).CreateWindow(0xc08219e000, 0x320, 0x
258, 0x7537d0, 0x5, 0x0, 0x0)
C:/Go/src/github.com/google/gxui/themes/dark/theme.go:169 +0x69
main.appMain(0x361fd8, 0xc08200a380)
E:/golang/app/UI/main.go:155 +0x1de
created by github.com/google/gxui/drivers/gl.StartDriver
C:/Go/src/github.com/google/gxui/drivers/gl/driver.go:46 +0x1dc
exit status 2

Error Building `image_viewer` Sample

Executing command go build main.go in image_viewer folder on Windows 8, go 1.4.2 x86 gives this error:

C:...\image_viewer>go build main.go
....\drivers\gl\glyph_page.go:13:2: cannot find package "code.google.com/p/freetype-go/freetype/raster" in any of:
C:\devox-apps\go\src\code.google.com\p\freetype-go\freetype\raster (from $GOROOT)
C:\Workshop\Devox\Workshop-Go\src\code.google.com\p\freetype-go\freetype\raster (from $GOPATH)
....\drivers\gl\font.go:14:2: cannot find package "code.google.com/p/freetype-go/freetype/truetype" in any of:
C:\devox-apps\go\src\code.google.com\p\freetype-go\freetype\truetype (from $GOROOT)
C:\Workshop\Devox\Workshop-Go\src\code.google.com\p\freetype-go\freetype\truetype (from $GOPATH)
....\drivers\gl\blitter.go:11:2: cannot find package "github.com/go-gl/gl/v3.2-core/gl" in any of:
C:\devox-apps\go\src\github.com\go-gl\gl\v3.2-core\gl (from $GOROOT)
C:\Workshop\Devox\Workshop-Go\src\github.com\go-gl\gl\v3.2-core\gl (from $GOPATH)
....\drivers\gl\driver.go:15:2: cannot find package "github.com/go-gl/glfw/v3.1/glfw" in any of:
C:\devox-apps\go\src\github.com\go-gl\glfw\v3.1\glfw (from $GOROOT)
C:\Workshop\Devox\Workshop-Go\src\github.com\go-gl\glfw\v3.1\glfw (from$GOPATH)

AdapterItemIds are too complicated.

In writing the samples, I've come to realise that the AdapterItemIds are really complicated, and make writing adapters really difficult.
The worst offender is the TreeAdapterNode - the contact for all Adapters is that a AdapterItemId needs to be unique for every item in the data set. Creating a unique integer for any data is hard, keeping it deterministic is really hard.

For context - the point of the AdapterItemId is so that the List or Tree knows when a Control needs to be rebuilt as the data is mutated - i.e. insertion of a new control shouldn't mean all other controls need to be rebuilt. It is also a requirement if we were to do sliding animations when things are inserted or removed, so we can associate what's on screen before the mutation and after the mutation.

I've thought about the problem a bit, and decided that actually AdapterItemIds should be replaced with AdapterItems - these are user data types (interface{}) that have equality testing. This simplifies usage heavily. For example:

  • Instead of List.Selected returning the AdapterItemId, it instead returns the actual AdapterItem data. Yay, no more looking up in the adapter.
  • If you have duplicates value types in your dataset (lets say strings) simply use a pointer as your AdapterItem. You can then guarantee it's unique.

I've pushed the rm_itemids branch that tries out this idea. It needs a little more polish before being ready.

Support wider set of platforms. Mobile? Web?

First off, thank you for creating this incredible Go library! I've recently discovered it and I'm a huge fan! I really like the approach of using OpenGL for platform-independent, high performance UI rendering, since it allows one to stay general and not to be constrained by each platform's UI toolkits. I've experimented with OpenGL UIs here.

Introduction

Now, the description of this project says:

GXUI - A Go cross platform UI library.

Currently, it is cross platform in that it will run and look/behave the same on OS X, Linux and Windows. However, with relatively little work, it seems it could be expanded to support more platforms: mobile and perhaps even web.

First, let me be a little imprecise and describe OpenGL APIs in this way:

  • OpenGL 3.2 Core - "Largest" OpenGL API available. Available on most desktop platforms (OS X, Linux, Windows).
  • OpenGL ES 2.0 - Roughly speaking, a subset of OpenGL API (with minor deviations). Available on most mobile platforms (iOS, Android).
  • WebGL 1.0 - Roughly speaking, a subset of OpenGL ES 2.0 (with minor deviations). Available in all major browsers (Chrome, Safari, Firefox, Opera, IE).

OpenGL 3.2 Core API is currently used in gxui [1]. But with a few changes (outlined in considerations section), it's possible to reduce what it used so that it can mapped to WebGL API.

I wanted to see what it would take to get gxui to run in browsers (and see how it'd perform), so I made a quick little prototype tonight in just a few hours. Some screenshots:

1

2

3

Demo

Here's a demo you can try in your browser (no gzip compression on served assets, sorry):

http://dmitri.shuralyov.com/projects/gxui-tree/index.html

Approaches

There are two different approaches to supporting additional platforms that I can see.

First approach is to create additional drivers, similar to the existing gl one. This seems to be suggested in related issue #45.

Another approach, which is the one I've used so far, is a little different.

Since the three OpenGL APIs are similar enough, it's possible to create a Go package that has a single OpenGL-like API, but using build tags, it can have three different backend implementations depending on what is available on the given platform:

  • OpenGL 2.1 or 3.2 Core, etc., backend on desktops.
  • OpenGL ES backend on mobile devices.
  • WebGL backend in browser.

The github.com/shurcooL/gogl package used in my quick prototype is an example of that. It only has OpenGL 2.1 and WebGL backend implementations (incomplete), but adding OpenGL ES one would be trivial since it's a superset of WebGL. It's a WIP package with unpolished API, but I think the general approach is solid and can be turned into a production ready package.

Considerations

Here are some implementation details of the changes I needed to do to make gxui samples run in the browser.

  1. glPolygonMode is not available in WebGL (since its implementation is very inefficient; a shame because it's useful for debugging). I commented it out since it was just a debugging feature.

  2. Index buffers with uint32 types were used. It seems my WebGL implementation (latest stable Chrome on OS X) did not support that type, so I dropped it down to uint16 which worked well.

  3. My WebGL implementation seemed not to support gl.UniformMatrix3fv calls with transpose equal to true, so I had to transpose the matrix before calling the gl func. I'm guessing the WebGL implementation opts to support fewer choices for performance reasons. It'd be better to avoid needless conversions between one format to the other when rendering.

  4. WebGL fragment shaders require precision to be set, so I added this to all fragment shaders to allow them to compile under all OpenGL/WebGL versions:

    #ifdef GL_ES
        precision lowp float;
    #endif
  5. Previous commits read the font directly from disk via ioutil.ReadFile. This can't work on all other platforms, so it's better to read from a virtual filesystem and each platform can provide that. It's no longer a problem since latest version embeds the font in code.

  6. My existing gogl package happens to use a higher level-style API (similar to x/mobile/gl) with types like *Texture instead of uint32, and it favors using int over int32 or uint32 the way the low-level C-style github.com/go-gl/gl/... packages do. This is a design decision that is orthogonal to all other API changes, but it required me to make some changes like:

    -framebuffer uint32
    -texture     uint32
    +framebuffer *gogl.Framebuffer
    +texture     *gogl.Texture
    -gl.DeleteFramebuffers(1, &f.framebuffer)
    -gl.DeleteTextures(1, &f.texture)
    -f.framebuffer = 0
    -f.texture = 0
    +gl.DeleteFramebuffer(f.framebuffer)
    +gl.DeleteTexture(f.texture)
    +f.framebuffer = nil
    +f.texture = nil
    -gl.Viewport(0, 0, int32(fw), int32(fh))
    -gl.Scissor(0, 0, int32(fw), int32(fh))
    +gl.Viewport(0, 0, fw, fh)
    +gl.Scissor(0, 0, fw, fh)
  7. Consts like gl.TRIANGLE_STRIP are not const on all platforms. For example, to get that value in a browser, you either need to create a WebGLContext first (which can't be done at const-time), or just hardcode the const value from spec. I went with the latter for now.

You can see the entire code change I made at 4699400. Keep in mind it's a quick prototype to test what it would take, and not a fully finished and polished version.

The performance of the web version (with Go compiled to JavaScript via GopherJS) is not as good as the desktop version with native Go. I am seeing around 20 fps. This is the result I got after doing the minimum work required to get samples to run without any profiling or optimizations. I am sure the performance can be improved if time is spent on it.

Conclusion

With just a few changes (do not use transpose true, use uint16 type for index buffers, etc.) it is possible to avoid using OpenGL-only features that are not available in OpenGL ES and WebGL. Doing that seems like a good idea as it enables gxui to be more cross platform.

This issue is to demonstrate what I've created. I'd love to hear feedback and thoughts. If you are interested, I'd love to help out with adding support for mobile and/or web and taking this prototype further.


[1] The imported package is v3.2-core/gl, so that's the API used, but since context version glfw hints are not set, it creates an OpenGL 2.1 context. Add this snippet after gl.Init() call to confirm:

{
    var samples int32
    gl.GetIntegerv(gl.SAMPLES, &samples)
    fmt.Printf("OpenGL %s %s %s; %s; %v samples.\n", gl.GoStr(gl.GetString(gl.VENDOR)), gl.GoStr(gl.GetString(gl.RENDERER)), gl.GoStr(gl.GetString(gl.VERSION)),
        gl.GoStr(gl.GetString(gl.SHADING_LANGUAGE_VERSION)), samples)
}

On my Mac, I got OpenGL ATI Technologies Inc. AMD Radeon HD 6770M OpenGL Engine 2.1 ATI-1.30.5; 1.20; 4 samples.. OpenGL 2.1.

Ubuntu 14.10 missing include files errors in go get github.com/go-gl/glfw/v3.1/glfw

After finally getting go get github.com/go-gl/gl/v3.2-core/gl to work and solve issues mentioned in #39 go get github.com/go-gl/glfw/v3.1/glfw also popped up a few errors of missing following include files:

  • X11/extensions/Xinerama.h
  • X11/extensions/XInput2.h
  • X11/Xcursor/Xcursor.h
  • X11/extensions/Xrandr.h

These include files are available in packages libxi-dev libxcursor-dev libxrandr-dev libxinerama-dev so installing them by doing sudo apt-get install libxi-dev libxcursor-dev libxrandr-dev libxinerama-dev fixed the errors. Updated documentation is needed.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.