Allow banner and logo to be suppressed?

[jbednar]

Right now, holoviews acts like Bokeh and prints a banner and logo when the notebook_extension is enabled:

This is helpful for debugging (if it isn't there, things aren't working!), but (a) things almost always work properly, making it not helpful for me in practice, and (b) it disrupts the flow of the page when I'm converting notebooks into web pages for documentation or examples.

Can there be a simple, concise way to turn off the logo and header? hv.notebook_extension(quiet=True) would work as a syntax, but that's actually still a bit distracting, because then every notebook will make people think about what "quiet" means, rather than what this particular notebook is about. I don't have any less-conspicuous way to suggest, though.

[jbednar]

I guess I personally would rather see the message gone by default, with an option needing to be provided to enable it, as in hv.notebook_extension(banner=True).

[jlstevens]

I agree with adding an option to suppress visual output when loading an extension.

I guess I personally would rather see the message gone by default, with an option needing to be provided to enable it, as in hv.notebook_extension(banner=True).

The original reason we wanted the banner by default is to show that the cell contains invisible Javascript output - if you delete the cell things will break (HoloViewsJS is gone). I think this is still true which is why I would prefer banner=True by default with banner=False when it is needed (e.g for dashboards).

Right now, holoviews acts like Bokeh and prints a banner and logo when the notebook_extension is enabled

I suspect Bokeh does the same thing for similar reasons...

[jbednar]

I don't understand the concern about deleting the cell -- if you delete the cell, then the notebook won't be runnable anyway. So when would that be an issue in practice?

Try counting how many times you have seen that banner message (here or in Bokeh), compared to how many times it was relevant to an action you needed to take or a decision you needed to make. In my case, those counts are about 10 million and 0, respectively, which makes me want to make it go away.

[jlstevens]

if you delete the cell, then the notebook won't be runnable anyway

It won't be re-runnable but deleting such cells can break the currently running notebook without a kernel restart. These cells are special due to their hidden contents, and not just their code.

Try counting how many times you have seen that banner message (here or in Bokeh), compared to how many times it was relevant to an action you needed to take or a decision you needed to make. In my case, those counts are about 10 million and 0, respectively, which makes me want to make it go away.

That is an argument I can buy - especially as we expect a new HoloViews logo at some point! If we got rid of it by default, I would probably deprecate the logo option entirely.

[jbednar]

It won't be re-runnable but deleting such cells can break the currently running notebook without a kernel restart. These cells are special due to their hidden contents, and not just their code.

Right; I appreciate the distinction in theory. But a notebook with a deleted cell that would be necessary for re-running is a zombie anyway, so that doesn't seem like something that is a big issue in practice.

[jbednar]

If it helps for motivation, here's an example of why I want it to go away:

There's no good place to put the "notebook_extension" line -- where it is here, the JS message seems like it's part of the document, which is very confusing, but later on I want to be showing how simple things are, and the message gets in the way there too. The notebook_extension call should be just part of the headers that people can ignore, like the imports -- something that can be inspected, but doesn't need to be. Shall I make a PR?

[philippjfr]

Can we close this or do we want to make further changes?

[jbednar]

Let's consider closing this issue to be dependent on making a decision about making banner=False the default for 2.0. If that's been decided, let's record the decision here, and close the issue (if nay) or assign it to 2.0 (if yea).

[jlstevens]

We've had a couple replies to your query on gitter and the ones I've seen have been from people who either like or don't mind the logo (no one's complained about it as far as I know). Personally, I'm wondering if it wasn't the logo but the message text that you were finding problematic...

[jbednar]

That's true; it's the message text that disrupts the flow; the logo is less of an issue. So, my new proposal: we make the banner text go away by default, and restore "logo" as a keyword to further suppress the logo also (removing the new "banner" keyword). In the future we can consider making logo=False by default, but that's less crucial.

[jlstevens]

I think having three options for this i.e banner, logo, banner_text (or load_message or just message?) is a bit much.

How about making the new banner parameter into an object-selector? Then it could be banner='logo' (just the logo), banner='message' (just the message), banner=False (no banner at all) and banner=True (full banner). Then banner='logo' is what you could use if you don't want the message...

[jbednar]

I'm not suggesting three options, just one: logo=True by default for now, logo=False by default eventually (or not). Then no change is needed to the API compared to master, just a change in behavior such that no banner text is ever shown anymore. The logo fills any information-providing function the text did, since the text message means almost nothing to anyone besides HoloViews developers, who don't learn anything by seeing it anyway if they also see the logo. So no need for new banner or banner_text keywords, since I don't think anyone would ever want or need to enable showing that text.

[jlstevens]

Are we happy with just having the banner switch? If we haven't come to any other decision, I say we should leave that for now and close this issue. Unless we have any new ideas!

[philippjfr]

Thinking about this some more I think the correct solution is to drop the text banner entirely and simply add logos for the imported backends, because that's the value in the banner text. Given that this is more effort I'd be happy readding the logo argument and could even be persuaded to drop the banner entirely, as long as we agree that in 2.0 we add logos for all the initialized backends.

[jlstevens]

If @jbednar agrees, I'm happy to go along with @philippjfr 's last suggestion.

[jbednar]

A logo per backend sounds very useful, thanks! Ok, I'm happy with re-adding the "logo" argument now, dropping all the text now, and later switching the single holoviews logo to one logo per loaded backend (to be suppressed when logo=False). Perfect, thanks!

[jlstevens]

Glad we came to a decision that I think everyone is happy with. Won't take me long to implement and then we can close this issue!

[jbednar]

Whew!

[philippjfr]

Reassigning to 2.0 so we can add the logos.

[jlstevens]

The holoviews logo at least has been updated.

[jlstevens]

We now do have a logo per backend. Closing.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.