Re: [go-nuts] Suggestions for layout/structure/coding-patterns for GUI applications in Go?
Tom, One very common and seemingly effective structure is the tree / scenegraph, which is used in Qt and, as the DOM, in HTML, and lots of other places. GoGi https://github.com/goki/gi uses this, so you can see native Go examples there. In Qt and GoGi in particular, you leverage the Layout to do a lot of the work — just add elements to it, and let it organize the appearance, etc. You can use the visitor and model / view patterns to operate on the scenegraph and keep the logic decoupled from the appearance.. GoGi makes extensive use of another efficient trick: separating the decisions about what gui elements to construct from the process of configuring those elements. There can be a lot of complex conditional logic in deciding what you want to build — tying this up with all the additional logic to create and manage those elements results in major spaghetti. To decouple these, a slice of type, name tuples is constructed dynamically via the relevant logic, and then after that point, everything is relatively clean and modular in switching etc on how to configure / manage whatever was ultimately built. See e.g., the https://github.com/goki/gi/blob/master/gi/dialogs.go code that has many different ways to configure the “config” slice for a dialog.. - Randy > On Jan 11, 2019, at 4:30 PM, Tom wrote: > > Hi! > > TL;DR: GUI applications seems pretty hard to structure the code in a readable > way. Can anyone recommend any patterns/layout or suggestions to structuring > such a codebase and keeping it readable? > > I wrote a GUI application in Go late at night once (using gotk3). I tried to > keep it readable by functionally decomposing methods, keeping as much private > as possible, and keeping different dialogs/windows etc in different packages > (each dialog/window was mapped to a struct). > > Despite this, each struct quickly turned into existential spaghetti, with > 10-20 fields on each struct and over a dozen methods, with quite high > coupling. > > I thought about trying to break down pieces into smaller components (like a > struct for a subset of fields on the page), but that seemed like more > boilerplate with still quite a bit of coupling. > > So my question is this: How do you structure Go GUI programs? What patterns > work? Anything well-written & open-source I can learn from? > > GUI programs seems particularly heinous compared to server or system > programs, which (at least to me) seem a lot easier to tease out parts & keep > them simple-looking. > > Thanks & love, > Tom > > -- > 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.
[go-nuts] Re: if/switch statements as expressions
On Sunday, 13 January 2019 01:40:14 UTC+2, David Collier-Brown wrote: > > [ ... ] > Anyone here remember how algol68 addressed that, or what the hollering was > about? > > It's too easy, forty years later, to label algol68 a success. From my very remote location and no social media at the time, I clearly recall a lot more criticism than welcome. Wirth's Algol-W got a better reception, at the time when pragmatism was still second-fiddle to academic "purity" and, I seem to recall, justly so. Lucio. -- 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.
[go-nuts] Re: if/switch statements as expressions
On Saturday, 12 January 2019 13:04:32 UTC+2, alanfo wrote: > > Sorry for the delay in responding. > > [ ... ] > > Such cases crop up a lot in practice and I don't think I'm the only one > who finds it tedious having to write six lines of code when a single line > suffices in most other C-family languages. > > Only because someone has long ago invented a notation for that, that sadly lent itself to abuse. > Also, knowing that both expressions will be evaluated will deter people > from passing complex expressions (including other nested IIf's, function > calls with side effects etc.) to the function [ ... ] > Unfortunately, some rope tends to be too inviting, with too many children around. The adults just have to bite the bullet. Lucio. -- 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] Re: Suggestions for layout/structure/coding-patterns for GUI applications in Go?
On Sat, 12 Jan 2019 15:55:01 -0800 David Collier-Brown wrote: > > I'm pleasantly mature (born in 1644), but I still don't understand > javascript GUIs (;-)) Amazing. -- 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] Transferring host's go-mod-download cache into docker container
On Fri, Jan 11, 2019, at 23:03, grego...@unity3d.com wrote: > But now, I don't know how I can essentially copy the mod cache (or > whatever the right term is) like I'd have copied the vendor directory. If you're suggesting that you already have the module cached on the machine that builds your containers, the cache lives at ~/go/pkg/mod by default so you could probably copy that tree into your build container. —Sam -- 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.
[go-nuts] Re: Transferring host's go-mod-download cache into docker container
On Friday, January 11, 2019 at 10:23:01 PM UTC-8, Tamás Gulácsi wrote: > > Use the vendor directory, or use a replace directive with a relative path. Manually adding replace directives for all dependent packages (probably 30-40 now, who knows how many after a few years) sounds like a fairly horrible maintenance cost, but maybe I'm missing a way to use them easily? Is there a page somewhere with a good writeup of these directives? Re: Using the vendor dir approach, I did re-read the `go help modules` text, the last section particularly: - Modules and vendoring When using modules, the go command completely ignores vendor directories. By default, the go command satisfies dependencies by downloading modules from their sources and using those downloaded copies (after verification, as described in the previous section). To allow interoperation with older versions of Go, or to ensure that all files used for a build are stored together in a single file tree, 'go mod vendor' creates a directory named vendor in the root directory of the main module and stores there all the packages from dependency modules that are needed to support builds and tests of packages in the main module. To build using the main module's top-level vendor directory to satisfy dependencies (disabling use of the usual network sources and local caches), use 'go build -mod=vendor'. Note that only the main module's top-level vendor directory is used; vendor directories in other locations are still ignored. - So I guess we can use `go mod vendor` and then `go build -mod=vendor` but is this a long term solution? It seems like the community desire is to move away from vendor dirs. If vendor dir support is eventually completely removed, will replace-directives be the only way to have network-less builds? I guess if this is the case we should probably just use vendoring until it's removed, then pay the price to switch. -- 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.
[go-nuts] Re: Suggestions for layout/structure/coding-patterns for GUI applications in Go?
I'm pleasantly mature (born in 1644), but I still don't understand javascript GUIs (;-)) --dave On Friday, January 11, 2019 at 11:53:03 PM UTC-5, Lucio wrote: > > >> I think it's a maturity thing, with the added complexity that the need > for an immediate solution prevents any study of possible generic (not as in > "generics", though) solutions. > -- 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.
[go-nuts] Re: if/switch statements as expressions
Very *very* regular languages like lisp barely made a distinction between expressions and statements, so if was an expression. I'm not sure how well that would work in a c-like language like Go: the debate about that in algol68 was about 8 years before I became interested in computers. Anyone here remember how algol68 addressed that, or what the hollering was about? --dave On Wednesday, December 19, 2018 at 3:09:35 PM UTC-5, Viktor Kojouharov wrote: > > I'm interested to know whether it was considered (I can't imagine that it > wasn't) for if and switch statements to be expressions instead, and if so, > why were they ultimately left as statements. > -- 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.
[go-nuts] Getting public ipv6 address with active privacy extensions
Hi there,
i developing a dynodes update client, for a mixed environment ipv4+ipv6
dual stack. For this it would be best to send/update the public
ipv6 instead of the temporary address.
For short
conn, _ := net.Dial("udp6", "[2001:db8::1]:80")
defer conn.Close()
localAddr := conn.LocalAddr().(*net.UDPAddr)
fmt.Printf("%v", localAddr)
gave me the temporary address.
In the Golang source
IPV6_PREFER_SRC_PUBLIC
/ sysIPV6_PREFER_SRC_PUBLIC Flag is defines according to rfc5014
passing this flag should
use the public IPv6
as source address.
My problem is that i can't figure out, how and where i can set this flag.
Did someone has in example for me.
Kind regards
Marc
--
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.
[go-nuts] Re: if/switch statements as expressions
Sorry for the delay in responding.
Yes, that's a fair point though I was only intending the Iif function to be
used for simple cases where the cost of evaluating both expressions is
negligible.
Such cases crop up a lot in practice and I don't think I'm the only one who
finds it tedious having to write six lines of code when a single line
suffices in most other C-family languages.
Also, knowing that both expressions will be evaluated will deter people
from passing complex expressions (including other nested IIf's, function
calls with side effects etc.) to the function which is the reason given in
the Go FAQ for not supporting the conditional operator in the first place.
So, in a sense, this is an argument for adding an Iif function as it will
enable people to write more concise code for simple cases whilst deterring
its use for complex stuff.
Alan
On Thursday, January 3, 2019 at 11:33:47 PM UTC, Milan Zamazal wrote:
>
> alanfo > writes:
>
> > Some languages which don't support the conditional operator or if/else
> > expressions have an Iif function (or similar) instead.
> >
> > If generics are added to Go, it might be worth including something like
> > this in the standard library to cut down on boilerplate for simple
> cases:
> >
> > // in a package called 'gen' say
> > func Iif(type T) (cond bool, t1, t2 T) T {
> > if cond {
> > return t1
> > }
> > return t2
> > }
> >
> > // usage
> > x := 3
> > ...
> > y := gen.Iif(x > 2, 4, 5) // T inferred to be int, assigns 4 to y
> >
> > You can, of course, do this now with interface{} but it's not type-safe
> and
> > requires a type assertion on assignment.
> >
> > A drawback is that it would require the overhead of a function call
> unless
> > the Go compiler could inline simple stuff such as this.
>
> A worse drawback is that both the alternatives are evaluated, which is a
> problem for all but very simple cases.
>
> > Alan
> >
> > On Wednesday, December 19, 2018 at 8:09:35 PM UTC, Viktor Kojouharov
> wrote:
> >>
> >> Hello,
> >>
> >> I've tried and failed at finding any previous discussion on this topic,
> so
> >> do point me to one if it exists.
> >>
> >> I'm interested to know whether it was considered (I can't imagine that
> it
> >> wasn't) for if and switch statements to be expressions instead, and if
> so,
> >> why were they ultimately left as statements. It seems to me that having
> >> them as expressions will not cause a significant change in how they are
> >> ultimately used, mostly because other languages that do support such
> >> expressions do not exhibit this behaviour either. Nor is such a change
> >> strictly backwards incompatible, since any expression is also
> technically a
> >> statement as well, via the ExpressionStmt grammar rule. Such
> expressions
> >> also cover a simple feature which a lot of people new to the language
> are
> >> looking for, and most of us have abused in other languages - ternary
> >> operators. The Go FAQ states that if-elses are clearer, if longer,
> which I
> >> definitely agree with. Yet it seems that an if expression would retain
> its
> >> readability, if not outright increase it, while allowing for terser
> >> assignments. The reason being that a chunk of repeatable code (for
> example
> >> assigning to the same variable in every logical branch) would be moved
> out
> >> of the whole block, thus highlighting the value.
> >>
> >> What if the spec defines that if all if-else blocks / all switch case
> >> clauses contain only single expression, they would be expressions
> rather
> >> than statements. How would that negatively impact the language, in a
> way
> >> that can't already be reproduced?
> >>
>
--
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] Re: how do I make my function always run at exit in `go test`?
Hmm.. I tested it again and it works today. I think it was just my problem. Sorry for the confusion and thank you! 2019년 1월 10일 목요일 오후 5시 25분 12초 UTC+9, Justin Israel 님의 말: > > > > On Thu, Jan 10, 2019, 9:14 PM 김용빈 > wrote: > >> Hi, Justin. Thank you for the response. >> >> But it didn't work for me. that means when I terminate it with Ctrl+C, it >> doesn't print CLEANUP. >> >> I am using linux (manjaro) terminal now. >> > > I am not sure why it wouldn't work. I confirmed it on an Ubuntu distro. > > >> 2019년 1월 10일 목요일 오후 2시 41분 24초 UTC+9, Justin Israel 님의 말: >>> >>> Oh, I see. Well also adding a signal handler for SIGINT/SIGTERM also >>> works for me: >>> https://play.golang.org/p/93VmTTgE4YB >>> >>> Justin >>> >>> >>> On Thu, Jan 10, 2019 at 6:29 PM 김용빈 wrote: >>> Sorry I didn't clarify but I mean when it is killed/terminated. 2019년 1월 10일 목요일 오후 2시 24분 35초 UTC+9, 김용빈 님의 말: > I tried signal.Notify but it seems it doesn't work. > > Then I find this: > https://github.com/golang/go/issues/15553#issuecomment-217162874 > > So what should I do to make my function always run at exit in test? > -- 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...@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.
