Connect histogram optional features

[zoccoler]

Hi,

I started connecting events for the Advanced tab. For that, I updated the .ui file a little bit.

This is still a draft PR (WIP), but I wanted to expose it more explicitly to share this starting point.

At this point, I connected the log checkbox and the overlay_colormap Combobox (the other widgets start hidden from the interface for now).

To Do:

• connect histogram colormap ComboBox
• connect manual bins SpinBox
• connect Auto PushButton
• connect Hide non-selected clusters CheckBox
• perhaps connect napari layer.events.visible to hide_color_overlay method and vice-et-versa

[zoccoler]

Latest changes will only work after BiAPoL/biaplotter#49

[zoccoler]

Hi @jo-mueller ,

This is ready for review. It needs the main development branch of the biaplotter (v0.3.0, not yet release but ready). Automated tests shall fail because of that.

I connected all the options in the advanced tab, except the hide non-selected clusters checkbox.

The functionality of painting the selected layer(s) with the colors drawn in the plotter and resetting the colors upon unselecting is working, at least for the Labels layers. Please give it a try.

[jo-mueller]

Hi @zoccoler I only could have a quick look at it on my smartphone so my insight is limited. One idea that came to me though is the following:

From what I understand there are a bunch of widgets that turn visible/invisible depending on whether the HISTOGRAM2D is enabled. You could put all the widgets for the histogram in a separate container (I think there's something like a QFrame or QWidgetGroup) so you'd only have to turn one object visible and save yourself a bit of code.

[zoccoler]

Hi @jo-mueller ,

Thanks for checking this up so quickly. That would save just a few lines of code because just 2 containers are histogram specific: bins and histogram overlay colormap.

There are other conditions that do not related to hide/show, for example:

• Bins: setting the auto bins should, in my opinion, set the value in the manual bin spinbox and disable it. By the way, I took the "Set" button out of the interface.

• Log checkbox: it must always be available. It can be used by the scatter plot to display a non-categorical hue colors in log, and in all cases for the histogram.

I would like to further simplify the logic, but at the moment, I focused on getting it working. One thing that I find confusing is that some widgets callbacks arw connected to the "plotter_needs_update" signal, which calls _replot, others are directly linked to specific callback functions that eventually call _replot.

[zoccoler]

I noticed that changing some settings, especially those related to the color_overlay, would bring the overlay back on top (sometimes permanently) regardless of the show_color_overlay property (reflecting the ToggleButton state). This issue was coming from the biaplotter.

This PR in the biaplotter repo should fix it, making the color overlay visibility fully determined by the show_color_overlay property. So after biaplotter 0.3.1 release, the recent changes here should also work (minimal biaplotter version already pinned in this PR now).

Below is a small demonstration of the following behaviors:

• If layer(s) is/are selected, then overlay colors apply (given show_overlay button is checked - eye icon is visible)
• If layer(s) become unselected, default colors of the unselected layers are restored
• Toggling the show_color_overlay property (eye button) shows/hides the color overlay over the plot (histogram/scatter) and also applies/restores colors to selected layer(s)

The code and gif below were made on napari 0.5.6.

[zoccoler]

I just solved minor conflicts to get tests running, sorry...

biaplotter 0.3.1 is out 🎉

I also added properties to set axes labels more easily in the release :)

[zoccoler]

Oh, I will take a look into #395

[jo-mueller]

@zoccoler The new bug you found in #395 I could also reproduce here. I think I found the issue, will fix it directly here on this branch.

Follow-up: Upon inspecting it again, I realized that I had noticed it before and I'd say that it's a feature, not a bug. Adding the newly selected clusters on top of the previous selection would require knowing which indeces have been changed in the last draw stroke. We could try to compare but I think we'd have a hard time discriminating between zero-valued indeces that were intentional (i.e. by drawing zeros) or unintentional (i.e. by drawing on a reset plot).

The correct way to continue drawing after a previous selection would be to first select the MANUAL_CLUSTER_ID (which will correctly bring up the previous selection) and then continue drawing.

We could throw a little warning that informs the user that they are about to erase the previous selection when drawing on a non-categorical display? Anyway - I am going to merge this as this is not related to this PR.