04:02 <cr1901_modern> sb0: It's going okay. As of right now, I have the axis linked to a pyqtgraph viewbox. When the axis is moved (for whatever reason- zoom in, zoom out, slider reached edge of view), it will send a signal to a widget that holds the sliders to recalculate their position.

04:02 <cr1901_modern> Additionally, spinboxes will receive this signal to update their contents.

04:05 <cr1901_modern> I'm trying to use a TickSliderItem in pyqtgraph to implement the sliders themselves, but *may* have run into a potential problem. I'll explain it after I find more info.

04:49 <cr1901_modern> Okay TickSliderItem is probably not the best idea b/c no matter what it's going to be scaled by viewbox transformations. A subclassed Region Of Interest (ROI) is probably better.

05:04 <rjo> cr1901_modern: are you sure you need or want to build this on top of pyqtgraph?

05:27 <cr1901_modern> rjo: The "free axis scaling" of viewbox is nice. I suppose it's just another layer of potential bugs tho

05:28 <cr1901_modern> "free" as in "I don't have to reimplement 1800 lines of QTransform management

05:34 <cr1901_modern> rjo: Additionally, pyqtgraph fixes bugs w/ PyQt and Qt

05:35 <sb0> cr1901_modern, can you put your code into a repos for rapid testing/review?

05:35 <sb0> cr1901_modern, what qt/pyqt bugs have you seen worked around exactly?

05:38 <cr1901_modern> sb0: Will do. And none personally, but I've needed to look at the pyqtgraph source to figure out how objects interact with each other. Viewbox.py in particular needs to work around a bug to ensure that during paint, transformations get correctly applied

05:38 <cr1901_modern> as mentioned in the comments

05:39 <cr1901_modern> I can remove the pyqtgraph dependency if you wish. It's not required. Just makes things easier.

05:42 <cr1901_modern> sb0: Are you trying to remove all pyqtgraph dependencies?

05:55 <sb0> cr1901_modern, potentially. with the new display system, only the display processes, not the top-level GUI, will really use pyqtgraph

05:55 <sb0> the only part the top level GUI will need is the docking system, which isn't too great, so maybe we will replace it at some point

05:59 <cr1901_modern> sb0: By display processes, you mean the "add display" functionality in the datasets dock, correct?

06:01 <sb0> cr1901_modern, what i described on the mailing list

06:01 <sb0> cr1901_modern, subprocesses managing plots

06:06 <cr1901_modern> Looking for the post now (it would be nice if mailman had a search feature)

06:08 <sb0> it was recent... and doesn't impact the scan widget btw

06:09 <sb0> the basic idea is one independent GUI subprocess per plot/display

06:14 <cr1901_modern> sb0: I can't find it on the m-labs mailing list from the titles. But yes, whether it impact the widget is what I wanted to know. QGraphics Framework by itself- without PyQt- should provide enough support to get this done.

06:14 <cr1901_modern> s/PyQt/pytqtgraph/

06:58 <whitequark> sb0: ping

07:00 <sb0> whitequark, pong

08:31 <rjo> cr1901_modern: for me the first question was: can you do it with the existing widgets (qxt etc) or do you need a canvas and draw more or less everything?

09:29 <cr1901_modern> rjo: The widget could *possibly* be done with qxt