<p>I can't really get it working. I wrote a small go app that just downloads a file from the web and displays the progress using the library <code>andlabs/ui</code> found on github. Here is the code:</p>
<pre><code>package main
import (
"encoding/json"
"fmt"
"io"
"io/ioutil"
"math"
"net/http"
"os"
"github.com/andlabs/ui"
)
var bar *ui.ProgressBar
var filesize float64 = 20971520
type PassThru struct {
io.Reader
total int64
}
func Round(f float64) int {
return int(math.Floor(f + .5))
}
func (pt *PassThru) Read(p []byte) (int, error) {
n, err := pt.Reader.Read(p)
pt.total += int64(n)
if err == nil {
var progress float64 = float64(pt.total) / filesize
// fmt.Println("Read", n, "bytes for a total of", pt.total, " ", progress * 100)
ui.QueueMain(func() {
bar.SetValue(Round(progress * 100))
})
}
return n, err
}
func main() {
url := "https://sirwindfield.github.io/taskflow/application-support/test.jar"
file := "test.zip"
err := ui.Main(func() {
box := ui.NewVerticalBox()
bar = ui.NewProgressBar()
box.Append(ui.NewLabel("Updating launcher..."), true)
box.Append(bar, true)
box.SetPadded(false)
window := ui.NewWindow("Hello", 200, 24, false)
window.SetChild(box)
window.SetMargined(true)
window.OnClosing(func(*ui.Window) bool {
ui.Quit()
return true
})
window.Show()
go downloadFile(file, url)
})
if err != nil {
panic(err)
}
}
func downloadFile(filepath string, url string) (err error) {
// create destination file
out, err := os.Create(filepath)
if err != nil {
return err
}
defer out.Close()
// target file needs get request
resp, err := http.Get(url)
if err != nil {
return err
}
defer resp.Body.Close()
reader := &PassThru{Reader: resp.Body}
count, err := io.Copy(out, reader)
if err != nil {
fmt.Println(err)
os.Exit(1)
}
fmt.Println("Transferred", count, "bytes")
return nil
}
</code></pre>
<p>It is just a small test app for later on. I tried to cross compile it. Compiling it using <code>go build github.com/sirwindfield/launcher</code> works fine for my OS (darwin 64Bit). But as soon as I tried to compile it for linux the build process failed because the ui dependencies where not found (<code>undefined: ui.ProgressBar</code>). Strange, because compiling it for OS X works. Trying it for windows gives me an error message that tells me that either go nor SWIG are being used.
I googled for like an hour and couldn't find any fix for it. Tried <code>gox,</code>xgo`but both didn't work. </p>
<p>Would be nice if someone could help me out.
My code follows the GO code structure guide. <code>GOPATH</code>is <code>~/golang</code> and I run those commands in the <code>GOPATH</code>directory.</p>
<hr/>**评论：**<br/><br/>SportingSnow21: <pre><p>This isn't a problem with your Go code at all. The <code>andlabs/ui</code> library uses cgo, which doesn't come with the same cross-compilation guarantees as Go code. Since it depends on the platform-native C/C++ compiler and linker, you would need to compile this on the platform you're targeting. </p></pre>positivedown: <pre><p>so there is no way to do it on my OS X machine? Do you know another UI library for Go that is cross platform and can be compiled cross platform too?</p></pre>ZenSwordArts: <pre><p>To my knowledge there is no stable (or near-stable), cross-platform GUI library for Go.. </p>
<p>However you could serve your 'GUI' via an http server + html/css/js frontend. I know it's not the same as a native library but I think it's the best option you have at the moment.. </p>
<p>If someone has a better idea I would be very interested too..</p></pre>positivedown: <pre><p>the idea is to write a native launcher that downloads my main application written in java. The only UI I need is literally a ProgressBar.
Are there any other languages that are relatively easy to learn and can be compiled into executables for each major platform? Maybe an alternative would do it.</p></pre>ZenSwordArts: <pre><p>OK for that case it really isn't the best idea to spawn an http server.. I guess you chose Go because the binaries are statically linked and thus easily deployable?</p>
<p>For Go maybe just display the progress bar in the terminal ( e.g. <a href="https://github.com/cheggaaa/pb" rel="nofollow">pb</a> )</p>
<p>You will have similar problems with other languages.. cross-platform gui libraries will probably always bring some dependencies. You should really think about sticking to the terminal.. maybe it's just good enough.</p></pre>positivedown: <pre><blockquote>
<p>OK for that case it really isn't the best idea to spawn an http server.. I guess you chose Go because the binaries are statically linked and thus easily deployable?</p>
</blockquote>
<p>Yep, that's the reason. I guess a terminal shouldbe enough though. It just needs to be shown if a download is needed.
The idea was to just deliver a small Go stub that will handle the download of my app + a java installation (if necessary).
Is there some way to only open a terminal window if needed?</p></pre>SportingSnow21: <pre><p>One option, since <code>andlabs/ui</code> library has its cgo tied up neatly and promises static linking, is to spin up a couple barebones vm instances to compile the binaries you need with the proper toolchains. </p>
<p>Otherwise, you can just stick to cli, which will pop up when the application is run. If it's a dev tool, or targeted at a similar community, a terminal window isn't a bad way to go.</p></pre>positivedown: <pre><p>It is targeted at normal consumers. That's the problem. A terminal is not that streamlined and may be "scary" to others.</p></pre>SportingSnow21: <pre><p>Build VMs are probably your best bet, then. That allows you the native toolchains without the cost or hassle of hardware.</p></pre>positivedown: <pre><p>Ok, thank you. Will probably end up with this.</p></pre>shovelpost: <pre><p>Just curious. You said that your main application is written in Java. Why don't you use Java for the launcher as well? Java has everything you need to write a "native" UI. Also using just one language for both will probably make maintenance easier in the future.</p>
<p>Meanwhile, writing a native, cross-platform UI in Go is not easy since there's no pure Go library yet and you are forced into the C world which throws all of Go's advantages out of the window.</p>
<p>On the other hand, if you insist on using Go and since the only thing you need is just a progress bar, it might be worth it to do some extra work and write one "from scratch" using <a href="https://github.com/golang/exp/tree/master/shiny" rel="nofollow">exp/shiny</a>. I don't know how easy it is but check it out.</p></pre>positivedown: <pre><blockquote>
<p>Why don't you use Java for the launcher as well? </p>
</blockquote>
<p>Because that means that people need to install Java themselves. We publish our application to different companies and not all of them have Java. We got a request if it would be possible to implement a pre launcher capable of downloading Java if needed. </p></pre>shovelpost: <pre><p>Oh aha. Makes sense. In this case take a look at <a href="https://github.com/golang/exp/tree/master/shiny" rel="nofollow">exp/shiny</a>.</p></pre>driusan: <pre><p>shiny uses cgo for the low-level bindings to the OS to create the window too. It would have the same problems. (In fact, I doubt that it's a problem that anyone can get around without cgo in a way that supports every OS that Go supports.)</p></pre>positivedown: <pre><p>Just in theory, legally that wouldn't be possible, am I right? Running OS X on hardware not specific to Apple is against the ToS. Windows would need a valid license to work too.</p></pre>Yojihito: <pre><p>Depends if the ToS is enforcable. And that depends on the country you're in.</p>
<p>Law >>> ToS.</p></pre>positivedown: <pre><p>Thank you for your help :)</p></pre>
