It sure does look like you put a great deal of effort into this project. Here are a couple of impressions after trying the demos and skimming through part of the source code.
First, I had to pull down a lot of other packages in order to get things to build. Did you happen to write up a dependency list somewhere? It might be helpful to list them in the readme so that fumblers like me won't have to do it trail and error. (FYI: I just added the non-standard lib dependency list to oksvg and rasterx.) Here are the additional packages I needed for gi : - https://github.com/BurntSushi/xgb - https://github.com/chewxy/math32 - https://github.com/go-gl/mathgl - https://github.com/goki/prof - https://github.com/jinzhu/copier - https://github.com/json-iterator/go - https://github.com/modern-go/reflect2 - https://github.com/modern-go/concurrent Also, I noticed that you need a go version greater than 1.9.4. I was getting a "math.Round not found" error until I upgraded to go1.10.2. So, once I got everything building, I was getting a few font path not found errors during runtime. (OS: Fedora 27), but still text was visible. Some things worked quite smoothly, like the transition from a simple panel to a scrolling panel as a window was resized to smaller than the window content. Other things were not behaving so well, like typing text into a text label, and the text would appear in a different location than the cursor. More seriously, almost every example I tried would at some point would hang and go non-responsive. I am happy to work with you offline if you want to track down some of these problems. As for looking at the code itself, as other people have mentioned it does seem to get a little heavy into use of reflection. Also, the ki package is very full featured, with a lot of capabilities built in to the tree nodes, like intra-node messaging, attribute maps, and more. So, I will echo some other comments here and suggest that you might want to consider letting some of those responsibilities fall to an object referenced by the node, which might allow simpler nodes to avoid unneeded overhead. I have been playing around a bit with GUIs also, but decided to base my stuff on SDL 2. It looks like you are basing off of something called shiny (golang.org/x/exp/shiny) ? Abstracting away the OS specific layer to make an all-platform GUI is a notoriously hard thing to do robustly, and is a frequent source of problems, just like intermittent hangups. Even with something as well supported as SDL, I was getting an intermittent bug until I realized I absolutely need to call runtime.LockOSThread(). Something like that might be going on here, and again we can follow up offline if you wish, or if you have any questions about using oksvg or rasterx. cheers, Steve On Friday, May 4, 2018 at 3:39:35 AM UTC-7, Randall O'Reilly wrote: > > https://github.com/goki/goki — key demo in: > https://github.com/goki/goki/tree/master/gi/examples/widgets > > This is the first release of a new Go framework built around the Tree as a > core data structure (Ki = Tree in Japanese), which includes as its first > application a fully-native Go GUI (built on top of a modified version of > the Shiny OS-specific backend drivers, supporting Mac, Linux, and Windows > so far). > > Building on the central idea in Go that having a few powerful > data-structures is essential for making many problems easier to solve, the > GoKi trees are an attempt to provide a powerful tree structure that can > support things like scene graphs, DOM’s, parsing trees, etc. > > The GoGi graphical interface system is a kind of “proof is in the pudding” > test, which weighs in at under 20k LOC and provides a reasonably > full-featured GUI — with a bit more work it should be able to do most of > the stuff you can do in Qt, and already includes a (self) reflection-driven > GUI designer. > > The overall design is an attempt to integrate existing standards and > conventions from widely-used frameworks, including Qt (overall widget > design), HTML / CSS (styling), and SVG (rendering). Rendering in SVG is > directly supported by the GoGi 2D scenegraph, with enhanced functionality > for interactive GUI's. This 2D framework also integrates with a (planned) > 3D scenegraph, to support interesting combinations of these frameworks. > Currently GoGi is focused on desktop systems, but nothing prevents > adaptation to mobile. > > Right now the rendering is based off of a modified version of > https://github.com/fogleman/gg, but I’m very interested in integrating > the new rasterx system that Steven Wiley recently announced. > > I’d be very interested in people’s impressions, suggestions, etc, and > welcome all interested contributors (there’s certainly much more to do) — > it would be great if this could provide the start for a widely-supported > Go-native GUI framework! This was my first Go project after many years in > C++ / Qt land, and I’m excited to join the community, and have really been > impressed with the language and ecosystem etc. The contrast in complexity > and build time between Qt and GoGi is really striking, and has kept me > going despite the huge amount of effort it took to get this new project off > the ground.. Cheers, > > - Randy > > -- 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.
