[go-nuts] Re: Linking static c++ library with Go using SWIG
ah, sorry I didn't properly read the whole thread before posting
if it works for you when you set the flags through the CLI, but not when
you put them in a go file, then there is something wrong with how you
embedded the flags in you go file.
like Ian said, you need to define the flags in a comment directly before
using
import "C"
so, something like this should work
package main
/*
#cgo LDFLAGS: -L${SRCDIR}kflow/libcolor/lib -lCOLOR
*/
import "C"
Am Mittwoch, 1. März 2017 21:02:25 UTC+1 schrieb Chun Zhang:
>
> Thanks! I didn't write out libboost etc just to make sure that at least
> one lib is correctly linked, if so, I should see other link errors and I
> can just keep passing in required libs. This is exactly what happens when I
> pass CGO_LDFLAGS= explicitly in the CLI.
>
> However, when using the directives in the go file, the CGO_LDFLAGS= as far
> as I see in the `go build -x` log never includes any the link directives.
>
> Regards,
> Chun
>
>
>
> On Wednesday, March 1, 2017 at 2:30:12 PM UTC-5, therecipe wrote:
>>
>> ah okay, I had problems with the ".a" suffix myself, so I though it was
>> worth a shot.
>>
>> I just know that this
>> >//#cgo LDFLAGS: $GOPATH/src/kflow/libcolor/lib/libCOLOR
>>
>> won't work, as the env variables won't be resolved by go afaik.
>>
>> maybe test it with an absolute path instead
>>
>> and/or use "go build -n" to see how go would invoke "link"
>>
>> and maybe you need to link against "libboost_system" and "libxml2" as
>> well, if "libCOLOR" really depends on it.
>>
>>
>> Am Mittwoch, 1. März 2017 20:04:50 UTC+1 schrieb Chun Zhang:
>>>
>>> Yes, I tried quite a few varieties, such as:
>>> //#cgo LDFLAGS: $GOPATH/src/kflow/libcolor/lib/libCOLOR with/without .a
>>> //#cgo LDFLAGS: ${SRCDIR}kflow/libcolor/lib/libCOLOR with/without .a
>>> //#cgo LDFLAGS: -L${SRCDIR}kflow/libcolor/lib -l:libCOLOR with/without .a
>>> //#cgo LDFLAGS: -L${SRCDIR}kflow/libcolor/lib -lCOLOR with/without .a
>>>
>>> None above works for me so far, they are simply ignored during the
>>> building process. I even played with the empty spaces at various places,
>>> still no luck :(
>>>
>>> Thanks,
>>> Chun
>>>
>>>
>>> On Wednesday, March 1, 2017 at 1:57:15 PM UTC-5, therecipe wrote:
>>>>
>>>> did you try it without the ".a" suffix in the LDFLAGS?
>>>>
>>>> Am Dienstag, 28. Februar 2017 20:06:20 UTC+1 schrieb Chun Zhang:
>>>>>
>>>>> Hi, All,
>>>>>
>>>>> I have googled quite a bit about this issue, there are some tutorials
>>>>> online. But most of them targeted either at older go releases or C
>>>>> instead
>>>>> of C++.
>>>>>
>>>>> Can somebody please help me to figure out how to solve the following
>>>>> issues?
>>>>>
>>>>> I have to use a static library, wrote in C++ in a go project. I have
>>>>> the libcolor.a and the COLOR.h header file, the libcolor.a relies on some
>>>>> other libraries, such as libboost_system.a, libxml2.a etc to build.
>>>>>
>>>>> I wrote a libcolor.swigcxx file as follows:
>>>>> ---
>>>>> %module libcoror
>>>>>
>>>>> %{
>>>>> #include "include/COLOR.h"
>>>>> #include
>>>>> #include
>>>>>
>>>>> /* This is where we initialize any global parameters that are not
>>>>> search-thread specific */
>>>>> extern void COLOR_init_global_config(int argc, char *argv[]); // from
>>>>> the COLOR.h file, which is one of the APIs I would like to use
>>>>>
>>>>> %}
>>>>>
>>>>> #include "include/COLOR.h"
>>>>> extern void COLOR_init_global_config(int argc, char *argv[]);
>>>>> ---
>>>>>
>>>>> An empty libcolor.go file with the following lines was manually created
>>>>>
>>>>> ---
>>>>> package libcolor
>>>>>
>>>>> // #cgo CFLAGS: -I .
>>>>> // #cgo CXXFLAGS: -std=c++11 <--- this does not seem to work
>>>>> // #cgo LDFLAGS: -L${SRCDIR}/lib/ -lCOLOR.a -lz <--- this is placed at
>>>>>
[go-nuts] Re: Linking static c++ library with Go using SWIG
ah okay, I had problems with the ".a" suffix myself, so I though it was
worth a shot.
I just know that this
>//#cgo LDFLAGS: $GOPATH/src/kflow/libcolor/lib/libCOLOR
won't work, as the env variables won't be resolved by go afaik.
maybe test it with an absolute path instead
and/or use "go build -n" to see how go would invoke "link"
and maybe you need to link against "libboost_system" and "libxml2" as well,
if "libCOLOR" really depends on it.
Am Mittwoch, 1. März 2017 20:04:50 UTC+1 schrieb Chun Zhang:
>
> Yes, I tried quite a few varieties, such as:
> //#cgo LDFLAGS: $GOPATH/src/kflow/libcolor/lib/libCOLOR with/without .a
> //#cgo LDFLAGS: ${SRCDIR}kflow/libcolor/lib/libCOLOR with/without .a
> //#cgo LDFLAGS: -L${SRCDIR}kflow/libcolor/lib -l:libCOLOR with/without .a
> //#cgo LDFLAGS: -L${SRCDIR}kflow/libcolor/lib -lCOLOR with/without .a
>
> None above works for me so far, they are simply ignored during the
> building process. I even played with the empty spaces at various places,
> still no luck :(
>
> Thanks,
> Chun
>
>
> On Wednesday, March 1, 2017 at 1:57:15 PM UTC-5, therecipe wrote:
>>
>> did you try it without the ".a" suffix in the LDFLAGS?
>>
>> Am Dienstag, 28. Februar 2017 20:06:20 UTC+1 schrieb Chun Zhang:
>>>
>>> Hi, All,
>>>
>>> I have googled quite a bit about this issue, there are some tutorials
>>> online. But most of them targeted either at older go releases or C instead
>>> of C++.
>>>
>>> Can somebody please help me to figure out how to solve the following
>>> issues?
>>>
>>> I have to use a static library, wrote in C++ in a go project. I have the
>>> libcolor.a and the COLOR.h header file, the libcolor.a relies on some other
>>> libraries, such as libboost_system.a, libxml2.a etc to build.
>>>
>>> I wrote a libcolor.swigcxx file as follows:
>>> ---
>>> %module libcoror
>>>
>>> %{
>>> #include "include/COLOR.h"
>>> #include
>>> #include
>>>
>>> /* This is where we initialize any global parameters that are not
>>> search-thread specific */
>>> extern void COLOR_init_global_config(int argc, char *argv[]); // from
>>> the COLOR.h file, which is one of the APIs I would like to use
>>>
>>> %}
>>>
>>> #include "include/COLOR.h"
>>> extern void COLOR_init_global_config(int argc, char *argv[]);
>>> ---
>>>
>>> An empty libcolor.go file with the following lines was manually created
>>>
>>> ---
>>> package libcolor
>>>
>>> // #cgo CFLAGS: -I .
>>> // #cgo CXXFLAGS: -std=c++11 <--- this does not seem to work
>>> // #cgo LDFLAGS: -L${SRCDIR}/lib/ -lCOLOR.a -lz <--- this is placed at
>>> the correct place
>>> ---
>>>
>>> When I tried to build this using "go build -x" CLI, I hit the following
>>> error:
>>>
>>> WORK=/tmp/go-build797493895
>>> mkdir -p $WORK/klow/libcolor/_obj/
>>> mkdir -p $WORK/klow/
>>> swig -version
>>> cd $WORK
>>> /usr/local/go/pkg/tool/linux_amd64/compile -o
>>> ./klow/libcolor/_obj/_go_.o -trimpath . -p main -complete -buildid
>>> 73a7f9534f74346db4b3e0f48875da9dbf8bc2fd -D _$WORK ./swig_intsize.go
>>> cd /home/chzhang/go/src/klow/libcolor
>>> swig -go -cgo -intgosize 64 -module libcolor -o
>>> $WORK/klow/libcolor/_obj/libcolor_wrap.cxx -outdir
>>> $WORK/klow/libcolor/_obj/ -c++ libcolor.swigcxx
>>> CGO_LDFLAGS="-g" "-O2" /usr/local/go/pkg/tool/linux_amd64/cgo -objdir
>>> $WORK/klow/libcolor/_obj/ -importpath klow/libcolor -- -I
>>> $WORK/klow/libcolor/_obj/ $WORK/klow/libcolor/_obj/libcolor.go
>>> cd $WORK
>>> gcc -fdebug-prefix-map=a=b -c trivial.c
>>> gcc -gno-record-gcc-switches -c trivial.c
>>> cd /home/chzhang/go/src/klow/libcolor
>>> gcc -I . -fPIC -m64 -pthread -fmessage-length=0
>>> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I
>>> $WORK/klow/libcolor/_obj/ -g -O2 -o $WORK/klow/libcolor/_obj/_cgo_main.o -c
>>> $WORK/klow/libcolor/_obj/_cgo_main.c
>>> gcc -I . -fPIC -m64 -pthread -fmessage-length=0
>>> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I
>>> $WORK/klow/libcolor/_obj/ -g -O2 -o $WORK/klow/libcolor/_obj/_cgo_export.o
>>> -c
[go-nuts] Re: Linking static c++ library with Go using SWIG
did you try it without the ".a" suffix in the LDFLAGS?
Am Dienstag, 28. Februar 2017 20:06:20 UTC+1 schrieb Chun Zhang:
>
> Hi, All,
>
> I have googled quite a bit about this issue, there are some tutorials
> online. But most of them targeted either at older go releases or C instead
> of C++.
>
> Can somebody please help me to figure out how to solve the following
> issues?
>
> I have to use a static library, wrote in C++ in a go project. I have the
> libcolor.a and the COLOR.h header file, the libcolor.a relies on some other
> libraries, such as libboost_system.a, libxml2.a etc to build.
>
> I wrote a libcolor.swigcxx file as follows:
> ---
> %module libcoror
>
> %{
> #include "include/COLOR.h"
> #include
> #include
>
> /* This is where we initialize any global parameters that are not
> search-thread specific */
> extern void COLOR_init_global_config(int argc, char *argv[]); // from the
> COLOR.h file, which is one of the APIs I would like to use
>
> %}
>
> #include "include/COLOR.h"
> extern void COLOR_init_global_config(int argc, char *argv[]);
> ---
>
> An empty libcolor.go file with the following lines was manually created
>
> ---
> package libcolor
>
> // #cgo CFLAGS: -I .
> // #cgo CXXFLAGS: -std=c++11 <--- this does not seem to work
> // #cgo LDFLAGS: -L${SRCDIR}/lib/ -lCOLOR.a -lz <--- this is placed at the
> correct place
> ---
>
> When I tried to build this using "go build -x" CLI, I hit the following
> error:
>
> WORK=/tmp/go-build797493895
> mkdir -p $WORK/klow/libcolor/_obj/
> mkdir -p $WORK/klow/
> swig -version
> cd $WORK
> /usr/local/go/pkg/tool/linux_amd64/compile -o ./klow/libcolor/_obj/_go_.o
> -trimpath . -p main -complete -buildid
> 73a7f9534f74346db4b3e0f48875da9dbf8bc2fd -D _$WORK ./swig_intsize.go
> cd /home/chzhang/go/src/klow/libcolor
> swig -go -cgo -intgosize 64 -module libcolor -o
> $WORK/klow/libcolor/_obj/libcolor_wrap.cxx -outdir
> $WORK/klow/libcolor/_obj/ -c++ libcolor.swigcxx
> CGO_LDFLAGS="-g" "-O2" /usr/local/go/pkg/tool/linux_amd64/cgo -objdir
> $WORK/klow/libcolor/_obj/ -importpath klow/libcolor -- -I
> $WORK/klow/libcolor/_obj/ $WORK/klow/libcolor/_obj/libcolor.go
> cd $WORK
> gcc -fdebug-prefix-map=a=b -c trivial.c
> gcc -gno-record-gcc-switches -c trivial.c
> cd /home/chzhang/go/src/klow/libcolor
> gcc -I . -fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I
> $WORK/klow/libcolor/_obj/ -g -O2 -o $WORK/klow/libcolor/_obj/_cgo_main.o -c
> $WORK/klow/libcolor/_obj/_cgo_main.c
> gcc -I . -fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I
> $WORK/klow/libcolor/_obj/ -g -O2 -o $WORK/klow/libcolor/_obj/_cgo_export.o
> -c $WORK/klow/libcolor/_obj/_cgo_export.c
> gcc -I . -fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I
> $WORK/klow/libcolor/_obj/ -g -O2 -o
> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor.cgo2.o
>
> -c
> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor.cgo2.c
> g++ -I . -fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I
> $WORK/klow/libcolor/_obj/ -g -O2 -o
> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor_wrap.cxx.o
>
> -c $WORK/klow/libcolor/_obj/libcolor_wrap.cxx
> # klow/libcolor
> In file included from $WORK/klow/libcolor/_obj/libcolor_wrap.cxx:243:0:
> ./include/COLOR.h:13:43: warning: defaulted and deleted functions only
> available with -std=c++11 or -std=gnu++11
>PerSessionData(const PerSessionData )=default;
>^
> ./include/COLOR.h:14:53: warning: defaulted and deleted functions only
> available with -std=c++11 or -std=gnu++11
>PerSessionData& operator=(const PerSessionData)=default;
> ^
> g++ -I . -fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -o
> $WORK/klow/libcolor/_obj/_cgo_.o $WORK/klow/libcolor/_obj/_cgo_main.o
> $WORK/klow/libcolor/_obj/_cgo_export.o
> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor.cgo2.o
>
> $WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor_wrap.cxx.o
>
> -g -O2
> # klow/libcolor
> /tmp/go-build797493895/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor_wrap.cxx.o:
>
> In function `_wrap_COLOR_init_global_config_libcolor_3cea422eb6211fe0':
> /tmp/go-build/klow/libcolor/_obj/libcolor_wrap.cxx:285: undefined
> reference to `COLOR_init_global_config(int, char**)'
> collect2: error: ld returned 1 exit status
>
>
> Looks like there are two errors:
> 1, the C++11 warning
> 2, the linker can't find the function COLOR_init_global_config in the
[go-nuts] Re: [ANN] (GUI) Qt binding which supports Windows / macOS / Linux / Android / iOS / Sailfish OS / Raspberry Pi
It's intended to be build against Qt 5.7. And I think Qt 5.6.2 works also (with some errors/warnings during the setup) I may add backward compatibility in the future, but it's not planned yet. I use this script to get Qt 5.7 on trusty, if you want to link against system libs. https://github.com/therecipe/qt/blob/master/internal/ci/linux.sh Otherwise I would recommend to try the official pre-build packages, which will also allow stand alone deployments of you application. Am Freitag, 18. November 2016 02:29:20 UTC+1 schrieb howar...@gmail.com: > > What version of QT is it intended to be built against? I get > therecipe/qt/core/core.cpp:9:30: fatal error: QAbstractAnimation: No such > file or directory > when I try to build against it, or when trying to build the renderer > example. > > qt5-default says it is 5.5.1+dfsg-16ubuntu7.2 and qtdeclarative5-dev > is 5.5.1-2ubuntu6 > > I am building on Ubuntu 16.04.1 LTS. > > Howard > -- 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: [ANN] (GUI) Qt binding which supports Windows / macOS / Linux / Android / iOS / Sailfish OS / Raspberry Pi
Yes, you could encode the image.Image to []byte (in png or some other image format) and use the encoded data to create a QByteArray, which then can be used to create a QImage. The QImage can then be used to edit the image or to create a QPixmap, which can be displayed inside a QGraphicScene, QLabel, ... I played around with something like that last week and created an example, maybe this is the part that interest you: https://github.com/therecipe/qt/blob/master/internal/examples/widgets/renderer/renderer.go#L145-L187 And here are some infos about the different classes that Qt provides to work with image data http://doc.qt.io/qt-5/qpixmap.html#details Am Mittwoch, 16. November 2016 01:53:08 UTC+1 schrieb howar...@gmail.com: > > therecipe, is there a means available to render image.Image or draw.Image > (go Image) objects to Qt images/buffers/etc? > > I was not able to locate such a facility in several other libraries. In > the end I got fed up and wrote my own for converting a draw.Image to a > GdkPixBuf to get gtk2 and gotk3 working. Is there a similar raw in-memory > image format for Qt that is accessible in a way I could manually create it > from an image.Image? (In other words, one where the raw bytes are > accessible for setting, as an array, etc?) > > Howad > -- 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: [ANN] (GUI) Qt binding which supports Windows / macOS / Linux / Android / iOS / Sailfish OS / Raspberry Pi
Converting Go code to ui xml is not supported and currently not planned. But you can load ui files created by the Qt Designer with the help of the uitools pkg, you might want to take a look at the basic example in internal/examples/uitools. I'm planning to port the uic application to convert ui files to Go code in the future, but haven't really looked into that yet. Also there are a lot of small additions planned, but nothing big beside new supported platforms and Qt 5.8. I will instead cleanup the code and work on the usability of the tools. Am Dienstag, 15. November 2016 19:21:53 UTC+1 schrieb Justin Israel: > > > > On Tue, Nov 15, 2016, 11:47 PM <gerald...@gmail.com > wrote: > >> Great news! is it possible to load the gui which has been created with qt >> creator? >> > > I doubt it. That would require converting your Go code into a Qt .ui file > format, which I would be surprised if the library supported. Then for it to > be useful it would also have to have the equivalent of pyuic (for PyQt4, or > pyside-uic) to convert from a UI file back to Go. > > Seems more likely that UI code will just be designed by hand. > > is there anything which you still plan to add/extend? >> >> >> On Monday, November 14, 2016 at 1:30:58 AM UTC+1, Rich wrote: >>> >>> This looks very well done. I've not done any real programming in it but >>> looking over the github it looks like this is well on it's way. Thank >>> you!! i have a few programs I've been meaning to write that needed a >>> gui, I'll be giving this a shot. >>> >>> >>> >>> On Thursday, November 10, 2016 at 3:34:36 PM UTC-5, therecipe wrote: >>>> >>>> Hey everyone, >>>> >>>> I would like to officially announce the project I'm working on for a >>>> while now. >>>> It's a binding for the Qt framework + some tools to help you with >>>> development and deployment of your Qt applications. >>>> >>>> The most interesting feature of the Qt framework for the Go community >>>> is probably that it can be used to develop native looking GUI applications >>>> for various platforms without the need to make platform specific changes >>>> to >>>> your code. >>>> Beside the GUI modules Qt also includes: a webengine (chromium), >>>> several multimedia functions, access to bluetooth + nfc, access to various >>>> hardware sensors, gamepad support, access to position informations and >>>> much >>>> more ... >>>> The Qt article on wikipedia: >>>> https://en.wikipedia.org/wiki/Qt_(software) >>>> >>>> >>>> There are two caveats for those who intent to use the binding: >>>> >>>> 1. You code won't be pure Go anymore, as this binding heavily relies on >>>> cgo. >>>> 2. The binding dynamically links to Qt's libraries, which results in >>>> 25-50mb (depending on the platform) uncompressed libs that have to be >>>> deployed along with you binary. >>>> (But it's also possible to link against the static Qt libs and remove >>>> this need. And there is also work being done to reduce the size of the >>>> dynamic libs in the upcoming versions of Qt.) >>>> >>>> >>>> For the pro side, I should probably mention that: >>>> >>>> 1. The deployment to most platforms is pretty trivial (that includes >>>> cross compiling). (And there will be even more supported platforms in the >>>> future) >>>> 2. That the binding is almost complete and already supports most Qt >>>> modules (30+). >>>> 3. There are a lot of examples to get you started. (And porting over >>>> existing C++ examples should be super simple) >>>> >>>> >>>> If someone is interested in testing it out, it can be found here: >>>> https://github.com/therecipe/qt >>>> >>>> >>>> Or if you just want to take a quick look and test the examples on Linux >>>> and you are familiar with Docker. >>>> You could use one of the images as well: `docker pull therecipe/qt:base` >>>> And simply run `qtdeploy build desktop` in one of the `$GOPATH/src/ >>>> github.com/therecipe/qt/internal/examples/` >>>> <http://github.com/therecipe/qt/internal/examples/> sub-sub folders. >>>> (inside the container) >>>> There will be a new folder created called `deploy`, which should >>>> contain everything that is needed to run the application on a regular >>>> 64-bit Linux system. >>>> >>>> >>>> Please let me know what you think. >>>> Any feedback is welcome :) >>>> >>> -- >> 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.
Re: [go-nuts] [ANN] (GUI) Qt binding which supports Windows / macOS / Linux / Android / iOS / Sailfish OS / Raspberry Pi
Most times there is some function that returns either some error code or some error string. Like in http://doc.qt.io/qt-5/qmediaplayer.html#error, but it's rarely needed. Am Samstag, 12. November 2016 18:54:16 UTC+1 schrieb Pietro Gagliardi (andlabs): > > Does Qt even expose errors itself? Back when I did Qt I never had to check > myself... > > On Nov 12, 2016, at 4:17 AM, Jason Stillwell <drag...@gmail.com > > wrote: > > I gave it a try using QMdiArea. It seems to work well. > > But I'm confused about where the errors go. There doesnt' seem to be a way > to check for errors. Does it panic in every error situation? > > On Thursday, November 10, 2016 at 12:34:36 PM UTC-8, therecipe wrote: >> >> Hey everyone, >> >> I would like to officially announce the project I'm working on for a >> while now. >> It's a binding for the Qt framework + some tools to help you with >> development and deployment of your Qt applications. >> >> The most interesting feature of the Qt framework for the Go community is >> probably that it can be used to develop native looking GUI applications for >> various platforms without the need to make platform specific changes to >> your code. >> Beside the GUI modules Qt also includes: a webengine (chromium), several >> multimedia functions, access to bluetooth + nfc, access to various hardware >> sensors, gamepad support, access to position informations and much more ... >> The Qt article on wikipedia: https://en.wikipedia.org/wiki/Qt_(software) >> >> >> There are two caveats for those who intent to use the binding: >> >> 1. You code won't be pure Go anymore, as this binding heavily relies on >> cgo. >> 2. The binding dynamically links to Qt's libraries, which results in >> 25-50mb (depending on the platform) uncompressed libs that have to be >> deployed along with you binary. >> (But it's also possible to link against the static Qt libs and remove >> this need. And there is also work being done to reduce the size of the >> dynamic libs in the upcoming versions of Qt.) >> >> >> For the pro side, I should probably mention that: >> >> 1. The deployment to most platforms is pretty trivial (that includes >> cross compiling). (And there will be even more supported platforms in the >> future) >> 2. That the binding is almost complete and already supports most Qt >> modules (30+). >> 3. There are a lot of examples to get you started. (And porting over >> existing C++ examples should be super simple) >> >> >> If someone is interested in testing it out, it can be found here: >> https://github.com/therecipe/qt >> >> >> Or if you just want to take a quick look and test the examples on Linux >> and you are familiar with Docker. >> You could use one of the images as well: `docker pull therecipe/qt:base` >> And simply run `qtdeploy build desktop` in one of the `$GOPATH/src/ >> github.com/therecipe/qt/internal/examples/` >> <http://github.com/therecipe/qt/internal/examples/> sub-sub folders. >> (inside the container) >> There will be a new folder created called `deploy`, which should contain >> everything that is needed to run the application on a regular 64-bit Linux >> system. >> >> >> Please let me know what you think. >> Any feedback is welcome :) >> > > -- > 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.
[go-nuts] Re: [ANN] (GUI) Qt binding which supports Windows / macOS / Linux / Android / iOS / Sailfish OS / Raspberry Pi
As Qt itself doesn't use exceptions (even through it partially supports them), there are no Go like error returns. Instead if something unexpected happens, most classes provide functions to receive an error message or error code in some way. So it will only panic if something happens, that's impossible to recover from. Am Samstag, 12. November 2016 17:55:48 UTC+1 schrieb Jason Stillwell: > > I gave it a try using QMdiArea. It seems to work well. > > But I'm confused about where the errors go. There doesnt' seem to be a way > to check for errors. Does it panic in every error situation? > > On Thursday, November 10, 2016 at 12:34:36 PM UTC-8, therecipe wrote: >> >> Hey everyone, >> >> I would like to officially announce the project I'm working on for a >> while now. >> It's a binding for the Qt framework + some tools to help you with >> development and deployment of your Qt applications. >> >> The most interesting feature of the Qt framework for the Go community is >> probably that it can be used to develop native looking GUI applications for >> various platforms without the need to make platform specific changes to >> your code. >> Beside the GUI modules Qt also includes: a webengine (chromium), several >> multimedia functions, access to bluetooth + nfc, access to various hardware >> sensors, gamepad support, access to position informations and much more ... >> The Qt article on wikipedia: https://en.wikipedia.org/wiki/Qt_(software) >> >> >> There are two caveats for those who intent to use the binding: >> >> 1. You code won't be pure Go anymore, as this binding heavily relies on >> cgo. >> 2. The binding dynamically links to Qt's libraries, which results in >> 25-50mb (depending on the platform) uncompressed libs that have to be >> deployed along with you binary. >> (But it's also possible to link against the static Qt libs and remove >> this need. And there is also work being done to reduce the size of the >> dynamic libs in the upcoming versions of Qt.) >> >> >> For the pro side, I should probably mention that: >> >> 1. The deployment to most platforms is pretty trivial (that includes >> cross compiling). (And there will be even more supported platforms in the >> future) >> 2. That the binding is almost complete and already supports most Qt >> modules (30+). >> 3. There are a lot of examples to get you started. (And porting over >> existing C++ examples should be super simple) >> >> >> If someone is interested in testing it out, it can be found here: >> https://github.com/therecipe/qt >> >> >> Or if you just want to take a quick look and test the examples on Linux >> and you are familiar with Docker. >> You could use one of the images as well: `docker pull therecipe/qt:base` >> And simply run `qtdeploy build desktop` in one of the `$GOPATH/src/ >> github.com/therecipe/qt/internal/examples/` >> <http://github.com/therecipe/qt/internal/examples/> sub-sub folders. >> (inside the container) >> There will be a new folder created called `deploy`, which should contain >> everything that is needed to run the application on a regular 64-bit Linux >> system. >> >> >> Please let me know what you think. >> Any feedback is welcome :) >> > -- 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: [ANN] (GUI) Qt binding which supports Windows / macOS / Linux / Android / iOS / Sailfish OS / Raspberry Pi
Yes it's fully supported, you might want to take a look at the `internal/examples/qml` or `quick` folder. To see how you can interact with QML from Go. Am Samstag, 12. November 2016 03:49:14 UTC+1 schrieb Tong Sun: > > Cool! > > Does it support the declarative > <https://en.wikipedia.org/wiki/Declarative_programming> QML > <https://en.wikipedia.org/wiki/QML>? > > > On Thursday, November 10, 2016 at 3:34:36 PM UTC-5, therecipe wrote: >> >> Hey everyone, >> >> I would like to officially announce the project I'm working on for a >> while now. >> It's a binding for the Qt framework + some tools to help you with >> development and deployment of your Qt applications. >> >> The most interesting feature of the Qt framework for the Go community is >> probably that it can be used to develop native looking GUI applications for >> various platforms without the need to make platform specific changes to >> your code. >> Beside the GUI modules Qt also includes: a webengine (chromium), several >> multimedia functions, access to bluetooth + nfc, access to various hardware >> sensors, gamepad support, access to position informations and much more ... >> The Qt article on wikipedia: https://en.wikipedia.org/wiki/Qt_(software) >> >> >> There are two caveats for those who intent to use the binding: >> >> 1. You code won't be pure Go anymore, as this binding heavily relies on >> cgo. >> 2. The binding dynamically links to Qt's libraries, which results in >> 25-50mb (depending on the platform) uncompressed libs that have to be >> deployed along with you binary. >> (But it's also possible to link against the static Qt libs and remove >> this need. And there is also work being done to reduce the size of the >> dynamic libs in the upcoming versions of Qt.) >> >> >> For the pro side, I should probably mention that: >> >> 1. The deployment to most platforms is pretty trivial (that includes >> cross compiling). (And there will be even more supported platforms in the >> future) >> 2. That the binding is almost complete and already supports most Qt >> modules (30+). >> 3. There are a lot of examples to get you started. (And porting over >> existing C++ examples should be super simple) >> >> >> If someone is interested in testing it out, it can be found here: >> https://github.com/therecipe/qt >> >> >> Or if you just want to take a quick look and test the examples on Linux >> and you are familiar with Docker. >> You could use one of the images as well: `docker pull therecipe/qt:base` >> And simply run `qtdeploy build desktop` in one of the `$GOPATH/src/ >> github.com/therecipe/qt/internal/examples/` >> <http://github.com/therecipe/qt/internal/examples/> sub-sub folders. >> (inside the container) >> There will be a new folder created called `deploy`, which should contain >> everything that is needed to run the application on a regular 64-bit Linux >> system. >> >> >> Please let me know what you think. >> Any feedback is welcome :) >> > -- 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: [ANN] (GUI) Qt binding which supports Windows / macOS / Linux / Android / iOS / Sailfish OS / Raspberry Pi
Thank you, I appreciate it :) Am Donnerstag, 10. November 2016 23:42:41 UTC+1 schrieb Rusco: > > Good to see some progress on the GUI front - I think you are up to > something ! > Rusco > > > > On Thursday, 10 November 2016 20:34:36 UTC, therecipe wrote: >> >> Hey everyone, >> >> I would like to officially announce the project I'm working on for a >> while now. >> It's a binding for the Qt framework + some tools to help you with >> development and deployment of your Qt applications. >> >> The most interesting feature of the Qt framework for the Go community is >> probably that it can be used to develop native looking GUI applications for >> various platforms without the need to make platform specific changes to >> your code. >> Beside the GUI modules Qt also includes: a webengine (chromium), several >> multimedia functions, access to bluetooth + nfc, access to various hardware >> sensors, gamepad support, access to position informations and much more ... >> The Qt article on wikipedia: https://en.wikipedia.org/wiki/Qt_(software) >> >> >> There are two caveats for those who intent to use the binding: >> >> 1. You code won't be pure Go anymore, as this binding heavily relies on >> cgo. >> 2. The binding dynamically links to Qt's libraries, which results in >> 25-50mb (depending on the platform) uncompressed libs that have to be >> deployed along with you binary. >> (But it's also possible to link against the static Qt libs and remove >> this need. And there is also work being done to reduce the size of the >> dynamic libs in the upcoming versions of Qt.) >> >> >> For the pro side, I should probably mention that: >> >> 1. The deployment to most platforms is pretty trivial (that includes >> cross compiling). (And there will be even more supported platforms in the >> future) >> 2. That the binding is almost complete and already supports most Qt >> modules (30+). >> 3. There are a lot of examples to get you started. (And porting over >> existing C++ examples should be super simple) >> >> >> If someone is interested in testing it out, it can be found here: >> https://github.com/therecipe/qt >> >> >> Or if you just want to take a quick look and test the examples on Linux >> and you are familiar with Docker. >> You could use one of the images as well: `docker pull therecipe/qt:base` >> And simply run `qtdeploy build desktop` in one of the `$GOPATH/src/ >> github.com/therecipe/qt/internal/examples/` >> <http://github.com/therecipe/qt/internal/examples/> sub-sub folders. >> (inside the container) >> There will be a new folder created called `deploy`, which should contain >> everything that is needed to run the application on a regular 64-bit Linux >> system. >> >> >> Please let me know what you think. >> Any feedback is welcome :) >> > -- 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.
