search

queryverse / ElectronDisplay.jl

An Electron.jl based figure and table display.
Other
85 stars 17 forks source link

display(HTML("test")) doesn't work #32

Closed zsunberg closed 4 years ago

zsunberg commented 4 years ago

Hi, first of all thanks for developing this package! It seems very useful!

To my surprise, this simple invocation doesn't work:

julia> using ElectronDisplay

julia> display(HTML("test"))

Was this by design?

The problem appears to be at src/ElectronDisplay.jl:39 where things "text/html" is explicitly listed as unshowable.

davidanthoff commented 4 years ago

Yeah, we don't want to capture HTML in general, because then things that can be shown fine in the REPL would all pop up in electron. I think it should work if you call electrondisplay instead of display?

zsunberg commented 4 years ago

Yeah, it works with electrondisplay.

What are some examples of things that you would like to keep showing on the repl? Are all html-displayable objects displayable in the REPL?

I would like to write generic code for a package that calls display and uses whatever display is available on the display stack to display a representation formatted in html.

davidanthoff commented 4 years ago

I think my main use case is probably DataFrame. I normally want to just see a few rows in the REPL, and not always pop up ElectronDisplay.

zsunberg commented 4 years ago

Ah, I now see the note about showable in the README.

To me, it seems like a better behavior would be to have the ElectronDisplay display everything it can by default (especially html, since the electron window is like a browser). If the user wants to opt out of specific types/mimes being displayed in the electron window, they can do, e.g.

ElectronDisplay.CONFIG.showable(::MIME"text/html", df::DataFrame) = false

Would you be open to a PR that changes the behavior to this? Are there any other display providing packages that adopt similar behavior? (it would be nice if most displays behave the same)

davidanthoff commented 4 years ago

We have the same situation in VS Code (and the same solution).

Can I think a bit about it? Or maybe we can entice some more feedback how others feel about this? My personal preference would be to leave it as is, but I think I'd be open to just go with whatever popular opinion is.

zsunberg commented 4 years ago

Sure. That sounds good. We should also probably see what Juno does.

It seems like there may be a piece missing from the whole Multimedia/display framework. Just because something is showable with a given mime doesn't mean we want to display it with that mime. It would be nice if there was a standard way to adjust this that doesn't depend on having a particular display package imported.

davidanthoff commented 4 years ago

Yes, that is very much what I've been thinking lately! I'm probably mostly in a situation where I have a REPL that is actually connected to at least two different display "devices", and what I want to appear where is really not trivial.

zsunberg commented 4 years ago

Perhaps there should be a package like DisplayConfig.jl that allows people to set affinities of different types to different displays - people could put a few commands in their .julia/config/startup.jl if they want, for example, DataFrames to always appear in the REPL. I'm not sure what the best way to hook it into the display code would be though.

davidanthoff commented 4 years ago

Yes, I think that would be the right strategy. I think it would also be good to have a common function for the secondary display, maybe even just display2. So one could configure things somehow, and then I could do foo |> display2, or foo |> display, depending on where I want things to appear... But I'm not sure what a good design would be. CCing @pfitzseb