GUI or CLI

[camUrban]

We should create a command-line interface or GUI.

Frontend development is not something I know well, so I'd love some help on this feature!

[Zach10a]

Once the examples have been fixed and I can run the code for v2 I would be happy to give the GUI a shot using Qt.

[Zach10a]

So this is going to require some design decisions on your part as it progresses, however, to begin I'd like to refactor your file structure slightly to clean everything up in preparation for the UI. I've attached a picture below of how I think would be optimal, and the full structure can be found in my branch https://github.com/Zach10a/PteraSoftware/tree/gui_formation .

After you've had a gander at that, let me know what you think about this as a template;

Obviously it's still in the early stages, however I am trying to loosely follow the generic "CFD Software" workflow. Let me know what you think!

[camUrban]

@Zach10a Thank you for your work on this. It looks awesome!

Regarding the file structure, that will require a bit of work on my end. The main challenges are ensuring that everything is packaged properly for a PyPI release, and trying to not break backward compatibility unless necessary. However, I think it will be doable! Once we have the GUI up and running, I'll start making those changes.

The template looks great! Because you are using QT, we may also be able to do the pyvista visualization inside the same window via the pyvistaqt package.

[Zach10a]

Standby on the file structure, I've halted the refactor because of issues relating to relative path imports. Will just finish off the GUI with the current file system and we can discuss refactoring after!

Edit: Already looking at that as a way of including Pyvista, will update when I have found a way to do it.

[Zach10a]

Initial design of the first page, needs some cleaning up but let me know if you have any thoughts on the design. I've also implemented a splash that shows the logo while the app is loading.

[camUrban]

@Zach10a Damn! I absolutely love how this looks.

One thing to keep in mind is that wings can be defined with many wing cross-sections (more than just two), and airplanes can have multiple wings (more than just one). Problems can even contain multiple airplanes!

However, the first version of the GUI doesn't need to incorporate every feature of the full solver. Instead, we should first shoot for a minimum viable product (MVP). I just wanted to mention this so that it's in your mind as we continue development.

I've also attached a version of the logo with dark text so that it shows up better against the white background. Thanks again for the amazing work!

[Zach10a]

Agreed with the MVP comment, that is what I'm currently trying to produce. Hopefully the early versions will allow us to package it up into an app to allow people to get a demo of what it's like, and increase awareness about it.

Obviously down the line more features can be added, and PySide2 designer software is relatively easy to find your way around and change things, improving the current style and adding more capability to catch up with the code itself!

Cheers for the Black logo, will stick that up there when I work on it next!

[Zach10a]

Just finished off adding the capability to run examples through the GUI, go check it out if you have a moment! They can be run via the "Help" menu at the top.

I've been having a think about your comment regarding MVP and would like to clarify it so we don't keep 'chasing that next feature'. My current MVP would look like this:

1. User has ability to run examples.
2. User has ability to run very simple 2 Cross-Section simulations using their own parameters
3. Terminal output is shown at the bottom of the page

If you have any thoughts on this please let me know. Would love to keep adding capability after that, however I think these very clear goals will help avoid the never-ending loop of adding features and never releasing.

Really enjoying working on this, CFD was always a big part of my Uni life so really happy to be giving back!

[camUrban]

@Zach10a I just downloaded your branch and ran the examples using the GUI. It's awesome!

Regarding the MVP, I agree with your list of features but would add one more: I think it would be advantageous if the GUI version of Ptera Software could be packaged in an executable. That way, users could start trying out the software without the added opportunity cost of downloading Python + an IDE and setting up a virtual environment.

However, I don't know how much extra work that feature adds. I found this article that outlines the process. In your opinion, do you think this is an appropriate feature to add at this phase?

Regardless, after we get those three or four features implemented, I think we should release the GUI with the next release of Ptera Software (v2.1.0 or v3.0.0 depending on if we break back compatibility or if other features are added in the mean time).

[Zach10a]

Many thanks for the kind words!

I've got experience packaging these sorts of apps, will most likely be using INNO Setup. Agree that this feature would be appropriate at this time.

[Zach10a]

I am still working on this, just had a busy few weeks!

[camUrban]

Hey @Zach10a! I've made a pull request template and contribution guidelines based on your advice regarding pull requests. I'd love to get your feedback on them if you have some time.

