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

Improving customizability and layout of widgets #84

Closed
philippjfr opened this issue May 17, 2015 · 10 comments · Fixed by #3836
Closed

Improving customizability and layout of widgets #84

philippjfr opened this issue May 17, 2015 · 10 comments · Fixed by #3836
Labels
type: feature A major new feature wishlist
Milestone

Comments

@philippjfr
Copy link
Member

Discussion in #70 indicated that we should aim to improve the customizability of the widget layout. The original request by @basnijholt was:

Is it also possible to determine where the slider will come? In a presentation the 'scrubber' orients itself nicely under the plots, although I don't actually want the buttons and the 'widgets' are on the right of my plots which make the plots too small. Any easy solutions for this?

Comments:

philippjfr:

The whole widget Javascript/HTML code isn't brilliant and the layout isn't customizable yet. Unfortunately neither of us is particularly experienced with JS. Once the IPython/Jupyter widget system is more stable we may also decide to start using their widget API again. What IPython doesn't yet offer is static widgets so we'll have to maintain our version at least for now. I'm the only one who is familiar with the widget jinja templates and won't have any time to work on it in the near future. If you know anything about JavaScript I'm happy to take you through it and you could have a shot at improving the layout and/or making the position customizable.

jlstevens:

I agree with Philipp and I think our best approach is to see if anyone is succeeding in doing anything significantly better in this regard within the IPython Notebook. If they are, we should be able to adapt their code/approach for our purposes.

Unfortunately, neither Philipp or I are sufficiently well versed in Javascript right now to tackle a general approach for laying out the widgets right now - although I agree this would be a nice feature!

Summary:

In summary there is currently very little customizability of the layout of the widgets. We are committed to improving the widgets until we or someone else can come up with a way to integrate static widgets with the IPython widgets API, however neither of us currently has time to devote to Javascript development. We would however be happy to provide input and guidance if someone wants to submit a pull request for improvements.

Known issues:

  • Widgets on the right don't leave enough space for large figures.
  • Widget layout behaves differently in IPython 2 vs 3 due to an updated dependency from Bootstrap 2 to 3.
  • Both the Bootstrap 2 and 3 have issues when text label gets too long.

Possibilities to consider:

  • Implement Backbone.js based widgets indpendently from IPython
  • Implement embedding within IPython widgets system (also Backbone.js based)
  • Improve current widget layout
@jlstevens jlstevens added the type: feature A major new feature label May 19, 2015
@jbednar
Copy link
Member

jbednar commented Oct 5, 2016

I'd like to vote for adding a "tight" option for the widgets. E.g. if we take this example from #882:

image

it just makes me feel bad to look at it, when it could look like this mockup:

image

I.e., an option that makes us pack each widget into a single line, shrinking whatever is necessary to make it fit with the label. Sure, this won't always work, with long labels, and maybe shouldn't be the default, but clearly we don't always need to be using so much space that it dwarfs the actual plot!

@jlstevens
Copy link
Contributor

jlstevens commented Oct 5, 2016

I just want to add that we have a plan to improve the javascript code, with a general WidgetManager that is widget-agnostic (in terms of how it looks and library used), allowing multiple possible widget libraries to be used in Javascript.

If we ever get round to completing this planned refactor, you could (for instance) use standard HTML widgets (i.e a HTML form) instead of the default JQueryUI widgets shown above. This would hopefully make it easier to implement fancier widgets and nicer layouts.

@jbednar
Copy link
Member

jbednar commented Oct 5, 2016

Sounds good. On a second look, I realize that I wasn't being ambitious enough. It should really look like:
image

That would be usable.

@jlstevens
Copy link
Contributor

@jbednar Nice mockup! And I agree that is what we should be aiming for.

@basnijholt
Copy link
Contributor

Looks really nice! This will make it much easier for me.

@stsievert
Copy link

Any update on this? I'd like to move the position of any sliders/dropdowns. I'm a new user to Holoviews and this is one of the first things I ran into.

@jlstevens
Copy link
Contributor

@stsievert

This is still a feature we are very intent on implementing!

As it stands, we just need a chunk of time to implement it, ideally with some experienced JavaScript help. The other thing we will want to keep in mind is support for JupyterLab: if we get a chance to refactor our widget system to make it more extensible and flexible, we will want to make sure it will also work right with JupyterLab.

@jlstevens
Copy link
Contributor

jlstevens commented Aug 14, 2017

@philippjfr and I discussed our plans for widgets and arrived at the same design we consider years ago (see the wiki page though I haven't updated it yet). Edit: I've looked through it and the plan is unchanged!

The core idea is that streams are powerful and everything should be streams. Streams can update plots in response to events and what we are missing are independent widget components that can generate stream events in response to user interaction.

Widgets need to be JS objects (not templated) associated with any widgeting library (bokeh, datgui, JQueryUI, native HTML5 widgets) that have a consistent API to talk to a generic WidgetManager class (in JS) that handles the stream aspect. These JS widgets need to have methods to set state (e.g range and allowable values on slider widgets) as well as a way of registering callbacks to respond to user events when they occur.

HoloMaps would be a special case handled by the widget manager: from the perspective of the widget, it is sending a stream event and from the perspective of the plot it is receiving new data in response to a stream event. What is different is the bit in the middle: instead of talking to a live Python process, the WidgetManager just looks up the data associated with the requested key/stream value from the static HTML document and returns it, no communication with Python needed.

There is a lot more to this and this is just an outline to restart the discussion: the vision is to have composable, independent components that generate stream events (just like LinkedStreams do with bokeh) that appear as widgets to the user using whatever implementation/widget library you wish.

@thoth291
Copy link
Contributor

thoth291 commented Dec 1, 2017

One more idea for the widget layout is it's position. I just got a case where I want my dropdown widget of holomap to be at the bottom - but it seems to be impossible right now...
Another way to look at this is being able to group widgets and then assign positions and order to a groups.
Just think how this would change the mockups above...
For example, I would put the sliders at the bottom, but checkboxes on the side (or vice versa).

@jlstevens
Copy link
Contributor

Just trying to link up the widget related issues. I think #2178 and #673 are also related.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature A major new feature wishlist
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants