As mentioned before, I am re-making the snowloadcount wizard gui using the golang with go-gtk bindings. Here is the code: https://github.com/omac777/gogtksnowloadcount
If you want to get up and running with go. mkdir -p ~/Code sudo apt-get install mercurial meld libgtkmm-3.0-dev libgtkmm-2.4-dev libpangomm-1.4-dev libgtkglextmm-x11-1.2-dev libgtksourceviewmm-3.0-dev libgtksourceview2.0-dev libgtksourceview-3.0-dev hg clone -u release https://code.google.com/p/go cd go cd src ./all.bash Put this into your ~/.bashrc: export GOROOT=/home/youruser/Code/go export PATH=$PATH:$GOROOT/bin go get github.com/mattn/go-gtk cd ~/Code/go/src/github.com/mattn/go-gtk make install make example NOTE: the go-gtk bindings build fails if you didn't install the gtk,gtkmm,gtksourceview stuff as mentioned above so make sure you install it first. go get github.com/omac777/gogtksnowloadcount cd ~/Code/go/src/github.com/omac777/gogtksnowloadcount go build gogtksnowloadcount.go ./gogtksnowloadcount I also added the gtkmm to github also if you want to compare between the c++ and the golang versions. Serialization is done in c++ version, but not done yet in the golang version although the golang version will be a lot cleaner once done. https://github.com/omac777/gtksnowloadcount Cheers, David Marceau On 01/24/2014 02:57 PM, David Marceau wrote: > I did a small gui that is a wizard reflecting an actual form being used > for counting snow disposal trucks which dump snow at different locations > in Ottawa, the city manages them with tickets and passes. At the end of > the shift, the form is submitted to the supervisor with the statistics > along with who generated them. > > Here is the qt/qt for android one: > http://adequatech.ca/snowloadcount.tar.xz > It's features: > -desktop linux target > -android 4.2.2 armv7 target > -saves snowloadcount report into a binary persistent storage file. > -has the the capacity to send summary via sms through qtjni support. > tested sendsms through qt and it works. > -does not load/view report on this, but can do it no problem. > -does not email report, but can do it no problem with android api or > through cpp libs out there like vmime and curl. > -androidmanifest file permissions are tricky and the qtcreator has bugs > with this respect. when you edit the androidmanifest within the gui, > they don't seem to get deployed properly so I needed to build by hand > using ndk_build and ant dist/debug. > -there is no mainwindow, there is only the wizardgui window. qtcreator > loves to generate a main window for desktop and android apps when first > going through their ide to create the app skeleton. mainwindow is removed. > -Time to create: a good week (5 days) > > Here is the c++/gtkmm version compiled for i686 linux: > http://adequatech.ca/gtksnowloadcount.tar.xz > Its features: > -builds on any manjaro,ubuntu, debian box > make -B -f Makefile > -saves the the snowloadcount report into a textfile persistent storage > file using standard boost serialization infrastructure possibly now part > of the ISO C++11 standard. > -no capacity to send sms because it's not on a smart phone, but ubuntu > touch has ofono scripts to send_sms so it could be possible to run this > gtk app on ubuntu touch/unity because it is gtk-based under-the-hood. > -loads/views a previous report in read-only mode. implemented using > boost serialization as mentioned before. > -does not email anything, but easily added with vmime/curl apis. > -there is no mainwindow, there is only the assistantgui(gtk's name for > wizard) window. > -Time to create: two days > >>From all this, I can easily say that I prefer building apps on the > desktop/server rather than on the android devices and on ubuntu touch > devices. There iteration time to build/debug/deploy with arm devices is > much slower than on desktop/server boxes. I have no patience for > slowness on mobile devices. Time is precious. The simulators for both > android and ubuntu touch still crawl considering you have to add in > android/ubuntu touch bootup time to a clean run session mostly everytime > to make sure everything is ok beforehand. > The lack of screen real-estate on touch devices implies needing more > pages to fill forms out which is something very common to do. QML and > it's declarative language are not for me. Too much automagic stuff > going on behind the scenes and it's not easy to decode what the qml is > doing and when just by looking at the qml code simply because qml is not > explicit enough for me. I prefer the c++ namespace and ada's required > explicity everywhere. qml/qt-declaratives are the reverse of everything > I learned about what's good for long-term software maintenance. C++ > with gtkmm is straightforward and no qtcreator/gui builder necessary. > Just coding it by hand gives exact results. > Compare the gtk makefile with the qt makefiles and judge which one is > easier to understand and to work with. > > I am going to rewrite the same app in golang with the go-gtk binding. I > can foresee it will be the most enjoyable to code. I enjoyed coding web > stuff with golang over any other language by far. IMHO golang is a > better c++. > > A few wishlist features although not part of gtk's mission: > -sending emails via gtk apis(non-gui and gui) with optional attachments > -sending sms via gtk apis(non-gui and gui) with optional attachments > -gtkmm for android > -gtkmm for ubuntu touch > > I send positive thoughts for a much brighter future for Gtk in this new > year. > > Cheers, > David Marceau > http://adequatech.ca > _______________________________________________ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
