Re-write GUI in Qt 5

[ksshannon]

I'm going to attempt to re-write the GUI in Qt 5 using QtCreator and the C API. I would like some input on what we should change in the current GUI. The first thing I'd like to do is aggregate the Solver, diurnal, stability, and solve pages. They are all solver options, they should be together. After that, what about a different navigation structure? I think we should keep a left-to-right/top-to-bottom model, but a tree might not be the best approach. Maybe it is. Regardless of that, I think we should move the input panel to the right of the tree (or other nav), I think it might save space. I'd like to get this in for 3.5, and would welcome comments and/or examples to follow.

/cc: @jforthofer @nwagenbrenner @tfinney9 @fspataro

[nwagenbrenner]

I think this sounds great.

I like the idea of aggregating the solver options. One issue with that though is that certain options still aren't available for the CFD solver (e.g., point init and stability) so we'll need to consider that in the work flow.

I also like the idea of moving the input panel to the right of the navigation. One thing to consider here is the future possibility of adding a viewing window for results and other geospatial data related to the run. We might want to think about the best location for a future viewing window and maybe setup for that now so we don't move things back and forth too much?

[ksshannon]

I like the idea of aggregating the solver options. One issue with that though is that certain options still aren't available for the CFD solver (e.g., point init and stability) so we'll need to consider that in the work flow.

Yeah, that is a good point. We can at least aggregate all the solver stuff into the top, and leave the solve/go button at the end.

I also like the idea of moving the input panel to the right of the navigation. One thing to consider here is the future possibility of adding a viewing window for results and other geospatial data related to the run. We might want to think about the best location for a future viewing window and maybe setup for that now so we don't move things back and forth too much?

I'd like to handle this with docks maybe, but I agree, we shouldn't move things back and forth. If we consolidate the current tree, maybe we can leave it below, and have a dockable widget on the right for various tools/viewers.

I'll mock something up and check it in on a branch.

*deleted earlier, stupid comment.

[ksshannon]

I've prototyped the toolbox ui in master. In cmake, set NINJA_QT5GUI to on to build it. It has no affect on the source tree. It builds a separate exe in $build/src/gui/ui. I'm neutral on toolbox vs tree, but I think we should plan on a large viewing area on the right, either web-based, or qgis based. I'd rather make the decision sooner than later (on the large viewer). I do like the list based interface for the domain averaged runs, and the outputs.

The idea is that they would fill in the fields, then click 'add run', then an editable list would display runs, that could be dropped. That would save a lot of space, and on the outputs, would allow multiple formats, with different resolutions. That one requires an API change, which I think we should do anyway, that defers the writing until after the simulation, and the caller specifies format, resolution, options, etc. as many times as they would like. That is a better interface, and saves multiple runs for the same solution.

After that, I think we do a save as... and allow all outputs to be written to a folder or archive.

[nwagenbrenner]

I checked out the toolbox ui. I like the domain average interface with the ability to add additional runs, saves a lot of space like you said. I'm not sure if I prefer the toolbox to the tree view. Maybe once it's cleaned up and organized it will be better.

What are the pros/cons to a web-based vs. qgis-based viewer?

I'm not sure what you mean by "and on the outputs, allow multiple formats, with different resolutions". We already allow different resolutions for the different output formats for a give simulation, right?

[ksshannon]

We'll let @jforthofer weigh in on the toolbox/tree.

Pros/Cons for web vs QGIS: Web is far fewer dependencies, but very simple. It also starts us down the path of a general web based interface. I also suspect it's a lot less work.

QGIS gives us a lot of control, but probably 10x the work. We have to handle everything, including base maps.

As for the last point, if you want two resolutions of fire behavior grids, you have to do two runs. We should be able to create multiple resolutions of a single format.

[ksshannon]

ping @jforthofer, I assume i won't hear back until after thanksgiving.

[jforthofer]

And you were wrong!!! Haha!

Got it to build. What I like:

1. Combining all the solver settings is a good idea.
2. This list for the domain averaged runs is a good idea. We could even possibly add a button in the future that would add a group of runs (like to simulate all directions N, NE, E, SE, etc.)
3. I think I like the idea about the output options. So the way I'm imagining it, things would change so that when you do a run, you would just initially save like a case file (which would ideally include a list of the inputs, and the results of the run in something like a database file). Then the user could "export" the results to a kmz, shp, etc. You can export as many times as you want (with different settings, like resolution). No need to redo a simulation if you wanted a different output file. This could also set us up for the future output viewing window. The user would choose (or import) the case file to select what they wanted to view in the window. We'd just need to decide how this would be done with multiple simulations, like a weather model run or the new point initialization runs. What do you guys think of this? It would require some work...

As for the toolbox look, right now I don't think I like it... but maybe I'm missing something. At least I don't know if it would work well for what I talked about in # 3 above. Right or wrong, I have in my mind the look of the FlamMap gui. Where a user adds multiple simulations to the tree (so you can have more than one simulation loaded at a time). I haven't fully thought this out.

[ksshannon]

And you were wrong!!! Haha!

Got it to build. What I like:

1. Combining all the solver settings is a good idea.

2. This list for the domain averaged runs is a good idea.  We could even possibly add a button in the future that would add a group of runs (like to simulate all directions N, NE, E, SE, etc.)

3. I think I like the idea about the output options.  So the way I'm imagining it, things would change so that when you do a run, you would just initially save like a case file (which would ideally include a list of the inputs, and the results of the run in something like a database file).  Then the user could "export" the results to a kmz, shp, etc.  You can export as many times as you want (with different settings, like resolution).  No need to redo a simulation if you wanted a different output file.  This could also set us up for the future output viewing window.  The user would choose (or import) the case file to select what they wanted to view in the window.  We'd just need to decide how this would be done with multiple simulations, like a weather model run or the new point initialization runs.  What do you guys think of this?  It would require some work...

I was thinking about just being able to add 'duplicate' formats with different resolutions. Right now you can only do one output for each format. The case file is a different issue.

As for the toolbox look, right now I don't think I like it... but maybe I'm missing something. At least I don't know if it would work well for what I talked about in # 3 above. Right or wrong, I have in my mind the look of the FlamMap gui. Where a user adds multiple simulations to the tree (so you can have more than one simulation loaded at a time). I haven't fully thought this out.

I'll re-write the tree version, and get another look. I'll work on this over Christmas.

[jforthofer]

OK, yeah being able to add "duplicate" formats with resolutions might be useful for some. Sounds fine to me, but I'd have to see how the UI ends up with this. I do think the case file stuff would be good in the long term... but it would require a good amount of work.

[ksshannon]

Bumping this until the newer solver work has settled.