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
Dragging OutputAreaWidget produces new OutputAreaWidget mirroring same model #424
Dragging OutputAreaWidget produces new OutputAreaWidget mirroring same model #424
Conversation
If the origin cell is deleted, one is left with an empty mirror widget. What is the proper way to detect that the model is dead and dispose of the extra widget? |
@blink1073 and I were talking about this. A model could, for example, have a signal that it is being disposed. A widget could listen to that signal and dispose itself when the model is being disposed. Then it would be on the owner of a widget, if it is changing the widget's model, to change the model before disposing the old model. @sccolbert, what do you think? |
As written, this breaks slider widgets. The slider sees the mousemove event, but it propagates it to the OutputWidgetArea, and a Drag is started. Should jupyter-js-widgets block propagation of events to parents? |
We should probably be more selective on which parts of the output area are valid for starting a drag. Since an output area can contain arbitrary output, we should probably not consider rendered output as a viable drag-start target. Maybe restrict the target area to the left side gutter? |
@sccolbert That makes sense to me. See new commit, defining a widget class, |
@danielballan can you post a gif of your most recent commit? If you need a tool to record it, most all of us use this one: http://www.cockos.com/licecap/ |
This is awesome. Adding a semantic class name to the mirrored output would help styling it differently (for example not display the top-level prompt in the mirrored output). Also changing the mouse pointer when hovering the output gutter would help make this discoverable. |
Sure. This recording demonstrates two things that work and two things that don't. Good:
Bad: Addressing (3), I wrote (unpushed) code in line with @jasongrout's suggestion above. When an OutputAreaModel is disposed, a new Signal will cause the corresponding OutputAreaWidget to be disposed. But I'm not sure what signal to watch to get this process started. Contrary to my expectation, deleting a cell does not seem to dispose that cell's OutputAreaModel. I don't know where to start with (4). Is the problem obvious to anyone? |
@danielballan, you need to explicitly set the "trusted" attribute of the mirrored widget, the "widget" mimedata is being stripped. |
Thanks, @blink1073. That did it. So, this is now working and ready for review / discussion about whether it is a good idea. :- ) |
The other point of discussion (and maybe we want to handle this in a separate PR) is the UI/UX to indicate the output drag target area. As it currently sits, the draggability (is that a word) of the output area is somewhat undiscoverable. We may want to indicate it visually somehow, along with perhaps making a command to "mirror" the output of the selected cell in a new pane (maybe also another PR). cc @ellisonbg for UI/UX input |
Also, since it may not be apparent from my typing: THIS.IS.AWESOME! |
Haha, thanks @sccolbert. All of the above sound reasonable to me -- including "draggability" as a word. |
* A signal emitted when the model is disposed. | ||
*/ | ||
get disposed(): ISignal<OutputAreaModel, void> { | ||
console.log('get model disposed signal') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove debug print.
Great first PR, @danielballan, you nailed all of our design patterns. |
Awesome, I added a demo GIF to your top level comment, will merge once Travis agrees. |
Drag-and-drop any notebook output areas to generate a new stand-alone widget that mirrors that output area.
Thanks for the hand, @sccolbert.