As yet another bonus, there's so much less misdirection/obfuscation between where the pen gets updates.

Nice! one of the things I was worried that would be missing out was that the button had a nice representation of what the pen looked like, but you preserved that 👍🏻

Only question I have is if we want to move the pen label into the widgets portion of the library; and import it in the parameter type. I know we talked about this earlier, ... I like the idea of parameter types using the widgets within the library, but I do think there is value in making those widgets accessible via pyqtgraph.widgets as well.

If I remember our discussion earlier on this, you were concerned we might run into a case with circular imports, would that be a concern here, as the modified QLabel wouldn't need to know anything about the parameter type (the parameter type would need to know about the QLabel though!), so is circular imports really a concern here?

@j9ac9k good point, it should be updated now.

Now pen preview shows "changing" details and a delay timer is added similar to #209. The video somehow uploaded with terrible frame rate, but you are welcome to test it out. A 'cosmetic' indicator was also added to the preview label since the pen preview looks the same in both cases without it

While playing around with this, noticed one issue...and by playing around with it, I mean running

python pyqtgraph/examples/PlotSpeedTest.py

Open the Color Selection Dialog button, select a color (but don't click ok); you'll notice the plot changes color. If you cancel out, it will eventually change back to what it was. I'm not sure this behavior is a deal breaker or not, or is that an issue with ColorButton?

I somehow mentally blocked the fact that color picker is in fact a popup. Side note -- should it be a subitem like calendar instead of its own dialog for the same reason as the gripe in this PR? The reason a child relationship makes sense for the pen is because there are few enough editable options, but a color picker needs lots of real estate.

To answer your question though, I listen for a delay in sigValueChanging signals. Since the color picker parameter doesn't expose an API for whether the window is still open, that's why the pen value changes (I assume it's after you wait 1s?)

What if instead of a SignalProxy, I waited until no pen children had focus? This might be akin to a editingFinished signal fired by text inputs. I originally thought of a delay proxy as opposed to immediate updates, but now I think it might make sense for the user to click out of the parameter children (or press some key?) rather than imposing a delay. Or both? That's how a spinbox does it.

I somehow mentally blocked the fact that color picker is in fact a popup. Side note -- should it be a subitem like calendar instead of its own dialog for the same reason as the gripe in this PR? The reason a child relationship makes sense for the pen is because there are few enough editable options, but a color picker needs lots of real estate.

I think having the color button be a pop up dialog is fine. I could see a case to be made for having a text input that runs the text into mkColor; but that's waaaaaay outside the scope of this PR IMO.

What if instead of a SignalProxy, I waited until no pen children had focus? This might be akin to a editingFinished signal fired by text inputs. I originally thought of a delay proxy as opposed to immediate updates, but now I think it might make sense for the user to click out of the parameter children (or press some key?) rather than imposing a delay. Or both? That's how a spinbox does it.

I think "both" here would be good. Widget loses focus, emit signal right away; otherwise wait the delayed 1s. I don't have a good sense of what kind of code complexity that would add tho.

QTreeWidgetItem doesn't seem to have a focus event ecosystem, so I will leave that off the table for this release