GUI means graphical user interface, and Gekko can be divided into two parts: the engine (core modules), and the GUI. Gekko tries to avoid too much clicking and pointing, instead offering a well-functioning syntax. Some software packages allow all operations to be done via menus and point & click, but we believe it is better that the users get used to a comprehensible command language that takes care of most of the functionality. In that way, sessions are easily reproducible, since it is just a question of copying the command code lines.
In principle, most of Gekko’s core functionality could run as a console application, that is, it could run without a GUI. Just state the commands in a command file, and have Gekko output a text file with the output (and perhaps some Gekko databanks, too). This would run on Mac and Linux, too. But it would not be a particular funny version of Gekko, since the graphing window (PLOT), the decomposition window (DECOMP), the nice tables (on the ‘Menu’ tab), the databank window (F2), the job status window etc. would be absent.
So in conclusion: Gekko does not work well without a GUI. As mentioned in the previous post, C#.NET was chosen as the software platform for Gekko, and the main Gekko GUI windows were originally made in WinForms. That is a tested technology, and when creating the main window in Visual Studio, I noticed that other modules were possible, using something called WPF. That sounded complicated, so I stuck with WinForms which I knew from previous work. I didn’t think much about it, but perhaps I should have.
A few years later, I was designing the DECOMP window, and I had a new look at WPF. It is indeed a bit more complicated, using something called XAML for the design, but actually XAML felt a bit like HTML, so it did not feel that foreign. The window ended up looking great, and much better than would have been possible using WinForms:
So the result was indeed really good and modern-looking, and subsequently I started using WPF for new windows in Gekko (which is at the moment using a mix of WinForms and WPF). One good thing about WPF is that it uses vector graphics, animations, etc., but most important is that it scales well on different screen resolutions. With the advent of retina screens (for instance screens with almost 3000 x 2000 pixels), this is important. Already now, on some large-resolution screens, the menus and letters in the Gekko main window become very small. You may actually zoom the text inside the Gekko window, but the menus and icons look like miniatures on retina screens. WPF can handle resolution independence, and even though WPF has a steep learning curve, it seems like a mature technology. After all, the GUI of Visual Studio is made in WPF!
All this led to what is the real question of this post: if WPF is the way to go, where does that road lead to? A few years ago, I was worried that Microsoft might abandon WPF at one point, and I started reading a lot on the perceived future of WPF. To confuse matters even more, at that time Windows 8 was being released, and suddently there was the question about how the Windows desktop would look like in the future? Would everything be made into Metro-style apps looking like this:
Metro for Windows does look good, and at that time it seemed that Microsoft wanted people to switch to WinRT for GUI building. People started talking about WPF dying, and being replaced by WinRT, but now (2016) it seems that WPF is (still) very well alive regarding desktop applications for Windows, whereas WinRT is intended for mobile devices/apps.
It seems that over the years since WPF was conceived, Microsoft has had varying enthusiasm for the technology, at times more or less abondoning further development. But it is still here, and more and more people are using it for desktop applications (whereas WinForms are slowly dying). So it seems that WPF is a reasonably safe choice regarding GUI development on Windows, and that the technology is here to stay for the foreseeable future.
Conclusion: The Gekko main window will be ported from WinForms to WPF, among other things in order to be able to support high-resolution (retina) screens. This will probably happen soon, but I’d probably better read a good book on WPF and XAML first. Suggestions regarding such a book are welcome!
Edit: After writing the above, mostly from memory, I read some more about WPF, more specifically these two posts: