The rgl package commonly has several widgets in a display that need to communicate with each other. Recently I've added crosstalk support, so this will become more common.
Older rgl code used magrittr pipes to glue together widgets in an htmltools::tagList. I've been experimenting with using combineWidgets instead of a tagList, 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, and w3 are functions producing widgets, then w1() %>% w2() %>% w3() should end up something like combineWidgets(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 a combineWidgets object (call it c12) which will be passed into w3(). That would be okay, but it makes w3's job tricky to see the earlier ones, and it gets worse if there's a longer pipeline. Currently I'm grabbing the c12$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 with w3() in a single call using do.call(combineWidgets, c(c12$widgets, list(w3(), ncol = 1))). It would be nice if there were an appendWidget function to allow this in a less hacky way.
-
Another problem is that not all widgets are the same size. Some (like rglwidget() or leaflet()) are pretty big, while others (like crosstalk::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 a rowsize vector for the combineWidgets call. I've been grabbing the old rowsize (e.g. c12$params$rowsize in the example above) and adding one more entry to it in the new combineWidgets call. Perhaps the hypothetical appendWidget 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 the sizingPolicy of the widget.
The
rglpackage commonly has several widgets in a display that need to communicate with each other. Recently I've addedcrosstalksupport, so this will become more common.Older
rglcode usedmagrittrpipes to glue together widgets in anhtmltools::tagList. I've been experimenting with usingcombineWidgetsinstead 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, andw3are 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 acombineWidgetsobject (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$widgetselement 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 anappendWidgetfunction 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 arowsizevector for thecombineWidgetscall. I've been grabbing the oldrowsize(e.g.c12$params$rowsizein the example above) and adding one more entry to it in the newcombineWidgetscall. Perhaps the hypotheticalappendWidgetfunction could do something similar.Finally, I'm having trouble guessing at what size to put into the new
rowsizevector. 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 thesizingPolicyof the widget.