Built-in plotting functionality for a range of parameters #2
Comments
|
Interesting plots:
|
|
FYI, @j9ac9k |
|
Where in the GUI would you want the plot to be, or would it be in another window? |
|
Well, you have all the creative freedom, whatever looks good and is user friendly.
…-------- Original Message --------
On 13 Nov 2017, 21:09, Ogi Moore wrote:
Where in the GUI would you want the plot to be, or would it be in another window?
—
You are receiving this because you authored the thread.
Reply to this email directly, [view it on GitHub](#2 (comment)), or [mute the thread](https://github.com/notifications/unsubscribe-auth/AIuyJ3p7iAf5TI42-ew1pmofBmAvbW6Jks5s2KIAgaJpZM4QcCyN).
|
|
Just forked the repo, for the minimum impact, I'm going to try and implement a standalone window. |
|
got the ugliest of ugly code to be somewhat functional, will be calling it a night, this is so ugly I decided to embrace it and leave the axes unlabeled (X is 'M' from 0.1 to 5, and y is p/p0
Truth be told, I've never worked with a properly packaged python library that is PyPi compatible, so I'm going to need some help adhering to those standards. Anyway check out my fork to see the code, there really isn't much to it at all. For reference, working on this branch here: https://github.com/j9ac9k/caeroc/tree/with_plots |
|
Good job, definitely a step in the right direction 👍 . This is more than what I would have done in a day! On the UI, since you have little more experience, I have a question, and probably you would have thought about it already. We need to be able set the range, and set the variables
PyPI does not complain so much, as long as we can build the package - it won't even complain if we don't specify the requirements explicitly. But it is good practice to write good code on the go. On the bare minimum one-line docstrings, comments wherever things get too complicated, and PEP8 standards. I haven't practised these myself while creating |
So first thing, pyqtgraph can indeed emit signals for all sorts of stuff from view ranges changing to...well anything I've thought I needed a signal for, it had one (granted they weren't always documented, but it's a pure python package with readable code). I'm not sure what the best UI layout would be for allowing a user to input ranges (was considering that). There are two forms of output you want to present, the table view, for a fixed input, and a plot for a ranged input (and perhaps you want to give the user ability to cap the y-range themselves).
Where I was going here is that I would make changes in the code, then was confused why they weren't taking effect (I'm sure there is a better way to do it than to On another note, I generally find QtDesigner UIs hard to work with or to get the layout exactly as I want it, but I do like it from a prototyping/layout. I'll think a bit more about how the UI should change for taking fixed inputs and getting all parameters, vs. saying which parameters you want to see a relationship between, and their respective ranges. I do think the external plot window is the way to go (as you can make it as big/small as you want). |
|
How would you feel about having a QTabWidget. One tab would have single value inputs as you currently have it (along with the result in table form), the other would have ranged inputs and bounded outputs for the plot results? |
|
On your question: you should use QTabWidget sounds like a fine idea. I hope it wont require too much refactoring. And yes , an external window to display the plot is good enough. QtDesigner is annoying to add changes, but easy to get started. I hear you.Compared to that |
It's visibility was fine, from the explanation, I wasn't sure that it was doing what I would want it to do (never having used setup.py).
Sounds good!
Alternative is to do it by hand; which sounds like a pain, and sometimes feels like a pain, but it's not too bad provided you're going into a layout knowing what you want it to look like. Here is an example of a project I'm working on, the GUI was written w/o the use of qt designer. This something I can likely help with; but it would likely be in conflict with #4 as the plotting would be limited to the Qt type GUIs ... I suppose if it's modular enough, it would still work.
Since you're wanting to support both pyside and pyqt5, how would you feel about adding qtpy as a dependency? qtpy is an abstraction layer where effectively you do not have to worry about which qt backend you have, you import from qtpy, so the end user can have either pyside, pyside2 (not compatible w/ pyqtgraph yet), pyqt4 or pyqt5, and you don't have to change anything in your code base. |
|
Sweet. Seems like you are building something really professional.
I would rather use `matplotlib.backends.qt_backend`. See if that works. If you think that is not good enough `qtpy` is fine with me.
EDIT: use `matplotlib.backends.qt_compat`
…-------- Original Message --------
On 15 Nov 2017, 19:22, Ogi Moore wrote:
> On your question: you should use python setup.py develop. I did mention this in the readme. Maybe I should but it somewhere more visible. A separate file like CONTRIBUTING.rst.
It's visibility was fine, from the explanation, I wasn't sure that it was doing what I would want it to do (never having used setup.py).
> QTabWidget sounds like a fine idea. I hope it wont require too much refactoring. And yes , an external window to display the plot is good enough.
Sounds good!
> QtDesigner is annoying to add changes, but easy to get started. I hear you.Compared to that pg is convenient. I don't know if there are any alternatives.
Alternative is to do it by hand; which sounds like a pain, and sometimes feels like a pain, but it's not too bad provided you're going into a layout knowing what you want it to look like. Here is an example of a project I'm working on, the GUI was written w/o the use of qt designer.
This something I can likely help with; but it would likely be in conflict with [#4](#4) as the plotting would be limited to the Qt type GUIs ... I suppose if it's modular enough, it would still work.
[screenshot from 2017-11-15 10-19-20](https://user-images.githubusercontent.com/646398/32852944-7b9f7f6e-c9ee-11e7-8fcc-0a9f605e2a76.png)
Since you're wanting to support both pyside and pyqt5, how would you feel about adding qtpy as a dependency? qtpy is an abstraction layer where effectively you do not have to worry about which qt backend you have, you import from qtpy, so the end user can have either pyside, pyside2 (not compatible w/ pyqtgraph yet), pyqt4 or pyqt5, and you don't have to change anything in your code base.
—
You are receiving this because you authored the thread.
Reply to this email directly, [view it on GitHub](#2 (comment)), or [mute the thread](https://github.com/notifications/unsubscribe-auth/AIuyJ8-J5VT4gecEh9XPUYgyqh-4xxRnks5s2ywAgaJpZM4QcCyN).
|
|
I haven't actually used Qtpy would just allow you to remove the if pyqt elsle pyside type code you have, and it would give you pyqt4 compatibility. |
|
It is an abstraction layer as I understand. Maybe not as advanced as qtpy. I have seen qtpy before, and there are numerous similar packages. Check out the source code, you will understand. https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/backends/qt_compat.py If this doesnt work, we go for qtpy. |
Can be integrated into the existing
caeroc-appor as a separate app.Related issue: AeroPython/scikit-aero#6
The text was updated successfully, but these errors were encountered: