[HN Gopher] Lessons Learnt Moving a GTK Application from Go to Ada
___________________________________________________________________
Lessons Learnt Moving a GTK Application from Go to Ada
Author : ajdude
Score : 135 points
Date : 2022-03-11 11:10 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mftb wrote:
| I really liked this write-up and I'm getting curious about Ada,
| after completely ignoring it for a very long time.
|
| My impression of the Fyne toolkit was similar to the authors.
| Overall I'm disappointed in Go's gui situation. After a lot of
| screwing around with Go's various native gui bindings, I ended up
| using Webview again, which is a nice package, but has the
| standard shortcomings of the approach.
| mrlemke wrote:
| I have goofed around a little bit with GUI programming for Go.
| Fyne is incomplete, but I did find it relatively simple to slap
| something together. It may turn out to be a good cross-platform
| toolkit in the future, but I didn't like the requirement on
| OpenGL. Not my choice, but the utility needed to run on Windows 7
| and I don't like updating drivers on the machine (risky).
|
| Webview works ok, and you can get a lightweight Electron-like
| thing going that uses your existing browser. This reduces binary
| size greatly. I didn't try any JavaScript frameworks with it,
| just vanilla JS. You can bidirectional bind between JavaScript
| and Go too.
|
| What I liked the most was gothic, since Tk looks good enough and
| runs on Windows 7 easily. Gothic is a Tk binding for Go that is
| quite simple to use. However, you are writing the GUI in Tk now,
| and you will either love it or hate it. I do have a bias for Tcl,
| so it was appreciated.
|
| My use case scenario was supporting an old machine running
| Windows 7 with mediocre video. I ended up just using Tcl/Tk
| without Go since it was simpler and reduced a layer (Tcl->Go->C).
| When it comes to writing small and/or inhouse stuff, I found it
| easy and fast to just slap out a Tcl/Tk app and call it a day. I
| can develop on my Linux/BSD box and then just Windows specific
| bits if necessary and it usually Just Works(tm).
|
| Oh, it should be noted that Python + Tkinter is a decent
| alternative for those of you needing executables. Pyinstaller is
| basically a "one-click" and works with bundling Tkinter. Roy
| Keene has done good work putting together kitcreator for Tcl, but
| pyinstaller is simpler if you don't understand the magic.
| melony wrote:
| The easiest way is to just use the Flutter binding.
| mrlemke wrote:
| How's that?
| melony wrote:
| UI quality is much higher but the bindings are all third
| party software, not official Google products.
| paskozdilar wrote:
| Fyne seems to be the closest thing to cross-platform GUI that
| Go has.
|
| Fyne-cross is a really nice tool that can cross-compile Fyne
| applications for most popular systems (including android).
|
| The libGL1 dependency under Linux is a fair tradeoff for wide
| compatibility - the drivers don't have stable ABI so dynamic
| linking to libGL1 is a must[0].
|
| Python + Tkinter + Pyinstaller works, but does not support
| cross-compilation, and I've personally had some portability
| issues with it (e.g. under Linux, the GUI mainloop doesn't work
| outside of the main thread; under Windows, if you start a
| Process after setting up GUI, each process will create its own
| window, so you must start all the Process-es beforehand).
|
| [0] https://github.com/fyne-io/fyne/issues/512
| mrlemke wrote:
| Cross-compilation would be nice. I have used asyncio to allow
| the GUI to run in the main thread but have other processing
| done separately. I am not sure I understand why you are
| getting a new window on Windows. Were you trying to create
| new windows separate from the thread the root window is in?
| paskozdilar wrote:
| Actually, I didn't remember it right, it wasn't tkinter. It
| was probably some other popular GUI library. I just tested
| tkinter + threading/multiprocessing on Python 3.4.3 on
| Windows 7, and it works fine. I'm sorry for the false
| information.
| hujun wrote:
| I used to like fyne a lot, it is simple yet very extensible,
| much more approachable than other mainstream GUI binding like
| QT. however like OP mentioned fyne is not production ready yet,
| one key issue for me is IME support, it is based on glfw, and
| glfw doesn't have proper support for IME input.
| zerr wrote:
| No GTK 4?
| Conan_Kudo wrote:
| GTK 4 is not available on any released Debian version. The
| author stated he's working on Debian, so there's no way he
| could choose GTK 4.
| smoldesu wrote:
| Why would it be?
| pavon wrote:
| At the time the author started this port GTK4 likely hadn't
| been released at all let alone have bindings for languages like
| Ada.
| sp1rit wrote:
| > let alone have bindings for languages like Ada.
|
| Language bindings for any GObject powered are usually
| automatically generated from their introspection data (.gir)
| generated from g-ir-scanner.
|
| So that wouldn't be the issue.
| FredPraca wrote:
| The problem is that GtkAda is called a thick binding which
| means that a lot of C-like code is refactored to Ada-style
| one. So it's just not a simple generation.
| Jtsummers wrote:
| Thick bindings aren't refactored code, they're a
| different interface. "Thin binding" means a shallow
| interface, possibly even autogenerated from C header
| files. "Thick binding" is usually abstracted, creating
| proper Ada data types (including the normal restrictions
| on them), different functions and procedures (perhaps
| bundling common sets of activities that would be a series
| of calls in the base C library), adding Ada tasks if its
| sensible to the system (which it may be, like wrapping
| around a network library, you can have the network
| connection handled in its own task).
| FredPraca wrote:
| docandrew wrote:
| It's also worth mentioning that gcc has a command-line flag
| -fdump-ada-spec that will generate an Ada spec (.ads file -
| Ada version of a .h) from a C header for easy binding with
| C libraries.
| badhombres wrote:
| I'm curious why there isn't a push for more support in desktop
| gui for Go.
|
| Is it because desktop gui is not as supported in modern times and
| Go is a recent language that is carrying that attitude or is it
| because Go attracts more web developers in general and they
| already have web applications as their solution for a gui?
|
| Maybe something else?
| ainar-g wrote:
| In my opinion, there may be two types of problems.
|
| The first is organizational. Maintaining a cross-platform GUI
| library takes a lot of time, effort, and reasonable knowledge
| of the platforms it targets, so that would need a dedicated
| team of at least a few people. Which is not impossible, but you
| need to actually do this. The closest thing to such project
| seems to be Gio, but I haven't tried it, so I don't know if
| it's any good.
|
| The second is technological. Most ways of interacting with
| (native) GUIs involve FFI, and in particular C. And cgo has
| known limitations and performance issues, to say nothing about
| the fact that using cgo make cross-compilation significantly
| harder. So a lot of Go projects tend to just avoid any project
| that involves cgo.
|
| Again, that's just my opinion as a Go developer.
| throwaway894345 wrote:
| I've looked into building cross-platform GUI toolkits before
| and I think you're underselling the difficulty pretty
| considerably. To build these toolkits, you need expertise in
| everything from graphics programming to text rendering (which
| itself is surprisingly pernicious:
| https://gankra.github.io/blah/text-hates-you/) to
| accessibility and more. And then there are things which are
| just "regular hard" like constraint solvers for layout
| engines, designing a decent API, etc.
| badhombres wrote:
| Valid points about FFI. That makes me think if Go devs cared
| enough about Desktop GUI, then they would try to make that
| weak point stronger. Their focus is elsewhere (networking,
| cli tools, web) which doesn't rely on FFI as much.
| mountainriver wrote:
| Eh a lot of people have, the issue is with Go's memory
| model and how that maps to the C memory model. It requires
| what they call "trampolining" which caused a performance
| hit.
|
| Interestingly, Rust originally used a similar memory model
| to Go, but then when they hit this problem decided to take
| another route.
|
| This has the unfortunate side effect of making most machine
| learning also not practical in Go.
| throwaway894345 wrote:
| On the other hand, it has had the fortunate side effect
| of minimizing the amount of code which depends on C,
| which makes building and packaging software (including
| cross compilation) super simple.
|
| That said, I'd like to know more about the limitations
| regarding machine learning. Presumably most machine
| learning stuff isn't implemented in C?
| electroly wrote:
| PyTorch and TensorFlow are both primarily C++ codebases.
| oxplot wrote:
| There seems to be a POC that attempts to load dynamically
| linked libraries on linux (and elsewhere on windows) without
| CGO: https://github.com/golang/go/issues/18296#issuecomment-4
| 6847...
| usrbinbash wrote:
| IMO, it's because the primary use case for Go isn't GUI
| programming.
|
| The language absolutely is a generalpurpose language, and
| making great GUI libs with it is certainly possible, as shown
| by Fyne (yes, I know it's still new, give it time).
|
| That being said, most people using Go build server side code
| and frameworks with it, aka. things that live as daemons in
| some rack or in a docker swarm. If there is an front-end to
| these kinds of applications, it's usually web based.
| Thaxll wrote:
| One thing is probably that FFI in Go is not on the same level
| compared to other languages, so binding to existing in C/C++ is
| not that popular.
| henning wrote:
| > There does not seem to be a generally agreed-upon central
| repository for such information in Ada.
|
| There's https://alire.ada.dev/ which is sort of like NPM or Rust
| crates for Ada. Obviously the number of libraries is much lower
| and the quality may be unpredictable.
| pyjarrett wrote:
| It's being built up a bit at a time and some of the older more
| mature libraries have been or are being put into it.
| benibela wrote:
| I have been doing my GUI programming in Pascal
|
| Lazarus was a great crossplatform GUI framework to have a native
| GUI on each platform. You put a button on a form window, and then
| it calls Win32 on Windows, Gtk on Gnome, Qt on KDE, ... to get
| their native button.
|
| Unfortunately, it is really lacking maintainers. It still works
| best on Gtk 2. They have been working on a Gtk 3 version for
| years. I am not sure if they have been making any progress. I
| guess the modern way for a Linux GUI is to have a Qt5 version or
| a Win32 version on WINE.
| Arnavion wrote:
| Qt is at Qt6 now, haha.
| benibela wrote:
| I know, but Lazarus does not support that...
| lights0123 wrote:
| Qt6 still doesn't have a lot of modules ported to it though,
| as it really hadn't been around that long.
| jcelerier wrote:
| since 6.2 most of the big qt5 modules are ported I believe
| Arnavion wrote:
| Yes, though qbittorrent at least has moved to it / supports
| it, which is how I found out about it. After an update it
| started with a completely different theme, and eventually I
| realized it had switched to Qt6 and I needed to install the
| Qt6 version of the theme.
| badsectoracula wrote:
| You can also use the Qt5 backend for Lazarus, AFAIK many people
| use it instead of Gtk2 despite the latter being the default.
| One annoyance with that is that you need to either distribute
| or depend on the qt5pas library which acts as an intermediate
| between Qt and Free Pascal, but that might not be _that_ big of
| a problem since AFAIK it is now available in all major distros.
|
| About Gtk i'm not sure if it is lack of maintainers or simply
| lack of interest in the Gtk3+ backends, i remember a discussion
| from not too long ago in the mailing list where people weren't
| happy with the breakage introduced by Gtk every major versions.
| It can be very disheartening to spend years building the Gtk2
| backend only to have to make a new one for Gtk3 and before that
| is finished, out comes Gtk4 breaking things yet again.
|
| But IME the Gtk2 backend works fine. At least personally i
| wouldn't bother with Gtk3 or Gtk4 as these feel like a waste of
| time now (though personally i did submit a patch recently with
| fixes for the Gtk1.2 backend[0] that didn't work for some time
| now :-P but that was mainly for fun - there might be some
| practical use for it though as all the necessary .so files are
| like ~2.5MB, so perhaps it could be used for simple GUI apps on
| Linux to minimize external dependencies).
|
| [0] https://i.imgur.com/OM8bC9i.png
| Arnavion wrote:
| One benefit of GTK3+ is Wayland support, since GTK2
| applications only support X11. But most of your Wayland users
| also run xwayland, so this may not be a big deal for you.
| jonpalmisc wrote:
| I love doing UI programming in Pascal, but I miss sane build
| systems and package management from other languages when I use
| Lazarus or Delphi.
|
| If Lazarus were more popular and had a better library
| ecosystem, I'd probably use it a lot more.
| benibela wrote:
| Unfortunately, they seem to have the attitude: we have
| standard libraries. Any library you need is already bundled
| with the default install of FPC/Lazarus
| badsectoracula wrote:
| For Lazarus at least you can download and install packages
| from inside the IDE using the Online Package Manager found in
| the "Package" menu.
| oxplot wrote:
| My Archlinux installer [1] uses fyne and I found it to be quite
| easy and straightforward to use. My use case is quite trivial
| though so not sure how that scales.
|
| [1]: https://github.com/oxplot/raspberrypi-archlinux-installer
| dbotton wrote:
| I'd take look at GNOGA for Ada (or CLOG it's Common Lisp brother)
| to future proof your GUI.
| cdelsolar wrote:
| Has anyone used Wails? Would this be a good choice? It looks
| great: https://github.com/wailsapp/wails
| ainar-g wrote:
| A reasonable write-up. I would really like them to elaborate on
| what GUI libraries besides Fyne they used and what issues they've
| encountered. Gio[1] has been fairly popular, and Tailscale's
| Android client is written in it, iirc.
|
| [1]: https://gioui.org/
| davb wrote:
| The demo on the Gio page is badly broken for me (Chrome 99 on
| Windows 10) - it's mostly black, with what appears to be a text
| area in the middle with black text on black background. Triple
| clicking text doesn't work. There's no right click menu (as in
| native text areas) to show copy/paste/select all. There's no
| visible scrollbar so it wasn't obvious I could scroll down to
| see more UI controls.
|
| Overall it's a terrible advertisement for the UI toolkit and
| seems typical of most immediate mode GUIs.
___________________________________________________________________
(page generated 2022-03-11 23:02 UTC)