positioning of plotting windows about qcodes HOT 8 CLOSED

For pyqtgraph this is possible via fig_x_position and fig_y_position https://github.com/QCoDeS/Qcodes/blob/master/qcodes/plots/pyqtgraph.py#L68

from qcodes.

Ah, the pyqtgraph object proxies are... so nice in some ways and such a pain in others.

Offhand I'd think setGeometry should belong to QtPlot rather than BasePlot. It won't pertain to matplotlib, will it? Nor to plotly, if I ever get around to adding that... but yes, that would definitely be nice to add. I haven't looked at its arguments, but perhaps there would be a way to add it to the QtPlot constructor too, as with figsize?

from qcodes.

I think setGeometry should be in BasePlot. Matplotlib figures do not have a
geometry from itself, but depending on the backend we can set the position
as well (e.g. fig.canvas.manager.window.SetPosition).
Adding the position to the constructor is fine, but I also want it in the
object class.

Usually I have many windows floating around and I like to use the
setGeometry function to tile the windows onto my second monitor.

On Mon, Feb 29, 2016 at 12:15 AM, alexcjohnson [email protected]
wrote:

Ah, the pyqtgraph object proxies are... so nice in some ways and such a
pain in others.

Offhand I'd think setGeometry should belong to QtPlot rather than BasePlot.
It won't pertain to matplotlib, will it? Nor to plotly, if I ever get
around to adding that... but yes, that would definitely be nice to add. I
haven't looked at its arguments, but perhaps there would be a way to add it
to the QtPlot constructor too, as with figsize?

—
Reply to this email directly or view it on GitHub
qdev-dk-archive#34 (comment).

from qcodes.

@eendebakpt looking at this again I think we can close this issue, you are seing an error because you are using ipython/jupyter!
Whenever you return an object to the ipython console, or the jupyter html notebook they will try to find a repr function, and the pyqt remote proxies will happily accept any function call and proxy it to the real object which then will raise an exception and then the proxy raises another exception that has a different type than what the console/ notebook expect.

Thas is a classic failure mode of poorly designed systems, like the remote pyqtgraph (which was just designed for speed, not interactive use).

from qcodes.

@Unga In #387 there is no issue any more, so in that sense the issue can be closed. Related there are the following two issues:

• There should be a generic .setGeometry that is both valid for the Qt and Matplotlib style windows.
• In #387 the plotting object is a subclass of QWidget. This has both advantages and disadvantages and we should decide whether we want this or not.

from qcodes.

@peendebak yes, because 387 uses pyqtgraph the way it's meant to be used :D

Possibly true that there should be .setGeometry but in matplotlib that gets tricky ( @jenshnielsen may know a lot more about this than me though) it also gets tricky in the web world where one does not take control of the desktop behavior!

from qcodes.

for pyqtgraph this can be solved like this:
qdev-dk-archive@ae32c1a

Wether or not we want to merge this back in qcodes it's something we can decide here!

@jenshnielsen you call the shot on this one!

from qcodes.

Probably we should expose a setting from config that sets a default position. That way you can configure your measurement computer with say the notebook/python console on the left and windows always popping up to the right of that and if you don't set anything in config it will default to the current behaviour.

The tricky part is handling multi monitor in a way thats both general enough and actually useful

from qcodes.