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)
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?
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
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
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.
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
