GUI frameworks - on stream

    Greetings, colleagues!

    A couple of months ago, I started looking at Golang in order to use it for desktop applications. I liked the language, the volume and the subject of the packages written for it made an impression, but the situation with the GUI is not so rosy. I will not dwell on the details now, it will suffice to say that after reading a few reviews and a quick look at the existing GUI packages I decided to write my own - especially since I have experience in this.

    My first thought was to go along the already beaten path: write a set of relevant functions in C, more precisely, adapt the ready one — what I wrote once for Harbor and C ++, make a link to it using cgo (C API for Golang) and friendly wrapper. I even started to do it, I received the first window, but as I imagined, there was still a lot of work ahead, separately for Windows, separately for Linux, purely technical work, since I was already passing through, my enthusiasm had cooled down a bit.

    And then another idea came.

    I already have a GUI-library, HwGUI for Harbor, quite functional, cross-platform, which I regularly use for my applications. It has already implemented everything that I need. Why not write on its basis a program that works as a kind of GUI-server. After starting, this server will silently listen to a certain port, and, having received a connection from my Golang program, in response to its requests, will create windows, widgets, manipulate them and provide feedback when any events from the widgets occur - in short, implement a GUI for it. All the low-level GUI implementation details are already in the library, for Windows - through direct WinAPI calls, for Linux / Unix and, probably, macOs - via GTK. In addition, I do not intend to make the server in the full sense of the word, it will not accept connections from different programs - this would introduce additional unnecessary complications. Each instance of the Golang program will launch its own separate instance of the GUI server, which further simplifies the task. In general, the program will therefore consist of two processes, one of which performs the main task, the other is responsible for the interface.

    The appropriate package for Go should include an Init procedure that launches and attaches a GUI server, and a set of structures, methods, functions for creating windows and widgets and manipulating them. The main content of all these functions is sending messages of a certain format (based on JSON) to the server and receiving messages from it. Communication is maintained using two tcp / ip ports, one responsible for sending requests to the server, the other for receiving signals from the server to handle events (pressing a button, closing a window, etc.). The task is relatively simple, the package itself is small. You do not need to use cgo, you do not need to bind to third-party libraries, all the code is on pure Go. The executable file of the program itself and the executable file of the GUI server are everything.

    The choice of Harbor + HwGUI for implementing a GUI server for me is primarily due to the fact that these are my “native” tools, the simplest and quickest solution. But it is a good choice from other points of view. Here, in my opinion, the main advantages:

    • cross-platform "in the box";
    • what is called the native look and feel, since under Windows these are exclusively WinAPI calls, under Linux / Unix - GTK; I don’t really know how “native” GTK for macOs is;
    • the ability to use Harbor as a built-in scripting language; fragments of code can be sent to the server for execution — event handlers, for example, which can unload the main program from some implementation details. In addition, Harbor is good for many things, for working with dbf and some databases, for example;
    • implementation of printing;
    • possibility to use screen forms created by the Designer (HwGUI utility). These forms are stored in XML format and can be used without changes in any OS in which the server is running;
    • the ability to use the report forms created by the same Designer for printing (also in XML).

    In short, I started doing this and much of the work has already been done. Both projects, GuiServer and Golang External GUI-framework - on Github, all links at the end of the article. Below is a couple of screenshots. Nothing special, just tests.

    This is a simple dialog box:

    And this is done on the basis of an example from the book by Kernigan and Donovan:

    Now the main goal of the projects is to ensure that this sweet couple, External and GuiServer, can do everything that HwGUI can. Well, in the course of creating some real-world applications that use External, it will be clear what else is needed.

    At this point it would be possible to finish; I postponed the description of the Golang package for another time. But the main thing in this article is just beginning. After all, the described method of implementing a GUI framework with the same GUI server can also be used for other languages. C, Python, Java, ..., even Perl and PHP (and why not?) - see the article title. Low cost - and quite functional GUI solution is ready. The most difficult thing for each specific language is not the implementation of the exchange with the server, but the fact that this solution fits in perfectly with its paradigm, its internal logic. If anyone wants to create such a framework for their language, I will try to provide all possible assistance in obtaining the necessary information and, possibly, in adding some features to the GUI server.

    In parallel with the Golang package, I made an analogue for Harbor, mainly for verification / debugging purposes. The Perl framework is unlikely to be done, but for C or C ++, it is quite likely. And here's why: there is one more interesting possibility connected with the use of a GUI server, it can be run on another computer. The main program runs on one computer, and its interface runs on another. Immediately see these options for using this case:

    • the main program runs on a Linux / Unix server on which the graphical shell is not installed at all;
    • the main program works on another computer (from a conditional accountant in your company), and you, without interfering with it, manage it on your own;
    • the main program runs on a smartphone, and you dig from a normal computer in its guts;
    • the main program works on the controller, on Arduino some, Raspberri or their analogues, where there is no normal monitor, maybe. Connect with your laptop - and go.

    For this last option, perhaps, a C-framework under a GUI server would be useful, this possibility seems to me very promising.

    And finally, the links are: - GuiServer on Github - External (Go package) on Github - the GuiServer page on my website here you can download ready-made binaries - my article on Harbor is here on Habré - Harbor on Wikipedia - the Harbor page on my website
    www. - HwGUI page on my site

    PS: It is clear that there are very few people who will install Harbor and HwGUI to build GuiServer from source, so I’ll post the compiled binaries on the GuiServer page on my website for Windows, Debian 8 32-bit, Ubuntu 18.04 64-bit. I can collect for Fedor, but under macOs - alas, I don’t have it within walking distance.

    Also popular now: