Open dmurdoch opened 6 years ago
For point 2, have you tried to put the filter_slider in the header parameter ?
combineWidgets(header = filter_slider(...), ...)
Parameters header
, footer
, leftCol
and rightCol
can be used to insert arbitrary html elements around the charts.
I haven't tried that. It would probably display nicely, but I'm hoping for a fairly general solution, e.g. allowing the filter_slider
to be w2()
in my original example.
I guess appendWidget
could work by setting the footer
or rightCol
elements in a new object, e.g. appendWidget(w3(), c12)
could be done as combineWidget(c12, footer = w3())
. This strikes me as ending up with a more complicated result, but maybe it would work better. I'll do some experiments.
After a little bit of experimentation:
I can use the filter_slider
as a header or footer, but only with a new patch to the code in combineWidgets
to get its dependencies. (The new patch is part of PR#47 now.) The spacing looks fine.
I can't put an htmlwidget into the header or footer, only HTML tags or text. filter_slider
works because it isn't a widget, but something like
library(leaflet) library(manipulateWidget) combineWidgets(leaflet(), footer = leaflet())
produces this image in the RStudio viewer:
i.e. the second widget is displayed as text.
The
rgl
package commonly has several widgets in a display that need to communicate with each other. Recently I've addedcrosstalk
support, so this will become more common.Older
rgl
code usedmagrittr
pipes to glue together widgets in anhtmltools::tagList
. I've been experimenting with usingcombineWidgets
instead of atagList
, and this looks very promising, because things are automatically resized to fit the available space. (Issue #46 was related to this.).I've been working out a simple model. If
w1
,w2
, andw3
are functions producing widgets, thenw1() %>% w2() %>% w3()
should end up something likecombineWidgets(w1(), w2(), w3())
, except that the 2nd and 3rd widgets will see what came before, so they can set up communications.This requires a few hacks. I'm hoping that some of these things could be supported so I don't need the hacks.
w1() %>% w2()
is going to produce acombineWidgets
object (call itc12
) which will be passed intow3()
. That would be okay, but it makesw3
's job tricky to see the earlier ones, and it gets worse if there's a longer pipeline. Currently I'm grabbing thec12$widgets
element and assuming it's basically a list containing unmodified copies of the original widgets, then constructing a new combined widget by putting those two widgets together withw3()
in a single call usingdo.call(combineWidgets, c(c12$widgets, list(w3(), ncol = 1)))
. It would be nice if there were anappendWidget
function to allow this in a less hacky way.Another problem is that not all widgets are the same size. Some (like
rglwidget()
orleaflet()
) are pretty big, while others (likecrosstalk::filter_slider
) have fairly small heights. I'd like to have the sizing happen somewhat automatically (with the possibility for a user to override it), so I need to construct arowsize
vector for thecombineWidgets
call. I've been grabbing the oldrowsize
(e.g.c12$params$rowsize
in the example above) and adding one more entry to it in the newcombineWidgets
call. Perhaps the hypotheticalappendWidget
function could do something similar.Finally, I'm having trouble guessing at what size to put into the new
rowsize
vector. Mostly those sizes are determined in Javascript once the target location of the widgets is known, but it would be really nice to have a function that could guess what would happen, based on a default target location, and thesizingPolicy
of the widget.