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.

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)

8. Solution 1
Toolkit Wrapper

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

10. I tried go-qml
http://qiita.com/shibukawa/items/47cb0ea60bf4a7259b5e

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

27. Achievement Unlocked!

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

31. Solution 3
Hybrid Style

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