Additionally, I was wondering about your feelings regarding the scope of GUI. Do you think it would constitute a major version release (it breaks backward compatibility with the pre-existing API) or a minor version release (it incorporates new features but doesn't change compatibility)?

Cheers!

[Zach10a]

Hey Cam,

In terms of the GUI scope, I think it would probably be good for it to constitute a major version release as for the first time any user irrespective of coding experience will be able to use it. Whether it breaks backward compatibility is yet to be known and I'll be honest I would probably have to make that call when I get back to working on it.

Will take a look at the contribution guidelines! Apologies that it's been a while, I am currently in a training program that requires pretty much all of my capacity. Looking to restart work on this early July.

Hope this helps, will get back to you if there are any queries regarding the PR template.

[camUrban]

Hi Zach. Good points on the GUI likely being a change that constitutes a major release. Also, no worries about taking your time with the GUI. I appreciate the help regardless, so no pressure!☺️

[Zach10a]

Hi mate,

Just fixed the examples menu to reflect the current folder structure. I'm getting near the end of this stage of my training so should have more capacity to work on this in the next couple of months.

I'd like to discuss the possibility of changing the structure of this git repo to reflect a project in development. This would mean that the 'master' branch would be the current release, and the 'develop' branch being the one that is collecting all of the new features and ensuring they are compatible. At the moment it appears a little sporadic and only built for one person to develop the project. As the contributing community grows (which I very much hope it does!) I think that the current structure may cause confusion and barriers to entry.

At the moment I am working on getting terminal output going. Once this is implemented, I think having a release put out with the full packaged software and the examples able to be run would be a fantastic PR tool and could increase the project's usability and therefore interest from a larger community. After that, the ability to add in user-configured simulations can be sorted.

Let me know what you think, hope you are well and enjoying the summer.

[camUrban]

Hi Zach,

I hope your training program has been going well!

Regarding the git structure, I'm open to changing the way it's structured as long as we follow a set of community-accepted guidelines. Currently, I'm using Git-Flow. However, perhaps GitHub-Flow would simpler and more collaboration-friendly. Let me know if GitHub-Flow fits what you are describing!

The only problem I see with GitHub-Flow is incorporating releases (on GitHub and PyPI) and semantic versioning. I did some quick googling, and found blog posts about this issue on tempertemper and hackernoon. In summary, we could probably use GitHub actions to automatically update the version number and to publish releases every time master is updated. What are your thoughts on this plan?

[Zach10a]

If I'm honest my idea was a tad more simple than this, just changing the develop branch to the branch with all the new features and the master branch being used for the latest full release versions.

Please see the below image for an example of how I would do it vs how we are currently doing it. It looks like you feed your master branch into the develop branch when I think that it should be the other way around. A tad pedantic and it feels silly to make such a hash over a small change but others coming in from different projects and wanting to contribute may find it more familiar.

As an update on the GUI, I'm starting to get it together in a decent way now so should hopefully be ready to package it in the next few weeks!

[camUrban]

I don't think you're being pedantic! You're right that simplifying things could make contributions much easier.

However, I think I wasn't clear before. The first image that you sent is "Git Flow," which is the method I'm already using. This is different (and more complicated) than "Github Flow," which is what I'm proposing. Here's an article explaining the differences.

Basically, Github Flow uses only two types of branches: the master branch and feature branches. Quoting from that article:

• When you are working on a project, you need to create a Feature branch out of your master branch and work on it.
• Once you have developed a feature and tested the changes completely, Then you can create a pull request (PR) to the master branch.
• Once the changes in the feature branch are reviewed and approved against the PR request, then the Branch is merged with the master branch.
• Branches let you work on new features and fix bugs.

Here's an image showing how Github Flow works:

Is this similar to what your idea? The only difference I see is that we get replace the develop branch with feature branches. I think doing so would be beneficial because when two users are implementing different things, they can be working on different branches. Separating out our work may prevent issues arising from two people committing to the same branch. Also, having contributed form feature branches form, be committed to, reviewed, and eventually merged will make reverting issues simpler. What are your thoughts?

[Zach10a]

Yep, there are crossed wires here somewhere. As long as we are on the same page regarding Git flow (Feature branches feed into develop, which is then fed into master upon a release) then I think we are on the same page and should continue using it. I think we may be confusing each other because we have never seen the system in action on this particular repo.

Regarding that, I am now happy that most parameters have been met for the GUI to be packaged and released as a Beta. As of now only the examples work, however getting custom simulations to work will require more than just me as it's a rather larger job than expected. I am currently working on getting it set up with Inno Setup, will update when I'm nearly there!

[camUrban]

Alright! Thanks to the awesome work of @Zach10a, I'm going to close this issue and issue #19.