Go & multi platform GUI Trials and Errors
•Download as PPTX, PDF•
10 likes•5,457 views
This document summarizes Yoshiki Shibukawa's presentation on building multi-platform GUI applications with Go. Shibukawa explored several approaches: wrapping existing toolkits, creating a new toolkit in Go, and a hybrid C++/Go approach. While wrapping toolkits is intuitive, maintaining wrappers is difficult. Creating a new toolkit in Go allows perfect integration but supporting multiple platforms is challenging. The hybrid approach uses C++ for GUI with Go handling logic, which provides better integration but requires managing inter-process communication. Shibukawa concluded more work is needed to find the best solution and that GUI programming remains difficult, potentially requiring C++ involvement.
Go & multi platform GUI Trials and Errors
- 1. Go & multi platform GUI Trials and Errors Go Conference 2016 sprint @ 4/23/2016 @shibukawa (Twitter) github.com/shibukawa Yoshiki Shibukawa
- 2. Who Are You? • Programmer in Mobile Game Department – http://www.slideshare.net/dena_study/final- fantasy-record-keeper Yoshiki Shibukawa Languages C++/JavaScript/Python/Golang etc Japanese/English/Español (studying with Duolingo) Books Translations: Expert Python/Pomodoro Technique/The Art of community Original: Mithril, つまみぐい勉強 etc
- 3. Before talking my presentation… • Machine readable docs for web service API
- 4. Before talking my presentation… • Machine readable docs for web service API YES!
- 5. • https://shibukawa.github.io/curl_as_dsl/ • I will add net/http, fasthttp server code generate in future • Welcome Ruby/Perl/emacs lisp pull request
- 6. Conclusion • This presentation doesn’t show the best solution for multi platform GUI • I am exploring possibility about Go and GUI and creating experimental codes. • GUI programming is not easy • C++ is required
- 7. Solutions I tried Pros Cons Toolkit Wrapper The most intuitive solution Maintaining wrappers is extremely hard job Can’t use deploy support tool Create new Toolkit in Go Perfect matching with golang Supporting multi platform is very tough Hybrid (C++ for GUI, Go for logic)
- 9. Toolkit Wrapper • I used wxPython, Qt for JavaScript etc… • The most intuitive solution – You can use it in same methodology with original native language
- 11. Toolkit Wrapper Cons (1) • Qt provides deployment helper tool – macdeployqt, windeployqt etc – They collects required .dll/.framework and rewrite dependency paths and create installer etc – This tool works only for Pre build Qt/C++ project • Few documents/examples – We reinterpret original toolkit documents – C++ knowledge is required • Debug is very hard – Where does this panic come from?
- 12. Toolkit Wrapper Cons (2) • Maintaining toolkit wrapper is hard work – GUI toolkit is contains many C++ classes • Qt has more than 1200 classes – Many wrappers were discarded • QtJS, QtJambi, ruby qtbindings, go-qml etc… – GUI toolkits update continuously • Basically newer version is better • Almost all toolkit gave up updating • I have to update wrapper by myself to use newer future – Languages update too
- 13. Expect Hours Create My Application Maintaining Toolkit
- 14. Actually Hours Create My Application Maintaining Toolkit
- 15. Not all GUI toolkit wrappers are bad PyQt Commercial (Qt 5.5 supports) wxPython Nightly build still supports latest Python(2.7/3.5) GTK# Xamarin supports? pygobject or some libs gobject introspection is good for keeping fresh Swing from Jython/JRuby Using toolkit directly tkinter / Qt Quick Official wrapper provided by suppliers • Some wrappers provide updates continuously • Maintaining is too heavy for individual developer • Community/Organizational support is required
- 16. Solution 2 Create New Toolkit in Go
- 17. Implement GUI toolkit in Go • There are many small GUI toolkits in C/C++ – http://qiita.com/shimacpyon/items/e5d2a4e2019273345c37 • Port one of them to Go! – NanoGUI seems good to port ※ When start porting, I didn’t the existence of Shiny
- 18. GUI toolkit on GL building blocks Font Loader Font Renderer Texture Management Font Texture Management Event Handling Vector GraphicsImage Loader Widget Drawing OpenGLOS Window System Widget Management
- 19. NanoGUI toolkit on GL building blocks Font Loader Font Renderer Texture Management Font Texture Management Event Handling Vector GraphicsImage Loader Widget Drawing OpenGLOS Window System Widget Management stb_truetype.h stb_image.h NanoVG GLFW NanoGUI fontstash
- 20. My toolkit on GL building blocks Font Loader Font Renderer Texture Management Font Texture Management Event Handling Vector GraphicsImage Loader Widget Drawing OpenGLOS Window System Widget Management go’s image NanoVGo goxjs/glfw goxjs/gl NanoGUI.go
- 21. nanovgo
- 22. nanogui-go
- 23. Input Method Editor issue • IME support is needed to input Asian chars • Now IME becomes more generic than before – Voice / pen input uses same infrastructure – Modern OS treats IMEs as keyboards • This is processed in GLFW (C++ layer) Japanese IME English Speech Input Handwriting Input Operating System Application ※On Windows, Handwriting features seem to be a part of MS IMEs
- 24. IME support levels • Level 1: Root window mode • Level 2: Over the spot Images from http://www.mozilla-japan.org/projects/intl/input-method-spec.html ※This is not common classify. My original.
- 25. • Level 3: On the spot • Level 4: Context aware conversion Image from http://nyaruru.hatenablog.com/entry/20070309/p1
- 26. IME tasks viewed from Application Level 1 Level 2 Level 3 Level 4 Receive multi byte input ✔ ✔ ✔ ✔ Send cursor position ✔ ✔ ✔ React to preedit text ✔ ✔ Send surrounding text around cursor ✔ • To achieve higher level IME support, applications should communicate with IME more • Each OS provides each API for IME. I should add new method to GLFW to absorb OS layers
- 28. Current Status • Windows – Level 3. Now I use IMM32(old), but Text Services Framework (TSF) is preferred. – Old Chrome and Firefox use TSF (but MPL is not good for GLFW) • MacOS X – Level 3. Applications should implement NSTextInputClient protocol. I don’t implement Level 4 feature yet. https://github.com/glfw/glfw/pull/658
- 29. Current Status • X11 – Level 3. XIM protocol doesn’t support level 4. – On Linux/BSDs, there many input method frameworks (UIM, SCIM, ibus, fcitx etc) and Qt/GTK communicate with them directly, but don’t use them (not to introduce new dependency to GLFW) • Wayland – Not yet • Mir – Not yet https://github.com/glfw/glfw/pull/658
- 30. Future Plan • Improve GLFW more to support level 4 and Wayland, Mir • Reconstruct NanoVGo – Cache geometry – Now it redraw from scratch on every frame • Reconstruct NanoGUI.go – ListView support like QAbstractItemView / QAbstractItemModel – Better image resource handling
- 32. Hybrid Model Thin GUI Logic
- 33. C++ is not so fear than before • Use Qt via C++ directly – No wrapper issues – Using C++ is not tough anymore – C++11 is much better than 20 years ago – Qt5 supports C++11 (C++11 is required from 5.7) • But building code in Golang is still faster than C++ for me
- 34. C++ support tool • Go is easy to build. C++ is boring • I made helper tool to make C++ easy – https://github.com/qtpm/qtpm • Generate CMakeLists.txt. Support following IDEs: – Qt Creator – CLion (thank you for Jetbrains OSS support program) • It support the following commands like go: – qtpm get – qtpm build – qtpm vet – qtpm fmt
- 35. How to communicate? Thin GUI Logic ??? • I am trying several solutions for communication
- 36. Qt’s thread model • You should understand it if use Go with Qt • http://doc.qt.io/qt-5/threads-qobject.html • All Qt’s objects are belonging to thread – Calling object’s method from non-owner thread causes panic – To call other thread’s method, QMetaObject::invokeMethod is needed (signal/slot uses this behind it) – Each thread has event loop – Of course, blocking main thread is not preferred
- 37. 3.1: QProcess • Create standalone CUI program in Golang and call via QProcess class – If the job is simple, it is the best (it becomes simple code) • Bi-directional communication is tough – Receiving message in SLOT (callback) – No fluent code
- 38. 3.2: QLocalServer/QLocalSocket • Qt provides special wrapper to provides high performance inter process communication – On Windows, it uses named pipe – On other environment, it uses UNIX domain socket • Go implementation is ready – I tested on Windows and Mac • How to manage process? – I need to implement some process supervisor https://github.com/shibukawa/localsocket
- 39. 3.3: c-archive • Creating c-archive and link with Qt application • Go 1.7 will support it on Windows too
- 40. • If the API is simple, it is the best • All method is called synchronous by default • If callback from Golang to C++, it is little messy – Polling is easy, but not beautiful – Pass function pointer from C++ and call it in Go • https://gist.github.com/shibukawa/ab516964b0390cb2 34c7c42e5c9bfda1 • How to specify “-mmacosx-version- min=10.x”?
- 41. 3.4: dRuby style • dRuby is a my favorite API in Ruby • dRuby hooks method call and transfers method name and parameters via TCP/IP – Go: https://github.com/shibukawa/tobubus – C++: https://github.com/qtpm/QtTobubus DRbObjectClient hello(“world”) method_missing() DRbServer Actual Instance hello(“world”)
- 42. tobubus • Now it works on QLocalSocket/Server • It uses Qt reflection(QMetaObject/QMetaMethod) and Go’s reflect • Method call is serialized by CBOR – CBOR is almost RFC version of MessagePacktobubusC++/Go Client hello(“world”) Proxy C++/Go Actual Instance hello(“world”) tobubus CBOR on local socket
- 43. 3.5: gRPC • I didn’t try it – I don’t want to create extra interface definitions for communication • It is suitable for loose coupling of micro services – It seems difficult to use with Qt threading model • I may need create wrappers for all interfaces in Qt
- 44. Combinations of my solutions Infrastructur e Connect Pros/Cons Simple Teste d QProcess stdin/std out bi-direction is difficult Go is always running in other process (should take care QThread) S ✔ tobubus Not implemented yet A QProcess + QLocalSocket /Server tobubus It needs process supervisor C++ client code is not clean because of Qt thread model Go is always running in other process (should take care QThread) B ✔ c-archive linker Writing callback is little messy Windows doesn’t support until 1.7 It works synchronously S ✔
- 45. Which is better? • QProcess is the most simple now • tobubus + QLocalSocket/Server was originally designed for generic plug-in system. I already implemented but I feel too heavy now. • c-archive is a stable way. It is not bad if you can wait by 1.7 release.
- 46. Conclusion • This presentation doesn’t show the best solution for multi platform GUI • I am exploring possibility about Go and GUI and creating experimental codes. – I will still improve GLFW IME support to realize pure Go solution – If you can wait by Go 1.7, c-archive is better • GUI programming is not easy • C++ is required
- 47. Actually Hours Create My Application Maintaining Toolkit
- 48. In future I want to achieve Hours Create My Application Maintaining Toolkit