Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add drag and drop based on @btel's work #2720

Open
wants to merge 12 commits into
base: main
Choose a base branch
from

Conversation

wolfv
Copy link

@wolfv wolfv commented Jan 10, 2020

No description provided.

@pbugnion
Copy link
Member

I thought this was great, thank you! I added a comment inline.

@SylvainCorlay
Copy link
Member

This looks good to me :)

@jasongrout jasongrout added this to the 8.0 milestone Jan 17, 2020
Copy link
Member

@martinRenou martinRenou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

"cell_type": "markdown",
"metadata": {},
"source": [
"`DraggableLabel` is a label that can be dragged and dropped to other fields."
Copy link
Member

@jtpio jtpio Jan 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like DraggableLabel can be removed from the example notebook?

Copy link
Member

@jtpio jtpio Jan 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never mind that, I thought it was initially imported from ipywidgets (https://github.com/jupyter-widgets/ipywidgets/pull/2363/files for reference).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, the initial implementation had a DraggableLabel, but we removed it in favor of the more general DraggableBox.

@jtpio
Copy link
Member

jtpio commented Jan 17, 2020

Really neat:

drag-drop-output-view

@SylvainCorlay
Copy link
Member

SylvainCorlay commented Jan 18, 2020

I am in favor of merging this. Leaving it open for a little bit more so that @wolfv gets to fix the small inline comments.

@jtpio
Copy link
Member

jtpio commented Jan 18, 2020

@wolfv the fix for JupyterLab: wolfv#1


this.pWidget.addClass('jupyter-widgets');
this.pWidget.addClass('widget-container');
this.pWidget.addClass('widget-draggable-box');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this class needed? It doesn't seem to be used.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I just tried to follow conventions:

this.pWidget.addClass('jupyter-widgets');
this.pWidget.addClass('widget-container');
this.pWidget.addClass('widget-box');

someone who wants to style the drag drop widgets might want to add CSS to this?
On the other hand, the two leaf classes should probably add another class as well.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

someone who wants to style the drag drop widgets might want to add CSS to this?

That could indeed be useful.

For the case of the widget_box, there is actually some default css:

.widget-box {
box-sizing: border-box;
display: flex;
margin: 0;
overflow: auto;
}

@jtpio
Copy link
Member

jtpio commented Jan 20, 2020

@wolfv a quick pass on the example notebook here, let me know what you think: wolfv#3

@jtpio
Copy link
Member

jtpio commented Jan 20, 2020

Maybe we'll want to look into adding the dragenter and dragleave events in a separate PR? It could be useful to give visual feedback of what and where widgets can be dropped:

drag-enter-leave

@wolfv
Copy link
Author

wolfv commented Jan 20, 2020

One thing that I am afraid of with these additional events is that depending on the latency, things might get out of order on slow connections ...

E.g. if we had a drag_start event and allow to modify drag_data, we somehow need to guarantee that the new drag_data is set before the widget is dropped etc.

@jtpio
Copy link
Member

jtpio commented Jan 20, 2020

Yes it sounds like there could be some race conditions indeed.

If we want to still be able to add a visual feedback, an alternative could be to keep these events on the frontend and provide a way to customize the hover effect (for example by setting hover_style).

@wolfv
Copy link
Author

wolfv commented Jan 21, 2020

Agree, adding a CSS class on hover would be nice! I was thinking to keep this PR minimal to make sure it gets in, then we can build on top :)

@btel
Copy link
Contributor

btel commented Jan 21, 2020

LGTM. Thanks for updating to code and adding awesome examples @wolfv @jtpio !

@jtpio
Copy link
Member

jtpio commented Jan 23, 2020

Another iteration on the example notebook, to add a "Dashboard Builder" section using the AppLayout widget:

dashboard-builder

cc @wolfv: it's in wolfv#4

@wolfv
Copy link
Author

wolfv commented Jan 23, 2020

Impressive!

@Alexboiboi
Copy link

This looks so promising, can't wait to use it in my projects ;)

@btel
Copy link
Contributor

btel commented Feb 2, 2020

That's insane! Thanks @jtpio. I didn't even know that you can create a window with a widget view. It's only a step away from an interactive builder for voila dashboards ;-)

@wolfv
Copy link
Author

wolfv commented Apr 1, 2020

I rebased & regenerated the spec :)

@jtpio
Copy link
Member

jtpio commented Apr 1, 2020

Thanks @wolfv!

The docs failure seems relevant and related to #2746 (new in master since the last rebase).

@wolfv
Copy link
Author

wolfv commented Apr 1, 2020

Tried to fix it :)

@jtpio
Copy link
Member

jtpio commented Apr 1, 2020

Looks good 👍


if data.get('application/vnd.jupyter.widget-view+json'):
widget_mime = json.loads(data['application/vnd.jupyter.widget-view+json'])
data['widget'] = widget_serialization['from_json']('IPY_MODEL_' + widget_mime['model_id'])
Copy link
Member

@vidartf vidartf Apr 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking about this. Why is this method exposed as an API method? If the user is meant to use it from the kernel side, should we not handle the deserialization of the widget reference before calling this? This way, any kernel use could simply pass a widget reference as widget, and not have to worry about the model_id.

@maij
Copy link

maij commented Jul 13, 2020

This is a really nice addition! Is the on_drop callback extensible to handle more than widgets in the future, e.g. dragging an out-of-browser file into a widget?

@giswqs
Copy link
Contributor

giswqs commented Dec 13, 2020

When will this drag and drop functionality be available? I can't wait to try this out.

@aditya-giri
Copy link

Any ETA on this? This would be very useful for me.

@jasongrout jasongrout modified the milestones: 8.0, 8.1 Feb 2, 2021
@epifanio
Copy link
Contributor

epifanio commented Jun 1, 2021

Any ETA on this? This would be very useful for me.

Wondering about the same. such a feature would be very useful for building dynamic dashboards.

@gregfreeman
Copy link

I rebased this PR and fixed some minor issues. gf_drag_drop. I think this is a really cool feature. Shall I create another PR?

@wolfv
Copy link
Author

wolfv commented Jul 16, 2023

yes, please! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.