Notification when Widget is resized or docked elsewhere

JupyterLab
1

Hi, I have a simple, stupid question.
https://jupyterlab.readthedocs.io/en/stable/developer/extension_tutorial.html creates a Widget which I’d like to use to display other information than the random image from the tutorial.
What if I need to react when this Widget resizes (due to window resize, or because the splitters are dragged) or when this Widget is docked to a different position?

Which events can I use?
Do you have a usage example that shows how to handle such resize or reposition events?

2

Silence?

Is this a phosphor issue, or do we need low level javascript mouse events to be notified of changes in Widget size, and, if possible, changes in Widget position?

3

It’s only been one day. :slight_smile:

A phosphor widget has a resize event and a convenience onResize method that is called when it gets a resize event.

4

Thanks. And what about repositioning of Widgets by drag&drop without resize? Any chance to catch these events? This is important to me, even if I have to catch the drag&drop at some higher container and bubble it down to the contained widgets.

5

@2ndworld There is a layoutModified signal on the application shell that you can listen to. It doesn’t give detailed information about how it was modified, but depending on your use-case, that might be enough.

6

Thanks to you both. This does the trick. For the app.shell.layoutModified signal, I am now looping over all Widgets that may be interested. There is no such event on the Widget itself, is it?

Is there any narrative documentation that could have guided me as a new jupyterlab hobby developer, where to search for these events? Or do I have to read the complete API documentation in order to understand what is possible in jupyterlab and what not? Or is this discourse group the “documentation”, stored in the brains of the developers?

Thank you!

7

We could always use better narrative documentation – the developer guide you have already found has some, but doesn’t cover a particularly wide amount of the API surface area. Beyond that, yes, the options are

  1. The auto-generated API documentation exists, but is in pretty rough shape.
  2. Ask here.
  3. Look at the array of extensions that do similar things to what you are interested in for examples.

Help with documentation is always welcome!

1 Like
8

There is also an ongoing effort to consolidate the documentation and answer questions such as the ones you had @2ndworld:

2 Likes
9

“Ask here” for documentation is a very kind offer, but do you really think it can replace a proper developer documentation?
What about a tutorial in the style of https://reactjs.org/tutorial/tutorial.html which I really like? Just pick a few recurring development patterns, wrap them in a more or less interesting story and explain to newcomers like me, how things are done and why.

10

@2ndworld Yes, as someone who tries to respond to questions here, “ask here” is not a very sustainable solution :slight_smile:

I agree that tutorials are a great way to push forward – that is what the [XKCD/APOD]
(https://jupyterlab.readthedocs.io/en/latest/developer/extension_tutorial.html) tutorial is meant to be, but we certainly could use more of them.

11

But not interested in pushing forward?

But you certainly would not offer more of them?

12

This is a community project, with documentation contributions from many people, including myself. We would welcome yours.

13

I don’t feel competent enough to provide a tutorial for a framework that I don’t understand.

What if I start a new topic, listing a few steps that I’d like to see covered in a more extended tutorial. And if I ask everyone in this group to brainstorm what they’d like to see added. I’d collect those ideas into an outline for such a tutorial.

Would anybody be willing to write an implementation for such an outline? Then I’d be willing to write the explanations, provided the developers jump in where I don’t understand the details.

Deal?

14

We’re happy to help and answer questions. Thanks for taking the lead on this.

I read an interesting article the other day about structuring documentation into How-to’s, Tutorials, Reference, and Explanation sections: https://github.com/jupyterlab/jupyterlab/issues/7387

Just curious: are you proposing to write a tutorial (i.e., focused on educating new developers) or a how-to (focused on small snippets useful as a reference)?

15

Yes, I’d consider this a tutorial, similar to the one for react that I have linked above. I’d like to collect a bunch of common challenges that I faced during my jupyerlab extension development attempts and ask for similar input from other new developers in this group. Around these challenges I’d like to outline some “story” like the tic-tac-toe game for react, which provides a simple, but not fully useless motivation to overcome those challenges.
Last but not, least, my idea is to have an implementation with a detailed explanation of what is happening where and why. An implementation that shows this story in action, but I won’t be able to do this with lots of help from your side.

If you think of a how-to as a collection of independent snippets (a cookbook?), this is not quite what I think of. But both a tutorial and a bunch of documented snippets would be invaluable and complement each other.

I’ll start a new topic with a bullet list of what I’d like to include in the tutorial hopefully next week. If somebody has suggestions already, please feel free to pm me.

16

The layoutModified signal does not work for me: