Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 08:17
    Hoxbro closed #5607
  • 08:17

    Hoxbro on ci_flaky

    (compare)

  • 08:17

    Hoxbro on main

    Maintenance of test CI (#5607) (compare)

  • 08:17

    Hoxbro on main

    Add convenience method to Opts … (compare)

  • 08:17

    Hoxbro on opts_convenience_functions

    (compare)

  • 08:17
    Hoxbro closed #5606
  • 08:15
    Hoxbro commented #5600
  • 08:13
    Hoxbro commented #5601
  • 08:12
    Hoxbro closed #5599
  • 08:12
    Hoxbro commented #5599
  • 01:16
    codecov-commenter commented #5609
  • 01:14
    codecov-commenter commented #5609
  • 01:09
    codecov-commenter commented #5609
  • 01:05
    codecov-commenter commented #5609
  • 01:04
    codecov-commenter commented #5609
  • 00:54
    codecov-commenter commented #5609
  • 00:52
    codecov-commenter commented #5609
  • 00:50
    codecov-commenter commented #5609
  • 00:49
    codecov-commenter commented #5609
  • 00:45
    codecov-commenter commented #5609
Andrew
@IAteAnDrew1_twitter
nevermind, figured it out; solution on discourse
playertr
@playertr
Hi! When I plot an hv.Curve of cftime.DatetimeNoLeap timeseries data, I get the warning 'Converting cftime.datetime from a non-standard calendar (noleap) to a standard calendar for plotting. This may lead to subtle errors in formatting dates, for accurate tick formatting switch to the matplotlib backend.'. However, I am okay with the output and want to suppress the warning. The warning is set internally using param.warning rather than the normal warning package, so I can't suppress it using warnings.filterwarnings. Does anyone know if it is possible to suppress this warning, or is that a bad practice?
James A. Bednar
@jbednar
import logging
logging.getLogger("param.main").setLevel(logging.CRITICAL)
?
Param's warnings use the logging module...
playertr
@playertr
That didn't work for me in a standalone python script, I might need to see if "param.main" is the correct logger to access
Marc Skov Madsen
@MarcSkovMadsen
Sorry. I missed the Bokeh session. I simply overlooked the mail that it was moved to 3rd september.
Hope there is a video link somewhere. I really need to learn this.
Regarding Bokeh and Extensions. I'm trying to create a custom button by inheriting from the Bokeh and Panel Button. So far without luck. If you have time please send me a few helpful hints via https://discourse.holoviz.org/t/how-do-i-implement-a-custom-button-by-extending-the-existing-button/1169. Thanks. FYI. @MattEttus
Marc Skov Madsen
@MarcSkovMadsen
A little inspiration for improving the code base of HoloViews and moving it a little bit into the future :-) can be found in https://fastpages.fast.ai/fastcore/. Just all the kwargs and params that are all over the place and gives not insight into what can actually be provided in a modern IDE could be solved via some of the tools described in that blog.
image.png
Marc Skov Madsen
@MarcSkovMadsen
For whom might be interested. I've added a FastButton to the awesome-panel-extensions package. It's implemented by extending the existing Panel and Bokeh Button classes. Worked really well. See https://discourse.holoviz.org/t/awesome-panel-extensions-package-change-log/1009/12?u=marc
fast-button.gif
Marc Skov Madsen
@MarcSkovMadsen
I've also added a FastCheckbox
fast-checkbox.gif
Marc Skov Madsen
@MarcSkovMadsen
I've also added a FastTextInput
All the Fast widgets are implemented as true Bokeh Extensions extending or reusing the code of the existing Bokeh widget.
fast-text-input.gif
Marc Skov Madsen
@MarcSkovMadsen
If you care about which components Fast currently plan to support they have a "spec". You can check it out here https://github.com/microsoft/fast/tree/master/specs. I've checked it versus the Panel Reference Gallery and it seems they will be supporting most of the components you would expect.
image.png
Marc Skov Madsen
@MarcSkovMadsen
I've added a FastAnchor
fast-anchor.gif
Philipp Rudiger
@philippjfr
That's really neat, we should consider a mechanism by which we can swap out the bokeh models that are backing a Panel widget. Should put together a proposal like that at some point.
Marc Skov Madsen
@MarcSkovMadsen
Yes. I don't know exactly the mechanism. When doing the bokeh implementations i can see the code is not always in a state where you can just swap out another HTML element. But it's very close and only small code refactoring is necessary.
I actually learned a lot from reusing all the Bokeh and Panel code. I've been used to rewriting my own from scratch. That has taken a lot longer time.
:-)
Marc Skov Madsen
@MarcSkovMadsen
I have been thinking about Material vs Fast widgets. There are a lot of users on Material in general. But not on the MWC widgets in particular. It seems they are not that high a priority for Google. And if you look at the implementation of the web components (investigate the shadow dom on a page where they are used it looks very ugly and looks like just a wrapper around the existing js and css material design components. Not a simplified from the bottom up rewrite. That is very different from Fast. A lot of marketing has been put together and there is already a lot of people (thousands) signed up of their twitter account on their discord channel. The Fast components just seem simpler. And they also come with a very simple framework for writing web components. Something that could maybe also be wrapped in Python on day. And the light vs dark mode and change of style settings is just very, very simple and powerful. And they openly claim that their web components should implement the same attributes and properties as the "old" html elements and then just extend on top. Making it very, very easy to drop them in. This is the right way to do things.
Eventually I would hope to implement both one day as I believe they will both be major as time goes by.
And the fast specs describe a range slider :-)
bsdis
@bsdis
@MarcSkovMadsen you are talking about the FAST design system? https://fast.design
@MarcSkovMadsen sorry...im just jumping into the discussion like this... But wouldn't it be more neat to do a proper integration between panel/bokeh and react instead? That way you get a lot more power than if just integrating with a design system.
Marc Skov Madsen
@MarcSkovMadsen
Maybe. I would need to understand more detail @bsdis
Right now you need to wrap any js library whether vanilla js, web components, react, vua or angular into a Bokeh Model Extension to be able to use it in Panel.
So for each react component there would be some work. I have also look at Vuetify and Material UI. But so far I've not been able to find any nice and easy ways to incorporate it. It's one component at the time. And then you need to understand React as well.
Marc Skov Madsen
@MarcSkovMadsen
Web components are just so nice and easy to use in my opinion because the .js and .css of Bokeh, Panel and Jupyter never screws up these components.
FYI. Regarding Fast I've created some Feature Requests for "missing" components. See https://github.com/microsoft/fast/issues/created_by/MarcSkovMadsen
image.png
Marc Skov Madsen
@MarcSkovMadsen
@bsdis . Regarding the integration with React. You can integrate with React or Vue via Bokeh extensions. https://awesome-panel.readthedocs.io/en/latest/guides/awesome-panel-extensions-guide/bokeh-extensions.html. You can use anything you can use in Javascript/ Typescript. I've just not yet seen a lot of people looking to integrate React. I don't know of Panel developers or users that have these skills? There is one user who has a PR on adding the React Grid Layout though. See https://discourse.holoviz.org/t/react-with-panel/1001 and holoviz/panel#1535.
But @bsdis I would really, really like to provide some documentation and examples for integrating React. If you know how to do it you are welcome to show me a small working POC. That is often what I need to get moving :-)
Another thing I would like to dive into one day is actually wrapping Lit-Element or Fast-Element into Python. I think that should be very possible and make it very easy to create fast and performant things that run in the front end but are defined in the back end using Python. See an example of a Fast-Element here. https://fast.design/docs/fast-element/leveraging-css
Marc Skov Madsen
@MarcSkovMadsen
For inspiration when developing Panel there is a Layout Guide for Shiny https://shiny.rstudio.com/articles/layout-guide.html. I can see some of the layout stuff I'm still missing from Panel is there. This includes a NavigationList. I've created an issue here holoviz/panel#1571
Eric Ma
@ericmjl
Just wondering if there's a guide that shows how to use DynamicMaps with custom Panel layouts? In particular, we have three components we need to scrub through, one is a video, the other two are timeseries plots for which we have a dynamic map VLine that shows us at which time step we're at. We want to put the video on the right, the timeseries plots on the left, and the scrubber at the bottom, while taking advantage of the syntactic ease and composability of using DynamicMaps. I put up a reprex here: https://gist.github.com/ericmjl/3d05c15339bd0cd26e07165b43035e7a, do you all have advice on how we can go about this?
James A. Bednar
@jbednar
This sounds like a good topic for https://discourse.holoviz.org/
Eric Ma
@ericmjl
Understood, thanks @jbednar!
Marc Skov Madsen
@MarcSkovMadsen

Question on naming conventions for alternative widgets in Panel. Should I add the name of the framework as a prefix to the widget class or just call them the same as in Panel?

For example: Button (Panel) vs MaterialButton, FastButton, WiredButton, SmartButton, UI5Button, ...?

or

For example: panel.widgets.Button, material.Button, fast.Button, wired.Button, smart.Button, ui5.Button, ...?

The reason for asking is that I would like to make it easy some day in the future to switch between the differents ones. For example if you are experimenting with the look and Feel. This includes trying out different frameworks as widgets parameter to pn.Param.

And I am asking now because renaming is just tedious later on :-)
James A. Bednar
@jbednar
My guess is to use the same name and put them in a separate package, if they are largely compatible and replacements for each other.
And then always refer to them as fast.Button, wired.Button, etc in examples and scripts if it matters what the button comes from, and refer to them (i.e. import them as) just Button if it doesn't matter.
Marc Skov Madsen
@MarcSkovMadsen
Thanks
sameerCoder
@sameerCoder
Hello Every1,
A Gentle Request.
Guys why we are facing so difficulties in making our dynamic plot embedded with flask with our own server.
I am not able to findout good resources to learn ,
How we can make our dynamic plot dynamic in nature when embedded with flask,
whereas it was very easy to see the dynamic property of plot when running the bokeh server.
I really appreciate for bokeh server but we want plot embedded with flask in our own server there we are facing difficulty .
we are not able to find the good resource to learn and do.
Thank you.