You are probably right about go get. I was pulling the repos into my workspace so I could check out the code more easily. That, plus just informing the user as to what is involved, is why you might want to list dependencies.
Gradients are coming soon to oksvg. On Monday, May 7, 2018 at 6:33:10 AM UTC-7, matthe...@gmail.com wrote: > > 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> 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. >> > 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.
