use_busy_gif() not displaying gifs on local disc

[Nick Howlett]

Hi,

I think I have discovered a bug with the package. I am aiming to use a gif stored in a local directory in an app via a path-string: use_busy_gif(src = "path/to/gif.gif").

My code works as expected using a url to a gif hosted online, or alternatively by using the logo_silex() function (which produces a path-string to gif on your file system) to read the silex logo from package files.

So it's rather confusing me that I can not display any other gif that I have saved locally to my machine. Here's a MWE of an app where I can not produce the behaviour expected:

library(shiny)

ui <- fluidPage(
    titlePanel("play-stop loading-gif"),
    use_busy_gif(src = "data/banana.gif",
                 height = 70, width = 70),

    actionButton("play", "Play GIF"),
    actionButton("stop", "Stop GIF")
)

server <- function(input, output) {

    observeEvent(input$play, {
        play_gif()
    })

    observeEvent(input$stop, {
        stop_gif()
    })
}

# Run the application
shiny::shinyApp(ui = ui, server = server)

Would anyone be able to confirm or deny that they can get a local gif to display using this function?

Something worth noting is that it does seem like something is displayed when this is run. If you play with the position argument to "top_left" you can see it interfering with the shinyUI buttons. However, at the very least it's not displaying properly.

I am building the app on an RStudio server, but have also tried and had the same issues locally. Here's my session info:

> sessionInfo()
R version 3.6.3 (2020-02-29)
Platform: x86_64-redhat-linux-gnu (64-bit)
Running under: CentOS Linux 7 (Core)

Matrix products: default
BLAS:   /usr/lib64/libblas.so.3.4.2
LAPACK: /opt/mango/R/3.6.3/lib/R/lib/libRlapack.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8    
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8    LC_PAPER=en_US.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C             LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] shinybusy_0.2.0 shiny_1.4.0    

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.3        digest_0.6.25     later_1.0.0       mime_0.9          R6_2.4.1          xtable_1.8-4     
 [7] jsonlite_1.6.1    magrittr_1.5      rlang_0.4.5       promises_1.1.0    Cairo_1.5-10      tools_3.6.3      
[13] htmlwidgets_1.5.1 rsconnect_0.8.16  httpuv_1.5.2      fastmap_1.0.1     compiler_3.6.3    htmltools_0.4.0

[Victor Perrier]

Hello,

You have to put the gif inside a folder named www/ in the root folder of your application, with a structure like this:

+-- ui.R
+-- server.R
\-- www
    +-- data
    |   \-- banana.gif

Then you can use in your UI:

use_busy_gif(src = "data/banana.gif", height = 70, width = 70)

The www folder isn't weel documented, but it's a place where you can put files that you want to include in the HTML page created by shiny, like CSS or JavaScript files or images too.

Victor

[Nick Howlett]

Hey Victor, thanks for the response.

I did see that in the documentation, however, it does say "Path to the GIF, an URL or a file in www/ folder", which would imply that the www/ folder isn't a necessity but works if you follow that development process. Also this doesn't clarify why using logo_silex() works but any other gif (not in a www/ directory) doesn't work, which I'd still like to clear up.

Edit: Also I just tried using adding the directory structure as you laid out (only difference being I use a single app.R file) and it still shows the same issues as pointing to a path not inside a www/. Can you confirm that it works on your machine? Did you try it?

[Victor Perrier]

Yes I wrote and try that function ;)
And yes it works if you follow my comment above.

www is the default resource folder for shiny apps, when you point to files in that folder in HTML you don't need to start by www/.

You can try including an image in your application with tags$img(src = "data/banana.gif"), that's the same principle.

Here's a note from Shiny documentation:

A note about www/
One thing you may notice is that we placed our CSS file in the subfolder www/, but we only specified the CSS file’s name (dark_mode.css) in our href or “hyperlink reference” argument. The www/ folder is a special one for Shiny. Resources your app may link to, such as images—or in this case, scripts—are placed in the www/ folder. Shiny then knows to make these files available for access from the web browser. If we had placed dark_mode.css at the same file hierarchy next as app.R, Shiny would not know that it needs to host it, and your app would tell the browser to look for a file that was not available to it.

Read more here : https://shiny.rstudio.com/articles/css.html and here : https://shiny.rstudio.com/articles/packaging-javascript.html

logo_silex()is a special case where I needed to made an image included in the package available to shiny applications, this is possible withshiny::addResourcePath`.

[Nick Howlett]

EDIT: Okay so I retried this again and got different behaviour..

Thanks again for the response, I've done a little more digging and have got it to work but only under the following conditions:

- App must be split into ui.R/server.R files
- Gif must be inside /www directory
- App must be initiated with runApp() or shinyAppDir() (not shinyApp())

We use a slightly different process to launching our apps, with a call to print(shiny::shinyApp(ui = ui, server = server)) within a single app.R file which we source(). This does not produce the same behaviour, which was what tripped me up. I believe this is to do with {shiny} and not {shinybusy}.

It seems in our case (which is very niche) we use print(shinyApp(...)) so that when you source() the app.R file the app is launched (which isn't the case without a call to print()). Further investigation seems to point towards the print() call being the culprit for the varied behaviour.

I'm not sure if you were aware of this, or understand what could be going on, I'll concede that I'm not knowledgeable enough with {shiny} to appreciate the differences between the various ways of structuring and subsequently starting up an app but I thought I'd update this here for your reference. In any case, we've found a way of working around this.