Re: [go-nuts] [ANN] GoKi Trees and GoGi GUI

[Steven Wiley]

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  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 

Re: [go-nuts] [ANN] GoKi Trees and GoGi GUI

[matthewjuran]

>
> 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  > 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 
> 

Re: [go-nuts] [ANN] GoKi Trees and GoGi GUI

[Randall O'Reilly]

On May 5, 2018, at 8:38 AM, matthewju...@gmail.com wrote:
> In a generic container I would expect to see items typed as interface{} and 
> the behavior defined on a slice of interface{} or struct with private slice 
> of interface{} field.
> 
> From the godoc it looks like type Node implements type Ki, and there’s no 
> other type that implements Ki. I don’t understand why this is necessary, why 
> not just define the methods on type Node?
> 
> * But a diversity of functionality at each node (i.e., many different 
> possible node types) 
> 
> My thought is this calls for a type Node interface, then there would be more 
> types that implement Node. This line of thinking may lead to similar code to 
> what you have already, I’m not sure.

Here’s some explanation relative to those points:

* Ki is basically a “Node” interface, but you can’t name a struct and an 
interface the same thing, so we have Ki and Node as two sides of the same 
thing..

* The Ki interface allows specific nodes to override any of the functions, and, 
critically, ONLY an interface type knows what the actual underlying type of a 
struct is, so we need that to be able to access the fields etc of the actual 
struct at each node.  In general, having an interface in Go opens up lots of 
extra powers — could not have done many other things without it..

* There is no point in supporting a fully generic interface{} in a Tree 
container because the tree structure and logic requires each node to implement 
the same basic parent / child structure etc..  So Ki is the “minimal” interface 
for all tree nodes, and the Ki tree is a container of nodes that support that 
interface.

* The Node struct provides the default impl of the Ki interface, and typically 
you don’t need to impl it again in a different way, so almost always new Node 
types will just put Node as an anonymous embedded type, and perhaps modify some 
part of the Ki api as needed.

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.

Re: [go-nuts] [ANN] GoKi Trees and GoGi GUI

[Randall O'Reilly]

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  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 

Re: [go-nuts] [ANN] GoKi Trees and GoGi GUI

[Wojciech S. Czarnecki]

On Fri, 4 May 2018 04:39:06 -0600
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),

Hats off! 

If even for trying/seeding.

#
Problems seen so far:

$ ./widgets 
2018/05/04 23:18:07 x11driver: no window found for event xproto.FocusOutEvent
^C

$ ./widgets 
FontLib: error accessing path "/usr/local/share/fonts":
lstat /usr/local/share/fonts: no such file or directory
FontLib: error walking the path "/usr/local/share/fonts":
lstat /usr/local/share/fonts: no such file or directory
2018/05/04 23:19:28 x11driver: no window found for event xproto.FocusOutEvent
^C
(This one likely stem from somewhere hardcoded path)


# github.com/goki/goki/gi/oswin/touch
goki/goki/gi/oswin/touch/touch.go:97:5: cannot use Event literal (type
*Event) as type oswin.Event in assignment:
*Event does not implement oswin.Event (missing HasPos method)
^C

> 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..

Such giant enterprise deserves a detailed blog post, IMO. In lines of other
"why I personally get to go from X/y/C++; what I do like and what I do not"
posts. 

Awaiting your goki brainchild to mature and flourish :)
 
> - Randy
> 

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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.