Jupyter Lab server app not showing rectangle drawn with BoxEditTool

I have the following Jupyter Lab server app for the use of BoxEditTool which won’t show the rectangle even when pressing the shift key. The rectangle shows if I output that to an html file. I adapted this example to a Jupyter server app after this SO example:

from bokeh.plotting import figure
from bokeh.layouts import column
from bokeh.models import ColumnDataSource, BoxEditTool
from bokeh.io import show, output_notebook
output_notebook()

def bkapp(doc):

    data = ColumnDataSource(data=dict(
    x0=[1, 2, 3, 4, 5],
    y0=[2, 5, 8, 2, 7],
    ))

    tools = ['hover', 'reset']

    plot = figure(x_axis_label='x',
                  y_axis_label='y)',
                  title="Test BoxEditTool",
                  tools=tools)
    
    source1 = ColumnDataSource({'x':[], 'y':[], 'width':[], 'height':[]})
    r1 = plot.rect('x', 'y', 'width', 'height', source=source1)
    tool = BoxEditTool(renderers=[r1], num_objects=1)
    plot.add_tools(tool)
 
    # Add the data renderer (here a scatter plot)
    scatter = plot.scatter(x='x0', y='y0', source=data)

    doc.add_root(column(plot))
    
show(bkapp)

2021-12-01 12_51_39-STEREO_Untitled (9) - JupyterLab1045×1045 21 KB

What browser are you using? Can you also see if the problem persists in other browsers? Are there any (bokeh-related) error messages in the browser JS console log?

Also relevant Jupyter project versions (please always provide all relevant version info in any support question to any OSS project)

Python 3.9.5
bokeh 2.4.2
OS: Windows 10

jupyter_client            7.0.6              pyhd3eb1b0_0
jupyter_core              4.9.1            py39haa95532_0
jupyter_server            1.4.1            py39haa95532_0
jupyterlab                3.2.2              pyhd8ed1ab_0    conda-forge
jupyterlab_pygments       0.1.2                      py_0
jupyterlab_server         2.8.2              pyhd3eb1b0_0
jupyterlab_widgets        1.0.0              pyhd3eb1b0_1

I tried with Chrome and Edge, same outcome. Console outputs nothing when I drag with the BoxEditTool enabled, whether I press shift or not.

[bokeh] setting log level to: 'info'
VM126 bokeh-2.4.2.min.js:587 [bokeh] Websocket connection 1 is now open
VM126 bokeh-2.4.2.min.js:165 [bokeh] document idle at 29 ms
VM126 bokeh-2.4.2.min.js:163 Bokeh items were rendered successfully

@Wall.E The docs here

https://docs.bokeh.org/en/latest/docs/user_guide/tools.html#boxedittool

Describe two ways to initiate a box

Hold shift, then click and drag anywhere on the plot or double tap once to start drawing. Move the mouse and double tap again to finish drawing.

Have you tried the double tap method? That works for me, but shift-drag does not. I would suggest making a GitHub Issue regarding the shift-drag that is mentioned. It’s possible that is a bug in the tool, or a bug in the docs, or a bad interaction with the JLab UI that was not previously known. To be honest I am not sure why there should be two mechanisms. cc @Philipp_Rudiger

Another observation @Philipp_Rudiger the BoxEditTool seems to behave pretty poorly with DataRange1d near the range boundaries. AFAICT the range updates but the tool basepoints are stored in screen coordinates (I’m guessing), meaning they are no longer valid after a range update, which in turn causes some erratic behavior.

@Wall.E if you otherwise need to use DataRange1d you are probably advised to limit the ranges’ renderers properties explicitly, and exclude the renderer for the tool. In your code above that would look like

scatter = plot.scatter(x='x0', y='y0', source=data)
​
plot.x_range.renderers = plot.y_range.renderers = [scatter]

Lastly, I guess I will speculate. Since the shift-drag method works in outside JLab, it might most likely be the case that the JLab UI is interfering, e.g. intercepting <shift> events before we can see them. If that is the case, there may be nothing we can do about it. Maybe other modifiers could work, and we could make that configurable. Definitely will require investigation, though, so please make the issue.

Yes, I had seen that in the doc too, the double tap didn’t work either.

Indeed, the shift modifier is heavily used by the UI, e.g. for selecting the cells, executing them… Note also that my OS is Windows 10. I don’t have a linux box around to test (won’t have room or time to virtualize it either), could be OS-specific? Unless you managed to reproduce the issue in another OS than windows?

Neither method seems to work on Linux in JupyterLab. Definitely seems like an interaction with JLab specifically. Please do file a GitHub Issue with full details. I am afraid the only immediate alternative I can suggest is to use the box selection tool (which appears to work as expected in JLab) and then respond to the SelectionGeometry event. You would have to manage a rect glyph yourself in the geometry callback if you want a “persistent” rect area to display.

Ok, using the box selection tool circles back to a related issue I posted: Access box_select attributes set in figure
In that topic we didn’t go over the SelectionGeometry event, I’ll look into it. I don’t need a persistent glyph. All of this was in the context of storing selected coordinates for later work on the image array. I’ll file a Github issue for this BoxEditTool issue with JLab.

Right, I didn’t have the bandwidth to follow the other thread, but I’d gathered that you settled on a solution based on using the geometry alone (i.e. the coordinates that a box edit tool updates). In that case, the selection geometry event will give you the same information any time a selection happens, and you can just ignore the actual selection value set on the CDS if it is not useful for you. See

and a full example that uses it here:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.