Where to we go from here with the ApsimX user interface #4381
Comments
|
Wow, appreciate all your work looking into this. I feel a pang of guild for even mentioning .Net Core. |
|
@zur003 Great work and thanks for the analysis! Happy to discuss this in Canberra next week. My view is that while there aren't many people using APSIM on Linux or MacOS, there are some. There were 3 people on Macs in Iowa that I was helping while I was there in July. I also know Jeremy Whish uses it quite a lot on his Mac. Forcing them to do this in a VM is somewhat painful for them. There are probably others. I would like us to retain cross platform support for APSIM, including the GUI. It is a great selling point when I give presentations! I was looking at the code for HTMLView a couple of days ago. Terrible, but I understand why it has been implemented that way. I would love to find an alternative, even if it is just a rich text view. Another source of frustration is the grid control (treeview in Gtk). It is only just acceptable with lots of hacks in the code to get it to function somewhat they way we want. Two options that haven't been mentioned so far:
|
|
In response to @hol353: Basic "rich text" would lose our mapping capability. For what it's worth, the Webkitgtk support that I've found for Windows currently displays the summary and model descriptions correctly - it fails with the mapping (and in other contexts where Javascript is used heavily so, for example, it doesn't render www.apsim.info particularly well). The Gtk 2 treeview admittedly makes for a very clumsy grid control. I don't think Gtk 3 will help matters here. It introduces a "Grid" widget, but that's intended for use as a layout container, not as a spreadsheet. I should look into recent developments with gtksheet. It didn't used to work very well, but it appears to be under active development, and things may have improved. Using gtksheet would require writing the bindings for .Net, but that might not be terribly difficult. Qt has a very rich set of controls, although it is designed for the C++ world rather than the C# one. It might (or might not) work well, but porting to it would require substantial effort. There's no need to write a "rich text" control. The Gtk Textview control can already handle a lot of that. |
|
Thanks for the detail, @zur003 - it's good to be so well informed. I'd strongly advocate for a native mac solution - the majority of my colleagues and a high proportion of students (~30%) are mac users; and increasingly many have never come across VM applications like parallells, and asking them to install the VM in addition to apsim is even more burdensome. On the converse - most linux users are well conversant with VMs, perhaps because Linux GUIs have always been a sorry joke. Many years ago, the WxWidgets people did native L&F cross platform GUIs successfully, but only succeeded due to a high abstraction level which made "nice" customisations difficult - so the resulting UI always looked bland - a lowest common denominator. WRT textviwers - it seems we'll be forever catching up with browsers if we focus on html. If we really want to surf that wave (eg a solution like electron), we'd be up a massive cost of re-tooling our UI, yet have a better (yet non-native) L&F. The much cheaper option of a markdown processor would still be able to turn our documents into something readable. I know we've got a map component, but has anything used it yet? I did some work on map data aggregators and soon found the bulk of the work relied on connecting a web datasource some form of customised popup - and html had been doing such async work for years. Its almost like they wrote it just for that task.. |
|
From the apparent lack of development of true cross platform UI tools would
it be fair to say that most of the work being done regarding UI is for use
in the browser?
If you look at some of the larger UI tool providers (DevExpress, Telerik)
they are Windows first, and then Javascript in the browser.
Is there any reason we couldn't use something like electron to provide
desktop capabilities to a web driven UI?
I haven't played with it much myself as yet, but 'in the browser' seems to
be the direction that cross platform support is heading.
Thanks for your work on .NET core 3 support Eric - very appreciated, and
being used.
…On Thu, Nov 21, 2019 at 9:02 AM Peter de Voil ***@***.***> wrote:
Thanks for the detail, @zur003 <https://github.com/zur003> - it's good to
be so well informed.
I'd strongly advocate for a native mac solution - the majority of my
colleagues and a high proportion of students (~30%) are mac users; and
increasingly many have never come across VM applications like parallells,
and asking them to install the VM in addition to apsim is even more
burdensome. On the converse - most linux users are well conversant with
VMs, perhaps because Linux GUIs have always been a sorry joke.
Many years ago, the WxWidgets <https://www.wxwidgets.org/> people did
native L&F cross platform GUIs successfully, but only succeeded due to a
high abstraction level which made "nice" customisations difficult - so the
resulting UI always looked bland - a lowest common denominator.
WRT textviwers - it seems we'll be forever catching up with browsers if we
focus on html. If we really want to surf that wave (eg a solution like
electron <https://electronjs.org/>), we'd be up a massive cost of
re-tooling our UI, yet have a better (yet non-native) L&F. The much cheaper
option of a markdown processor would still be able to turn our documents
into something readable.
I know we've got a map component, but has anything used it yet? I did some
work on map data aggregators and soon found the bulk of the work relied on
connecting a web datasource some form of customised popup - and html had
been doing such async work for years. Its almost like they wrote it just
for that task..
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4381?email_source=notifications&email_token=AAE3G7F5XRLGZJ2OULZZATDQUW6YXA5CNFSM4JPM6T4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEV5R3I#issuecomment-556521709>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3G7EWCR5OCLAVGJJRL43QUW6YXANCNFSM4JPM6T4A>
.
|
|
A solution may have presented itself to one problem: WebWindow has just been released on NuGet and looks like it might handle the cross-platform browser problem. The approach is similar to what we're doing currently (wrapping native browsers on each platform), but packages it more nicely. Also I've been playing with GtkSheet, an add-on to Gtk which provides a spreadsheet-like widget. This now works under Windows. The main problem with it is that is requires a native binary for each platform. |
|
@zur003 do we really have to build a wrapper for the gtksourceview? There seems to be a .net wrapper already out there - it has its own page in the mono documentation. We don't seem to have access to this namespace currently but I'm guessing that's just because we don't have the source view binary sitting next to the other gtk binaries. |
|
@hol430 - I think the Mono documentation is for an early version of gtksourceview, prior to the introduction of useful stuff like code completion support. It would also have been for Gtk 2 rather than Gtk 3. |
|
@zur003 I've checked out the netcore3 branch but it seems like .net core 3 isn't supported by vs2017? Do I need to upgrade to vs2019 to work on this branch? |
|
That is correct - .Net Core 3 requires VS 2019. |
|
Intelicode and other features are worth the upgrade. |
|
@hol430 - Just a word of warning: If you check out the netcore3 branch into the same directory tree that you normally use for building ApsimX, then switch back to a Framework based branch later, you are likely to get cryptic error messages when doing a build with Framework. The solution is to totally purge the "obj" and "bin" folders for each project. This seems to happen only when going from a netcore3 build to a framework build; going the other way doesn't seem to present any problems. |
|
Yeah in the end I just opted for a 'nuke everything' approach with |
|
@zur003 did you end up looking into the webwindow component? I had a bit of a play around last week and managed to get a barebones version of our ui running on .net core/gtk3 but couldn't get the webwindow to play nicely. Also worth noting that webwindow requires the developer's version of edge to be installed in order to work at all on windows. |
|
@hol430 - I didn't look very deeply into WebWindow, but I kind of got the impression it was more suitable for creating and controlling a browser window from a console program rather than for proper embedding. That is, I don't think it would allow the browser to be hosted inside a Gtk window, which is what we need (if possible). But I could be wrong about that. |
|
Yeah that's what I found as well. I had a brief look into cef but couldn't find much in the way of documentation |
|
@zur003 @hol430 Isn't the WebWindow approach just a lightweight approach to the same way Electron works? |
|
@zur003 have you looked into the graphing side of things? It appears that the OxyPlot.GtkSharp3 package is based on the .net framework version of gtk#3. |
|
Well, it is open source, and I had no problems compiling a version for .Net Core 3. |
|
Time for an update: #1: We have to move to .NET core. The quickest way to get to .NET core is to keep using GTK# but upgrade to version 3 which supports .NET core. This is much simpler than switching to Electron or another technology. One of the hold ups to this was the use of HTMLView which isn't supported in GTK#3. To this end we have moved most (all?) our GUI code away from using HTMLView. The notable exception to this are the CLEM views. Ways forward:
@lie112 : thoughts? |
|
If you're spending effort upgrading to a newer technology, why not upgrade to the most modern technology - electron? |
|
Hi everyone, My hope had always been that CLEM sat in the background and never caused any problems, just adding extra functionality to others along the way and identifying areas of improvement, optimisation and generalisation. My reason for using HTML in CLEM for the descriptive summaries was because other summary documentation approaches were not mature in APSIM Next Gen three years ago, I wanted a professional, colourful display providing a standard look and feel across the CLEM environment within APSIM Next Gen, there was a HTML viewer already being used in APSIM that fulfilled the role, I was able to leverage off the full capabilities of css including simple plots, it allowed an instant simple dark/light theme implementation, and I assumed a HTML view would always be one of the the safest and most compatible approaches into the future. WRONG ON LAST POINT It seems the cross platform UI development from Microsoft (and others) is lagging behind the Core and Standard code and this is our dilemma. I can see we're a couple years too early in needing the linked UI to the model core across platforms. I think there will be much more interest in running CLEM at the same time as ASPIM crops and pastures in future as many current users are using APSIM results as input into CLEM with no feedback between the models, so I suggest CLEM remains with the current build, but what with the HTML? Plus, I want access to the latest C# and Core coding conventions! I haven't looked into future HTML view options that might be on the way. The pages being displayed are static (after clicking tree) and don't contain hyperlinks etc. I am not sure if they could be converted to RTF or something in the meantime (if there was a viewer). Was there talk that the HTML view may work on Windows machines? I am not sure how many CLEM users are on macs, but restricting CLEM to Windows might be a start (no descriptive summary on iOS, Linux). Otherwise I guess we could use an external browser to display the information outside the APSIM UI, which is not ideal but an interim approach. I am less inclined to spend time and effort on converting the CLEM summary descriptions to GTK components as I see the UI being one of the more fluid aspects into the future and love the separation of model and UI, and never liked GTK. In future I can see web apps interacting with servers for APSIM. They are my thoughts and only solutions I can think of. Any choice of future UI direction can potentially have large costs and something with least change to present is desirable at present. Unless the process of building the entire VIEW component in Electron or equivalent was simple and provided vast improvement in functionality and look and feel I am not sure it's worth it at present. |
|
I also think that html is a better choice for our future direction and if progressing to a newer version of GTK3 is going to remove that then I don't see that as a step forward. I didn't realise that we were moving away from htmlview for this reason - apologies for not understanding that earlier. I realise that a much larger investment of time and resources will be needed to move to a different tech rather than upgrading the current one. At present that will fall heavily onto Drew and yourself, but I think it will be easier to find people who have html skill or would be willing to invest time in developing skills in html rather than GTK - I know that I'm one of them. I think the number of existing components and tutorial code out there for html has to be orders of magnitude larger than GTK which should also be a consideration. Our front end (views) should be able to be separated from the presenter/model code - so with the release of .net5 shouldn't we be able to run the existing gtk interface on top of .netcore? I know this wasn't possible before, but it should be now? |
We might need to rethink our use of grid controls. The problem though is I can't see a way of visualising a soil profile without using a grid control of some sort. |
I haven't managed to find anything that works but I'll admit haven't really looked into a windows-specific solution. It seems that there are four options:
From where I'm standing, the third option seems like the least bad option. Not entirely sure why you guys don't like gtk - yes there's a learning curve (as with anything) but I've found the documentation to be pretty good. If there are specific things that you guys find difficult, maybe we should add some help pages to the website. |
|
I am having a meeting with the CLEM team on Monday. The problematic HTML visualisation in CLEM is not model critical, but a feature used by users new to modelling (and experts like me) to understand and check the complicated setup of their farming systems tree structure and highlight potential issues before running the simulation. If I had to chose an option right now with the least cost it would be to throw the current HTML to a text or PDF file for the user to view using the GTK PDF viewer widget (if the conversion from HTML to PDF is suitable and fast) or in external application. Depending upon the widget we may drop the instant descriptive summary feedback in the summary tab, and reduce the error reporting to TEXT or mark-up and allow external viewing of the complete model setup rather than the ability to summarise each model component. This would be in the hope that a near future UI that we chose will allow us to easily resume displaying the HTML with a transition to the .Net cross platform UI as developed. I understand the desire to remain completely open source, but it might be worth considering some third party tools if/when we head down the MAUI/xamarin path in future as these would be licenced by the software and not required by the user. It is an investment in us not having to develop the UI components to provide the most professional feature packed experience our users are accustom to in other applications. I know the Syncfusion xamarin controls have export to excel in the grid component and they also have pretty good individual free licencing and are not prohibitively expensive and locked down like Telerik but as your aware multi-developer licencing can start to get expensive. Anyway, we'll come up with the best solution for the short term while APSIM next gen shifts to .Net Core and look forward to the latest C# and Core coding conventions. |
|
@hol353 You're using .netcore now - is there a huge overhead in continuing to have 2 branches for Models? I agree it's not preferred. I also agree that .netcore is where we want to be and is the highest priority. I think we should organise a zoom call to discuss the short term and long term decisions. I am more concerned with the long term and how the short term decisions will affect that. The possible options mentioned are clear, and all have their issues. Long term - is GTK the path we want to continue to follow in the long term? Right now the largest cross platform applications that I can think of - Slack, Discord, Twitch, VS Code are all using Html inside Electron and count their users in the millions. Does GTK have the same future? Electron wasn't available when we made the choice to use GTK - it was the best solution for us at the time - is that still the case? There are more grid and tree controls available within HTML than there are in GTK. The first page of google search is all about different grid solutions for JS - GTK barely lists 1. Note: All of the excel like grid demos I looked at were not open source. Xamarin is now a mature technology - but is aimed at phones more than the desktop - evidenced by Microsoft's own choice for cross platform development in VSCode. I'm not sure that MAUI is going to be much different. I will admit to only knowing what Drew has told me about it though. I believe we're committed to open source, so purchasing ui components is not going to work for us. I'm currently involved in developing 4 projects that are web based, with possibly 2 others in the next 6 months - so I don't feel that GTK is a technology that I have time to invest in - probably the reverse of the position that the GTK users are in. |
|
I'll setup a zoom call - looking at this Thursday to start with. I meant to add a couple of html grid examples as well. |
|
Closing this one. Current plan is to migrate to .net core/gtk3. |
Three years ago, I ported the Apsim user interface from Windows.Forms to Gtk# to allow for cross-platform usage. That has worked reasonably well, despite it not being a particularly mainstream technology (more precisely, the Gtk side is mainstream on Linux, and .Net is mainstream on Windows, but their intersection isn't that widely encountered).
Now the question arises of how (and if) we can maintain this platform as the associated technologies evolve. On the Gtk side, Linux is gradually moving away from Gtk 2 (which we are currently using as the native base layer), and towards Gtk 3, with Gtk 4 on the horizon. On the Windows side, Microsoft has introduced .NET standard (and the associated .NET Core 3 implementation), and indicated their intent to move things further in that direction. Apparently .NET Framework 5 will be base on .NET Standard.
I've spend some (too much!) time recently looking into these technologies. ApsimX's Models,exe builds and runs readily under the .NET Core 3 implementation, and gives noticeably better performance than Mono on Linux (and presumably OS X) platforms. The problems arise when we turn to the user interface. This seems like a good time to consider transitioning from Gtk 2 to Gtk 3, which is not too radically different, although Gtk 3 uses a very different CSS-based mechanism for controlling the style of user interface elements, and has a bit more support baggage associated with it. Most of the existing ApsimX user interface works under Gtk 3 with only minor modifications, but there are three areas with some difficulties:
The Text Editor: we have been using Mono.TextEditor, which is based on Gtk 2 and was taken from version 5.9 of MonoDevelop. MonoDevelop is now at version 8.4 (and still using Gtk 2), but the editor code can no longer be readily abstracted from the rest of that project. I have tried porting the "old" Mono.TextEditor to Gtk 3, but haven't been fully successful, and it's not clear that we want to rely on an old, complex codebase that no-one else is working on. If we migrate to Gtk 3, I suggest that we switch to GtkSourceView as the editor. It continues to be under active development, and provides useful stuff like a code completion interface. The newer versions target Gtk 3, not Gtk 2. I have been able to successfully build a .Net wrapper for it, but have tested only its most basic features.
Code completion: this is tied in with the text editor, to some extent, but another aspect is a change in C# compilers. We would likely want to transition from Mono.Cecil and ICSharpCode.NRefactory to Roslyn equivalents for parsing C# code. I haven't looked into this very closely yet. @hol430 would know far better than I what is involved. Getting the Manager to compile scripts using Roslyn turned out to be quite simple, though, so perhaps this won't be too hard.
HTML rendering: this is perhaps the biggest problem. Our current use of browsers is platform-dependent. We embed an instance of Internet Explorer on Windows, WebKit on Linux and Safari on OS X. This isn't going to work, at least not easily, with .NET Core. Using IE on Windows involves using a COM interface, and calls in System.Windows.Forms which offers this support. If you do this under .NET Core, you've pulled in a platform dependency in a way that prevents the application from running on other platforms. The solution ought to be using WebKitGtk on all platforms. Unfortunately, the WebKit developers dropped official support for Windows several years ago. I've tried using an older webkitgtk dll from Cygwin, and it almost works, but can't render maps, apparently because the JavaScript interpreter has a bug in it. I've tried re-building this myself in an attempt to track down and remove the bug, but with no success to date (it's a very slow process; compiling webkitgtk can take several hours). WebKit should work readily on Linux and OS X, but Windows has me stumped. The developers of Midori appear to be working on a Windows port (for 64-bit Gtk3; their old one works well but is for 32-bit Gtk2), but there's no guarantee that will ever be released. A possible alternative to WebKitGtk is chromely.cef.gtk (which wraps the Chromium browser), but this appears to still be under development with little documentation, and I haven't been able to get it to work.
Note that for testing both GtkSourceView and WebKitGtk, I've had to build my own C# wrappers around the native binaries. This is an obscure process, but not terribly difficult if you have access to the source code for the native binaries.
So where do we go from here? Do we (1) stick with .Net Framework 4 and Gtk 2 and watch the rest of the world go by, (2) find workarounds (the browser part really has me stuck) for using .NET Core 3 and Gtk 3, (3) abandon the concept of a multi-platform GUI (making it Windows only, using either Windows Forms or WPF), or (4) use some other option like qml.net? @hol353 - can we discuss this when you are next in Canberra?
The text was updated successfully, but these errors were encountered: