Hi @Kevin_Kyoungup_Park Bokeh 2.x tightly manages layout of its own widgets, so the intention of css_classes is really only to afford a mechanism to apply non-layout styles, e.g fonts, colors, outlines, etc. The kind of usage you are describing is definitely not intended or supported. You might consider opening a GitHub development discussion to surface this use-case to more of the core team, in case there is any bearing on the upcoming 3.x work.
In any case, for now, your options would be:
Add the Bootstrap components outside Bokeh (e.g. in a page template) and wire things up manually, with regular JS callbacks that manipulate Bokeh objects
Create a custom extension that wraps your Bootstrap components
Thank you, @Brian. Your answer is clear for me to do what.
I can wire things up to Bootstrap objects manually, but I would like to change the design of the Button from Bokeh. The bokeh Button is not the object to wire up, though.
Anyway, I hope there is a way to discard or redefine Bokeh’s specific CSSs to apply Bootstrap’s CSSs. Is there a way??
@Kevin_Kyoungup_Park I am sorry but your response seems to have some contradictory statements. To be clear, my suggestion is to not use Bokeh’s Button widget at all, because there is definitely not any supported way to replace the CSS for Button to the extreme degree you are proposing.
You can also use that template in your Bokeh app I believe.
My dream is that one day Bokeh was provided the funding for a professional to style Bokeh using a well known design framework like Bootstrap, Material or Fast. That would make a big, big difference for both direct users and others who build on top of Bokeh.
Certainly I have had the same dream for the better part of a decade. If you ever have any leads on funding please do let us know. @MarcSkovMadsen your demonstrations are always interesting and impressive, but if I am honest, I don’t they have connected to average users for the most part, simply for lack of actually being part of the project proper, in features, docs, and examples. I’d love to see the time you have invested garner a broader return in the community, so I would encourage you to consider direct contributions in the form of Pull Requests to the codebase.
Most of what I have been doing is a part of Panel. I am the number 2 contributor according to github insights with 124 PRs. Regarding adoption. Panel has +400.000 downloads per month and 1600 stars on Github.
So I truly believe I have contributed a lot. Over the last 2 years I’ve spend so much time on contributing stuff to Panel and related projects, Panel extensions for users, Helping the community on discourse and adding docs to other frameworks about Panel integrations, Communicating etc.
On the other hand you are right. Adoption is low compared to Streamlit and Dash. But it is similar to the adoption of R Shiny during its first years. So its not that bad either. But I dream of a broader adoption of Panel as I believe it could help a lot of users that could create more awesome things than what they can do with Streamlit or Dash.
@MarcSkovMadsen Looking back, perhaps my wording was clumsy. All I meant to suggest is that if some things are currently hard/time consuming to do in Bokeh—yet you are still managing to accomplish them!—then perhaps there are concrete changes that can be pushed down all the way into Bokeh itself, to make those things simpler or quicker to do (to benefit both for Panel devs and for general Bokeh users).
I think Panel is sort of reaching a level of maturity where things like pushing things back into Bokeh or just making them available to Bokeh users in some form. For example there are extensions that could be shared between Panel and Bokeh users. For example there are probably improvements to the server that is only in Panel. But probably docs will take the forefront of Panel for some time. Its really needed. And then there is adapting to Bokeh 3.0. It fear that will be huge.
