What direction should we take with the ApsimX GUI?

[zur003]

I've been looking into the cross-platform operation of ApsimX, and thought this might be a good place to jot down some of my thoughts and observations, and also solicit the views of others.

The current GUI, based on Windows Forms, works reasonably well on Windows (as expected, though there are still a few rough spots), but rather poorly on Linux or Macintosh. My (admittedly limited) tests on Linux indicate rather poor responsiveness, the need to use a version of ICSharpCode.TextEditor more recent than that available via NuGet, and poor (that is, slow and with incorrect layout) display of the summary file. The situation is similar on the Mac which, although more forgiving in use of the TextEditor, tends to fail completely on any attempt to view the summary file. For both Linux and Mac, the worst performing aspect of GUI performance currently is the display of the summary file, which is implemented via an RTF representation. I'd like to see us get rid of this in any case: RTF is a difficult format to use. HTML would be much better, if we can find a suitable rendering engine that works across platforms.

If we really want to achieve good cross-platform performance, I think we would need to move away from Windows Forms completely, and move to GtkSharp. With GtkSharp, we should have access to the various controls we need with decent cross-platform support. These include: tabs, trees, grids, charts (Oxyplot has a GtkSharp implementation), context-sensitive code editing (using Mono.TextEditor from MonoDevelop). I'm a little less certain about rendering "rich" text, but I think cross-platform HTML rendering under GtkSharp should be possible via WebKit.

So the positive side of moving to a GtkSharp-based GUI would be a much better cross-platform experience. But there are negative sides as well. Here are a few I can think of:

1. Installation is likely to be much larger and more complex, as it would likely require installing the GtkSharp framework, WebKit, etc.
2. No one currently working on ApsimX has much GtkSharp experience (that I'm aware of), so we would all be facing the cost of learning a different technology. A lot of things work quite differently from their Windows counterparts (how controls are positioned; how the content of a tree control or grid is held and described).
3. There may be versioning issues. The underlying Gtk technology is now at version 3, but most GtkSharp support is at version 2, or currently migrating to version 3. (I suggest we start with version 2, and transition to version 3 only when it is more broadly supported.) There may also be some risk of DLL version conflicts with previously installed versions of Gtk.
4. There is no interface designer for GtkSharp that can be used from within Visual Studio. Interfaces would either need to be created completely in code, or using the Stetic designer included in Xamarin Studio (aka MonoDevelop), or via the stand-alone Glade designer.
5. Oxyplot works well under GtkSharp with one odd exception: tooltips don't seem to work. These are nice to have on plots, but this probably isn't a show-stopper, and it's likely that there will be a working implementation in the future.

[hol353]

This is good Eric and what I was expecting

If we were to move to using GtkSharp, what would be the strategy? Is there an iterative way to do it or does someone down tools for 3(?) months and just do it?

[zur003]

I don't see any way to do this in a nice stepwise fashion, beyond starting by setting up a simple test framework or two to make sure all the bits and pieces we want to use actually work nicely. We wouldn't want to invest substantial amounts of time in porting stuff only to find that it doesn't quite do what we want. I'm still a bit uncertain about rendering HTML, for example, or the details of setting up a text editor with intellisense capabilities.

[HamishBrownPFR]

Speaking from the point of view of a windows user and someone who has endured pain in helping progress the current UI to a usable state... I am not keen to throw away what has done already until the alternative is working at least as well. However, provided that the UI works well I don't really mind what technology it is built upon. It would be easy enough to develop a 2nd UI in parallel to the current one until it is ready to replace what we already have??

It strikes me that there are two development imperatives that are in conflict here. 1. The desire for APSIM to work cross platform (which is important). 2. the desire to have a clean and tidy development platform (which is also important). Currently all facets of APSIMX can be worked on from Visual studio in the same .sln file and the build, release procedures seem to work nicely. I have no real expertise in this but I wonder what pain we could be setting our selves up for if we start cobbling multiple platforms together again as we have done in the current version of APSIM.

[zur003]

Good questions, Hamish.

I'm still trying to get a good understanding of how all this stuff works, but what I hope to do is to develop a second GUI in parallel with the existing one. That shouldn't be too overwhelming a task. After all, a major reason for using the model-view-presenter paradigm is that it should be relatively easy to swap out one view and replace it with another. There should be no reason to pull the plug on the current Windows.Forms GUI until a substitute is fully functional (if that ever happens).

The question of development platforms in an important one. The main contenders for a suitable IDE are Visual Studio and Xamarin Studio (aka MonoDevelop). Both can use the same .sln files, and compile the same code, but there are a few differences. The APSIM development team is already familiar with Visual Studio, the community edition is free, and it integrates with lots of other stuff, so there are good reasons to stick with it. MonoDevelop is also free and works pretty well, but also has an integrated designer (named "stetic") for GtkSharp development, whereas Visual Studio does not. However, the stetic designer currently supports only Gtk 2, not Gtk 3. I think we're probably better off targetting Gtk 3, so that kind of eliminates the main advantage of MonoDevelop. At this point, I'd recommend sticking with Visual Studio on Windows, but using MonoDevelop if your normal work platform was Mac or Linux.

One reason for preferring Gtk 3 over 2 is that the support libraries for it are readily available via NuGet, so it's pretty easy to get started with it in Visual Studio. Gtk 3 also seems like the way to go if we're keeping an eye on the future.

As I mentioned, there is no integrated form designer for GtkSharp in Visual Studio. A developer has a couple of alternatives. It is possible to do all the design work non-visually, and construct everything using code. This would be similar to constructing WinForms Designer.cs files by hand. You would have a lot of control, but it's tedious work. The alternative is to use Glade, a stand-alone forms designer which generates an XML description of the form contents. The resulting XML can be embedded as a resource in an application, then used to initialize a form using only a couple of lines of code. The Glade approach is the one I'm currently taking. (There are Windows versions of Glade for both Gtk 2 and Gtk 3; these can both generate two different XML formats [libglade and GtkBuilder]. I'm currently trying to do development using Gtk 3 and the Gtk Builder format.)

I'm hoping to play with this for a few weeks and see how far I can get. The learning curve is reasonably steep...

[zur003]

As a early step towards making this work, I'm going to try to remove use of the WIndows.Forms namespace from everything except the Views in UserInterface. The hope here is that it will be possible to use the same Presenter source for both the Windows.Forms and GtkSharp versions of the GUI. This may require a small bit of refactoring.

[steelheaddigital]

Have you all considered something like Electron along with edge.js for the .NET integration? Seems like a perfect use case for these technologies. This would give you a truly cross platform UI including Web and mobile all done with common web technologies that many developers are already familiar with.

[hol353]

Rather than having an ApsimNG directory that duplicates everything in the user interface folder, it would be good to only have the files that are different. For example, I notice in the presenters folder under ApsimNG, there are many files that are the same as the one in the presenters folder under user interface. The same probably applies to some of the other folders under ApsimNG.

Is this doable?

[zur003]

That would be good. I've tried to keep the differences between "UserInterface" and "ApsimNG" as small as possible, which means most of the files in the Commands and Presenters folders are identical, or nearly so. It should be possible to use links for the identical files. I've been waiting until I get to the point where ApsimNG is being built during the Jenkins tests. It's nearly to that stage, but the build machine will need to have the Gtk libraries installed on it first.