Does it depend on CGO? I think CGO dependency is the most annoying issue of existing GUI libraries in Go.
Two suggestions: how about adding some screenshots and a godoc link? On Saturday, August 27, 2016 at 11:04:27 PM UTC+8, howar...@gmail.com wrote: > > I mentioned this on the list a little while back in a discussion on Shiny, > and now it is finally up and available. > > https://github.com/TheGrum/renderview > > So... what is it? RenderView is a simple GUI wrapper that makes it easy to > wrap any image generation function and make it interactive. > > It is NOT a replacement for writing full graphical interfaces. This is not > for front-end developers, this is for the more general Go crowd, the people > writing back-end code, micro-services, web services, composable > applications and the like, who don't *want* to have to learn the > nitty-gritty of a particular graphical toolkit, but would like to be able > to have a rapid-turnaround way to test/view the graphical outputs of their > work. > > My own intention in writing this came after writing a tool to parse some > log files, and another to render them as visualizations saved as PNGs, > produced several gigabytes of data. I want to be able to peek into some of > my algorithms as they are running, to confirm their behavior is as desired, > not merely their final output, but I don't want to fill up my disks to do > it. > > I've included several examples of various levels, but basically, given a > function that produces an image.Image: > > func DrawSomething(bounds image.Rect, input1 int, input2 float64, input3 > etc) image.Image { > } > > RenderView asks you to provide a RenderModel that simply wraps this image > generation function, a bag of parameters, and your code for setting up > those parameters to feed into your drawing function, and it gives you a > graphical application with various interactive features. Which features you > get depends on what parameters you use, and which you pay attention to. If > using a backend that can produce editable widgets (at the moment, this is > only go-gtk), you can add arbitrary additional parameters to be exposed to > the user for editing. > > The Maze example provides an illustration of how simple it can be. Aside > from the functions to generate, and to draw the maze, both of which are > ordinary Go code, the added work is this: > > func main() { > sig := "" > rand.Seed(time.Now().UnixNano()) > m := rv.NewBasicRenderModel() > m.AddParameters( > rv.SetHints(rv.HINT_HIDE, > rv.NewIntRP("width", 0), > rv.NewIntRP("height", 0), > )...) > m.AddParameters( > rv.NewIntRP("page", 0), > rv.NewIntRP("linewidth", 1), > rv.NewIntRP("cellwidth", 5), > rv.NewIntRP("mazewidth", 100), > rv.NewIntRP("mazeheight", 100)) > m.InnerRender = func() { > z := NewDepthFirstMaze(m.Params[5].GetValueInt(), > m.Params[6].GetValueInt()) > m.Img = RenderMaze(m, z) > m.RequestPaint() > } > } > driver.Main(m) > } > > The mandelbrot example, specifically, is code by Sonia Keys taken from > RosettaCode, used by permission, and shows a concrete instance where I took > code that literally produced a single, static png, elevated a few constants > and variables to parameters, had it return the image instead of saving it, > wrapped it in a simple model - the actual executable for it is in cmd/demo. > > The intention is that your library or backend code could live unchanged > and uncontaminated, while you add a cmd/gui/ folder, drop in a model and a > main and produce a GUI that lets you exercise your code dynamically. Or, > for that matter, your GUI could live in its own package, just importing > your backend code, never to even visit your production environment. > > If you look at this and think, you know, with just a little work you could > do this in any language wrapped around an executable in Go that produced > the images, well, you're right. There is no reason the frontend code has to > be in Go. But by the same token, there is no reason the backend code has to > be in Go either! In cmd/cmdgui, cmdgui is a utility that does just this, > wrapping a command-line call, with parameters passed both in the > environment, and optionally interpolated into the arguments using Go > Templates. The examples show taking a simple Python script for quickly > generating a function plot, and making it interactive, and using curl to > call a webservice to make it interactive. > > Give it a try with > > go get github.com/TheGrum/renderview > > and let me know what you think. Have fun! > > > Howard C. Shaw III, the Grum > > P.S. I guess I have not documented the default parameters it cares about > yet, I should do that: > > left,top,right,bottom - these can be either int or float64, and when > available, operate panning, and if float64, zooming. - two way, you can > change these in your code to move the viewport if you are paying attention > to them > width,height - these get populated with the window width and height - > changing these in your code has no effect. > options - maybe more later, right now these just control the zooming (done > with the scroll-wheel) > const ( > OPT_NONE = iota // 0 > OPT_CENTER_ZOOM = 1 << iota // 1 > OPT_AUTO_ZOOM = 1 << iota // 2 > ) > zoom - int or float64, this gets incremented/decremented when the > scroll-wheel is turned, and can be used to implement your own zoom. > mouseX, mouseY - float64, these get populated with the current mouse > position in the window > page - this gets incremented/decremented by PgUp and PgDown when the > graphical window has the focus, allowing for a paged environment. You can > manipulated these from a custom zoom parameter to tie scrolling to paging > if desired. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
