Steve — thanks for your impressions. I’ll definitely contact you directly when I get around to trying to integrate rasterx — I haven’t even had a chance to look at it all, but a first question is when you expect it to be stable and reasonably feature-complete? e.g., one of the main things I would love to be able to use in the GUI are gradients, and your announcement mentioned that those were still pending?
I’m pretty sure you can just type "go get …” and it finds all the dependencies automatically, and they are likely to change over time, so I’m not sure it is conventional to list them? For example, I just removed the json-iterator dependency as it wasn’t even working, to make that list smaller by a few.. Re the all-platform GUI, it definitely seems tricky, and I’m developing on a Mac and only spent a minimal amount of effort getting Linux and Windows working, relative to the original Shiny framework. Unfortunately on linux any time you close a window it exits the event loop through some mechanism that I have yet to find! That is what is causing the lack of responsiveness — if you just don’t close any windows, everything should work fine :) I’m pretty sure Shiny was only tested with a single window, as there have been several issues related to that across the platforms. I don’t see those text field editing issues you report — did you install the MS TTF fonts? I also removed the /usr/local/share/fonts path per Wojciech’s comments — users can add via prefs if needed, so you shouldn’t be seeing any font path issues on the most recent version. One thing I’ve found so far is that the specific demands of the GUI logic place specific demands on the OS-specific logic, so I’ve been happy to have full control over that at the lowest level. The Shiny framework provides a really nice, maximally-Go-based OS-specific interface that I’ve easily been able to modify per my needs, so I’m hopeful that with a bit more effort things will be pretty smooth.. Re the full-featured nature of the Ki nodes, one consideration is that each node in the tree needs to support the relevant capabilities for them to work properly: e.g., properties can be inherited, and signals need to disconnect when a node has been deleted (and more generally, the node signals like “Updated” are an essential part of the basic functionality, and could not be made optional). Also, I wanted to automatically support things like JSON in the same way that a slice or map natively does, so an end-user doesn’t have to struggle with all that themselves (and I don’t ever have to deal with it again myself :) Anyway, in my estimation, the Ki node is minimal relative to the core desired functionality, but I’m very open to specific suggestions about how it could be simplified or more efficiently decomposed. Cheers, - Randy > On May 6, 2018, at 2:11 PM, Steven Wiley <steven.wi...@gmail.com> wrote: > > 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. -- 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.
