ANNOUNCE: renderview

[howar...@gmail.com]

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.

[mura]

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?

[Michael Jones]

I tried to build but was deterred by build woes.

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nigel Tao]

On Sun, Aug 28, 2016 at 2:57 AM, Michael Jones <michae...@gmail.com> wrote:
> I tried to build but was deterred by build woes.

Yeah, all of the "renderview" imports need to be
"github.com/TheGrum/renderview" to play well with "go get".

[howar...@gmail.com]

Thanks, Nigel. I've updated as you recommended.

Remember to use -u to tell go get to fetch it fresh from github.

go get -u github.com/TheGrum/renderview

[howar...@gmail.com]

I still have not tested on Windows; I did look up and find some documentation on how to get go and gtk installed and working together on Windows, and it basically boils down to installing the linux version of go under mingw.

https://github.com/conformal/gotk3/wiki/Installing-on-Windows

http://stackoverflow.com/questions/16999498/how-to-set-up-gtk-for-go-on-win-7

You might say, "but Howard, you posted links for go-gtk and gotk3, what's up with that?"

Well, other update, I added preliminary gotk3 support last night. So now we have three backends, two of which are partially broken. Fun. Shiny = framebuffer, eventloop, no widgets. go-gtk = framebuffer, eventloop, widgets. gotk3 = eventloop, widgets, no framebuffer. That is too say, even though as far as I can tell the code is correctly asking a GtkImage to set its image from the pixbuf I'm passing it, I get nothing. 

So, hey, Joe Blue from the Shiny convo earlier, if you want to showcase examples in the various toolkits, you could contribute some more backends! :-P

I tried to set it up so that gotk3 would not try to compile by default, to limit the introduction of new build headaches. To build it, add -tags gotk3 nogtk2 to the build line. If on Ubuntu 14.04 like me, or a different distro with an early gtk3, you may need to add gtk_3_10 as well. I am slowly marking the example as such in the build tags so they don't auto-build, so in the example folder use example tag to build them.

go build -tags 'gtk_3_10 gotk3 nogtk2 example'

lsystem example compiled with the above... 18 M

go build -tags 'example'

lsystem example compiled with the above (uses go-gtk)... 7M

Hopefully the gotk3 rendering issue will be resolved shortly - if anyone has experience going from a golang image.Image to a rendered image on a GTK3 Cairo surface, I'll gladly listen.

Howard

[howar...@gmail.com]

Alright, gotk3 appears to be working properly now. I found the right function - I had found set_surface_pixbuf in the GTK3 docs, but thought it missing from the gotk3, until a helpful page pointed out that it was *not* a Cairo function, and took the Cairo context as a parameter instead.

So, one partial and two working backends. Excellent. All is proceeding as planned.

[Joe Blue]

Hey everyone,

That's great news. So trying this out i got stopped...

seems i need gtk on OSX.

i got lots trying to find out how to cleanly get gtk working on OSX. Their docs did not make sense to me.

http://www.gtk.org/download/macos.php

raised an issue.

https://github.com/TheGrum/renderview/issues/1