> > 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?
You may want to vendor them (https://golang.org/cmd/go/#hdr-Vendor_Directories) so if they ever go away or change API then your project will still work. Matt On Monday, May 7, 2018 at 1:05:13 AM UTC-5, Randall O'Reilly wrote: > > 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...@gmail.com > <javascript:>> 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...@googlegroups.com <javascript:>. > > 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.
