What's the status of go-qml?

[Alexander Medvednikov]

There haven't been any commits in almost a year.

Is it still active?

Thanks

[Paul Pacher]

I'm also curious. I used go-qml for some for small applications just to see how it works and it did work out well. I hope it contiues.

Greetings

[Rodolfo Amaral]

+1. go-qml is a brilliant work, I'm looking forward to see it evolving. Great products can be built with it.

[Geert-Johan Riemer]

I totally agree! I hope development will be picked up again!

--
You received this message because you are subscribed to the Google Groups "go-qml" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-qml+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gustavo Niemeyer]

Hey all,

Thanks for the kind comments, and sorry for not pushing the project further much in the last several months.

The honest truth is that my attention has been elsewhere, but this project is still close to my heart. If there are critical bugs, I'm interested in fixing them sooner rather than later, and I'm also interested in hearing about use cases and contributions. The more people depend on it the easiest it is for me to justify investing resources (and my own time) on it.

My email is always open to questions and conversations as well. Always feel free to reach out.

  

--

gustavo @ http://niemeyer.net

[Andrew Jackman]

Thank you, Gustavo. We appreciate your work. Let us know if you need anything.

-----
A. R. Jackman
USA: 801-432-0541
jac...@jackmanlabs.com

[Dennis Joachimsthaler]

I want to add my support too. I think go-qml might be the best binding to GUI I've seen in Go. In all others making GUIs is kind of... tedious, in go code.

[David Marceau]

On 10/21/2015 07:54 AM, Dennis Joachimsthaler wrote:
> I want to add my support too. I think go-qml might be the best binding to
> GUI I've seen in Go. In all others making GUIs is kind of... tedious, in go
> code.

Stating that go-qml is the best binding for gui with go is a stretch.
It's cool yes, but BEST can only be defined by the number of users and
and the number of real applications using golang with go-qml.

Don't get me wrong. go-qml is cool. golang is cool. I have
experienced painpoints with golang and qt in general that lead me to
believe gtk/gtkmm with c++ is a better choice for the time being:
-golang can't produce DLL's and explicitly states will never product
DLL's for any OS. This highly limits golang's applicability within
different architectures legacy and bleeding edge.
-qt's gui stuff is interpreted and compiled at runtime.
-qt's gui is yet another language to use.
-qt's gui requires mapping that gui language to golang's native language
data structures.

I am of the opinion gtk3 along with gtkmm maps more transparently with
golang. Any application worth building will eventually require some
bridging to C/C++. Golang does a good job of bridging to C/C++, but
golang is limited to non-DLL applicability. Conformal's gotk gtk golang
bridge is worth considering if you don't need a gui within a dll.

If you need a gui within a dll, you will need to look elsewhere and not
use golang. It doesn't matter go-qml or go-gtk/gotk. That means
Android golang gui dll plugins are not easily implementable. It means
MS windows control panel-like plugins are not easily implementable.
That involves circumventing the issue by creating servers/clients of
apis to get things done adding possible points of failure to the overall
architecture .dll/.so or .exe/.apk.

CONCLUSION:
gtkmm/C++ compiles/runs on windows 32-bit/64-bit, linux 32-bit/64-bit
intel/amd64/arm32/arm64 for building dlls and exe's.
golang go-qml .exe's are possible but not golang go-qml dll's for the
same platforms including android. Android however adds a dependency to
java/native developer kit which IMHO falls inadequate when compared to
the standard GNU/Linux with GNOME desktop GUI even with touch
capability. Even Ubuntu touch's UI is based on GTK3, yet constrains
users to building with QT at a higher level if I understood correctly.
That is highly constraining just like Android. That's my current
understanding about the state of affairs desktop and mobile.
DESKTOP: GNU/Linux with GNOME based on gtk. Highly versatile for any
purpose including touch. Easy to use tools. Best of class tools with
source code for everything as it should be TO PROTECT YOUR DIGITAL
FREEDOMS at every level.
ANDROID: constraining GUI toolkits depending on java/ndk. Less
versatile more complicated tools to use to get anything done. NON-FREE
BLOBS(no source code) are every turn deliberately reducing your digital
freedoms.
UBUNTU TOUCH: constraining GUI toolkits depending on qt, but based on
gtk. Less versatile and more complicated tools to use to get anything
done. Based on Android somewhat because they inherit the android linux
kernel device drivers and associated NON-FREE BLOBS(no source code)
again reducing your digital freedoms.
MS WINDOWS(ALL OSes): NON-FREE BLOBZILLA OS vendor locked-in complicated
tools to use to get anything done. If anything breaks under-the-hood,
you don't have access to source code to pinpoint where exactly the
source of the problem is occurring and how to fix it; you don't have
access to the source code depleting your powers to understand the flow
of the OS operations and application-specific operations involved in the
problem you are attempting to resolve. ALL AROUND HELL TO WORK WITH AS
A DEVELOPER. DO YOUR BEST TO AVOID IT IF AT ALL POSSIBLE. I understand
there are many facilitators(QT being one of them) wanting to mediate
between MS OS and other OSes and glue them together for some semblance
of peaceful coexistence. I assure you that is all in vain. The
GNU/Linux purists understand Microsoft however friendly they may seem to
be at present, have the ulterior motive to embrace extend and extinguish
GNU/Linux market share because it is eating away at their profits. MY
ONLY ADVICE TO YOU: Don't support windows when friends ask you for
help. Install GNU/Linux instead to get the real experience of DIGITAL
FREEDOM and the world synergy that comes with it.

GTK and X.org are the real GUI APIs to be working with. QT sits on top
of it as a mediator. Use it if you want, but the real power is found in
the lower level apis(GTK and X.org). The added benefit is reduced
complexity, reduced number tools...the core tools to get things done and
focused purpose of the APIs.

THE BOTTOM LINE: golang is not core-tool enough because it can't build
shared libraries. go-qml as a result is in the same predicament. As a
result, you couldn't rebuild the OS using golang even if you wanted to
because it's too constraining.

GNU/Linux, GNU COMPILER COLLECTION accompanied with GTK and X.org
totally empower you with enough rope to hang yourself with. You have to
be careful, but you can do it and you're not alone. There is a world
community out there taking a few minutes out of their day here and there
to answer each others questions and contribute different sources and
different docs because they love GNU/Linux more than any other OS.

>>>> an email to go-qml+un...@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
>>> "go-qml" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an

>>> email to go-qml+un...@googlegroups.com <javascript:>.

[salah....@gmail.com]

Go >=1.4 support shared libs.

[David Marceau]

Yes, perhaps experimental in 1.4, but not really useable.
I'm investigating 1.6 more closely. Lots of changes happened in 6
months. I'm glad to see it. Nothing compiles faster than go and
nothing is more fun to use than go. The "creating dll's with go useable
from other languages" was a very important component and makes it really
worth considering for multi-platform development gui or not.