Why not use QT backend for Unix? about ui

[gour]

Probably because it is easier to bind to than C++ library...however, I also believe that Qt is better option today.

[andlabs]

Several reasons:

• I didn't want to lug around a large C++ dependency (GLib/GTK+ may be somewhat large but they aren't nearly as massive binary-wise as QtCore/QtGUI by themselves)
• Qt already does everything package ui aims to do (this is a weak argument, since I am using GTK+, but)
• existing Qt bindings for Go are not compatible with the go tool; I wanted to keep go tool support in mind
• Qt is not actually a native platform toolkit: it draws everything itself on all platforms (only not an issue on Unix systems)
• my experience with Qt on Mac and Linux is that it works fine; but my Qt software on Windows would crash consistently doing things other Qt programs can do just fine (like right-clicking on a text box)
• installing Qt on a system where it isn't provided by a system software repository has always felt somewhat clunky to me (especially when crossed with juggling other MinGW installations on Windows!)
  • related: I figured not all Linux distributions would necessarily come with Qt, but most, if not all, would come with GTK+, since more DE-agnostic tools would use GTK+; I'm not sure how true this is (might as well switch to the X Athena Widgets if I really wanted out of the box support on Unix! =P )
• I'd rather not use QML

That being said, Qt has served as an inspiration for some things, namely the layout object-based widget layout system (Rather than fixed positioning). Its QFormLayout is something I also want to implement (will need to add Label vertical alignment first...). I have used it in the past for projects that are not on github (and cannot be uploaded due to using a nonfree component (1998 MAME's YM2612 emulator core)).

However, I have no intention of dropping everything for Qt now that the project is this far in. Sorry.