Hi Brad, Regarding the progress in ipywidgets, we are currently working on the 6.0 release. You can track the 6.0 milestone on the ipywidgets repository. The main objectives in 6.0 are
- the JupyterLab integration. - the deployment of Jupyter Widgets in other contexts than the notebook (sphinx docs, nbviewer, standalone apps) - the improvement of the overall UX of the core set widgets - the formal specification of protocols, mime types and file formats. >From a more technical standpoint, 6.0 also includes the migration to typescript and the phosphorjs framework. More than a set of core widgets, ipywidgets is meant to be a point of extension for custom widget library authors. pythreejs, ipyleaflet, bqplot, nglview, the autodesk molecular design toolkit are all custom widget libraries built upon it. Some additions might be made to the core set of widgets. One is a date picker. We have also made prototypes for token-input widgets. In terms of more complex widgets such as a grid / spreadsheet widgets, it is unlikely that such a project would be made part of the core set of widgets. Instead, it will probably be a custom widget library (just like bqplot or ipyleaflet) making use of the future phosphorjs spreadsheet. Cheers, Sylvain On Thu, Dec 22, 2016 at 7:02 PM, Brad <[email protected]> wrote: > Hi Brian, > > Thank you for the advice. > > It sounds like we should first see how far we can go with ipywidgets. > > Is there a way of monitoring progress on this front to see what developments > and API changes take place? > Would it be appropriate to request a certain widget type if we foresee that > it may have utility outside of our project? > > My sincere thanks to all of you who are involved in developing and improving > the Jupyter platform so that it can continue to grow as a powerful and > flexible platform for scientific exploration and other applications. > > Kind regards, > Brad > > On Tuesday, December 20, 2016 at 2:22:26 PM UTC-7, ellisonbg wrote: >> >> Brad, >> >> Great question. Nick has done a great job and answering this question >> and providing a lot of background. I wanted to fill in a few other >> aspects that may help you decide what fits for you and where things >> are headed. >> >> In general, there are a number of factors that go into where the >> project is headed: >> >> * The planning and roadmap work from the core project contributors >> about where we want to go >> * Which of the various options are attracting users >> * Which of the various options are attracting developers >> * Which of the various options have funding to hire developers >> * etc. >> >> On all of these fronts, I think ipywidgets is the best bet: >> >> * It has the largest number of users of the various options and has >> been around the longest >> * We have funding to work on it >> * There are a number of core developers putting a lot of time into it >> * There are a number of third parties building on top of it >> * It continues to be our top priority on the roadmap in this area >> >> The other thing to note is that much of what you describe in your >> original question can be done with ipywidgets out of the box. In other >> words, you can probably get a lot done by importing ipywidgets and >> using it - without diving into JavaScript and building custom widgets. >> >> I should mention though that ipywidgets is going through a phase of >> massive change and development right now. Because of this, lots of >> internal details will change over the next year. However, we are >> working hard to make sure the Python APIs change minimally, if at >> all. But even on the JavaScript side, we are working hard to minimize >> the changes needed. The good news, is that all of the work being done >> reflects the fact that ipywidgets is moving quickly and getting a lot >> of improvements. >> >> Hope this helps. >> >> Cheers, >> >> Brian >> >> On Mon, Dec 19, 2016 at 8:33 AM, Nicholas Bollweg >> <[email protected]> wrote: >> > Brad: >> > >> > Thanks for the interest! >> > >> > We're excited to help you do really cool things with notebooks, widgets, >> > etc. I guess it depends on what you mean by "application." Do you want >> > something that lives "close" to the notebook, such that a scientist can >> > use >> > it during their work, with full access to kernels, etc. or is it a >> > "display" >> > that just shows information? Or a SaaS? Or a presentation? Or actually a >> > "dashboard" on a device?! >> > >> > With those questions in mind, I'll answer your last question first: >> > >> >> I would also be grateful for pointers to any resources that you think >> >> would be useful in understanding this landscape. >> > >> > >> > I just updated this example to the newer APIs, based on this very dated >> > example. This is more of a "replace the old broken computer next to my >> > scientific equipment," rather than "what is the scheduling status of >> > this >> > machine?" On the API maturity side, it took about five minutes to get it >> > working, which isn't that bad considering two years had elapsed, in >> > which we >> > split everything up, and have done many releases of every component! I >> > can >> > vouch for python-driven widgets being a sound way to build up rich, >> > maintainable GUIs! >> > >> > Here is a recent talk I did at PyData ATL (sorry, no recording) which is >> > arguably an application, in that it is (a number of) live coding >> > environment(s). In that talk, to make matters worse, I use nbpresent, as >> > another way of laying out notebook content, including widgets (sort of a >> > sibling/competitor to Jupyter Dashboards). >> > >> > Ok, to your specific stuff: >> > >> >> IPython widgets >> > >> > >> > ipywidgets is (historically) the reference implementation of Jupyter >> > Widgets. >> > >> > When you install the python module of ipywidgets, it also updates some >> > JavaScript (jupyter-js-widgets), which is loaded into the notebook. >> > >> > For many kinds of interactive computing activities, you might not need >> > to >> > write any JavaScript, CSS and HTML, and get the full complement of GUI >> > stand-bys: buttons, sliders, layouts, etc. With a little bit of CSS >> > knowledge (written in a pythonic way), you can have pretty attractive >> > content. See the example at the beginning! >> > >> >> Jupyter declarative widgets >> > >> > >> > Declarative widgets gives access to the underlying widget API: Instead >> > of >> > python, you're mainly writing HTML and JavaScript. The bits and pieces >> > gets >> > installed via bower, yet another javascript dependency management >> > ecosystem, >> > instead of a python-focused one. >> > >> >> >> >> Jupyter dashboards >> > >> > >> > The Jupyter Dashboard has two components: the authoring tool and the >> > server. >> > The authoring tool lets you visually construct content on a >> > single-screen >> > scrollable dashboard, where the individual content pieces can be >> > markdown, >> > code, output or any widget (including, therefore, declarative widgets... >> > though it does take some extra work), and bundle up the content. The >> > Server >> > can accept these bundles, and host them in a relatively secure way via >> > Docker and clever proxies, and as such can be good for standing up >> > "hands-off" dashboards like kiosks and NOC/EOC kind of big displays. >> > >> >> >> >> Polymer >> > >> > >> > Polymer is the mother-of-all polyfills for browsers that don't yet >> > support >> > WebComponents... basically, you can use the future standard, today, at >> > the >> > price of a pretty big slug of JavaScript monkeypatching your >> > environment, >> > which is a totally normal practice, just that Polymer does a LOT, >> > because... >> > >> >> >> >> WebComponents >> > >> > >> > WebComponents are the "not widely distributed" future standard of web >> > development. They will presumably end much of the "tool churn" we have >> > been >> > seeing in React\Angular\Phosphor space, but it will take a while once >> > they >> > are a generally-available feature. They support things like data >> > binding, >> > encapsulating style, shadow DOM, and other things that I haven't wrapped >> > my >> > head around. >> > >> >> They have read through documentation and have seen a few detailed >> >> examples >> >> and videos, but are having a hard time seeing the big picture and >> >> getting an >> >> idea of where they should focus for constructing our application. >> >> >> > >> > Hopefully some of the information above was helpful! >> > >> > If you can deal with "just python", my recommendation would be to use >> > ipywidgets, and stick as close to that baseline as possible. If the work >> > you >> > are doing supports people that are already working in the notebook, this >> > will be the easiest to install/maintain. Stock widgets will work nicely >> > in >> > the Jupyter Dashboard server, if you need to deploy them. >> > >> > Your team would write mainly Python. With a little python >> > object-oriented >> > programming, you can prototype your dashboard in the notebook, then make >> > it >> > reusable as your analysis grows. >> > >> > If you start needing some special stuff, evaluate the existing offerings >> > (i.e. bqplot, ipyleaflet, pythreejs, etc.) If they meet your need, >> > hooray! >> > >> > If you end up building truly custom widgets (as opposed to python-based >> > confections), it may be worth evaluating the declarative widgets >> > approach, >> > though that does bring another level of "ops". Otherwise, there are >> > tools to >> > help you get going with writing and packaging your own work as modules. >> > >> > Let us know how else we might help, and of course share anything cool >> > you >> > guys make! >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups >> > "Project Jupyter" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> > an >> > email to [email protected]. >> > To post to this group, send email to [email protected]. >> > To view this discussion on the web visit >> > >> > https://groups.google.com/d/msgid/jupyter/5df08561-e25e-4a96-9de5-33faeae804bc%40googlegroups.com. >> > >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> Brian E. Granger >> Associate Professor of Physics and Data Science >> Cal Poly State University, San Luis Obispo >> @ellisonbg on Twitter and GitHub >> [email protected] and [email protected] > > -- > You received this message because you are subscribed to the Google Groups > "Project Jupyter" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jupyter/4d135b0f-4c1e-4d44-bfde-b4cc6960f930%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Project Jupyter" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAK%3DPhk7Gh5-nTvufZuG26sxQSZ5CvGEBxXL3cGO1fA7-5JfsJQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
