search

UCL-ARC / python-tooling

Python package template for new research software projects
http://github-pages.arc.ucl.ac.uk/python-tooling/
MIT License
43 stars 2 forks source link

Start a GUI page #373

Closed dstansby closed 4 months ago

dstansby commented 6 months ago

A start on https://github.com/UCL-ARC/python-tooling/issues/354. I don't have recent experience with other GUI toolkits, so leave it for others to fill them in.

I would suggest merging this PR as a starting point, and then iterate on it to add more content in future PRs?

samcunliffe commented 6 months ago

I'm still 👎 about a different page for each type of library and think we should have a large(ish) single page with all libraries that we recommend/use and like in our projects.

dstansby commented 5 months ago

I'm still 👎 about a different page for each type of library and think we should have a large(ish) single page with all libraries that we recommend/use and like in our projects.

👍 for this in theory (especially as the list of recommendations grows), but deserves it's own issue/PR?

nicolin commented 4 months ago

I have just joined and use Qt C++ for GUI development, so a GUI page should sit outside python tooling as a GUI should be solver code agnostic just providing input to the solver and also reading back as xml or text format.

samcunliffe commented 4 months ago

I have just joined and use Qt C++ for GUI development, so a GUI page should sit outside python tooling as a GUI should be solver code agnostic just providing input to the solver and also reading back as xml or text format.

The scope of this is research software projects in general. We are not just for solvers. I think there is enough Python-specific interest in GUI programming and enough Python GUI libraries that the page should exist for signposting.

samcunliffe commented 4 months ago

... although we should do something with this PR. Merge as-is or move the table to utilities? I favor the latter but I'd bow to the consensus.

dstansby commented 4 months ago

I'm 👍 to as is, as I think having a GUI page makes it more discoverable.

paddyroddy commented 4 months ago

I have just joined and use Qt C++ for GUI development, so a GUI page should sit outside python tooling as a GUI should be solver code agnostic just providing input to the solver and also reading back as xml or text format.

I second Sam. The purpose of this project is not to imply that GUI means only for Python. We're saying in the context of Python development, if you want advice on GUIs then here are some potential ideas, and our experience.

p-j-smith commented 4 months ago

I'm still 👎 about a different page for each type of library and think we should have a large(ish) single page with all libraries that we recommend/use and like in our projects.

👍 for this in theory (especially as the list of recommendations grows), but deserves it's own issue/PR?

I'm in two minds about this, but probably agree that having a single page for these things would be good. Should the libraries in Parallel and asychronous processing also be moved to this libraries page? Agree with @dstansby that having a separate issue / PR to discuss this makes sense

samcunliffe commented 4 months ago

Merge as-is then?