I'm running an R script via my Linux Mint 16 command line. It contains a boxplot that I want to display in a window. So I'm using x11() function for creating that window. Here is my code:
testdata <- data.frame(sample(1:1000,size=100,replace=T), row.names=NULL)
colnames(testdata)<-c("data")
x11()
boxplot(testdata, main="Boxplot der Testdaten", horizontal=TRUE)
When I run this function in Rstudio, it will open a window and show the boxplot created. But whenever I run it from the command line of my Linux Mint 16 machine, the window will open for a second and then close again. I can see the boxplot for a second. I couldn't really find a reason for this. I'm quite new to R and never used X11 before. Any ideas would be really appreciated. Thanks!
This is more-or-less a FAQ. Part of this is that you seem to misunderstand how all commands terminate. I.e. when you call ls it does not stop either.
So here you need to something extra. Possibly approaches:
Just sleep via Sys.sleep(10) which would wait ten seconds.
Wait for user input via readLines(stdin()) or something like that [untested]
Use the tcltk package which comes with R and is available on all platforms to pop up a window the user has to click to make the click disappear. That solution has been posted a few times over the years on r-help.
But in this day and age, you may also rethink the issue. I had good success preparing analysis and visualization for colleagues via the most-awesome shiny package which displays to a web page. Everybody has a web browser...
You can sleep until all windows are closed
while(names(dev.cur()) !='null device') Sys.sleep(1)
on my machine, after calling x11(), names(dev.cur()) is "X11cairo". After closing all/any windows opened with x11, names(dev.cur()) becomes "null device"
testdata <- data.frame(sample(1:1000,size=100,replace=T), row.names=NULL)
colnames(testdata)<-c("data")
x11()
boxplot(testdata, main="Boxplot der Testdaten", horizontal=TRUE)
# wait until window is closed (check every second)
while(names(dev.cur()) !='null device') Sys.sleep(1)
Related
I was wondering if it was possible to snapshot a workspace, i.e. save state not only of the layout but also of the windows which were opened.
Why do I need this?
Because I switch between different workflows. I may program for a while and then I may want to switch to a different activity, then switch back again to programming. On the average I have up to 7 windows on my workspace.
I need to save RAM for (freeze and lag)-less workflow.
I want to be able to close workspace 1, switch to another - workspace 2, then restore workspace 1 from the point when I had left it.
This should be totally manual, so I still can work on multiple workspaces. I have to control whether I want to close and restore previous workspace session.
When I restore the workspace, it should be just like I had left it, given that I hadn't changed the files or deleted programs that were opened.
Can this be done at all or at least some part of it with any WM?
Is this a stupid idea?
Does not running a graphical UI saves me RAM (how much)? - so maybe the windows should not be killed when closed, but rather run in the background (daemon), like in Tmux.
Earlier I tried i3 and Awesome(briefly). The biggest struggle was the toolbar, manual set up of volume, brightness, language switching control and proper fonts (on Arch Linux), I didn't fully succeed in setting my environment(I skimmed through wikis) so I fled.
Is it easier to set up Awesome in this respect?
Currently I use Cinnamon+Debian, and I'm almost happy with it.
I'd like to use touchpad less and therefore ask for advice.
I'll try to set WM up on VM first for painless transition.
I've done something similar before in i3-wm. I created a keybind to a bash script in my path that opens four terminator terminals on an empty screen. It uses the i3 command i3-msg to tell the window manager how the behavior of the next window opened will change. Here is my script:
terminator # opens terminal, change to the terminal that you use
i3-msg split h # tells i3 that the next window should split screen vertically
terminator # opens terminal
i3-msg split v # tells i3 that next window should split current one horizontally
terminator # opens terminal
i3-msg focus left # Changes selected window to the left one
i3-msg split v # tells i3 that the next window should split screen vertically
terminator
You should be able to take the i3-msg command and use it to control how windows of your applications open.
This is a quick, hacky solution, but it does work.
I hope this was able to help!
phylo
I wonder if there is a workaround for how to keep output from windows() open after R terminates.
To specify. I've built a system for production which is run from BASH. BASH runs the R instance and terminates it when it is finished. During the run it produces plots which i would like to display and keep open even after the R instance terminates so I can decide to keep them or not.
Can you keep the opened windows from closing or is there an alternative?
Don't really know what the example code would be here... since all im using is grDevices::windows().
Any suggestions?
# Plot data for overview ----
if(cfg$verbose) cat(crayon::green("Plot data for visualization of
problem\n"))
plots <- Learning_package::plot_iris(dat)
grDevices::windows();gridExtra::grid.arrange(plots$p1, plots$p2,
plots$p3, plots$p4,
plots$p5, plots$p6,
nrow = 2)
Expected result is to NOT close the window when bash is finished with its run.
I'm using Jupyter notebooks running an R kernel (3.2.2) in OSX, working through some basic stats exercises. A few days ago I played with ggplot for the first time, and ran some commands from a notebook cell experimenting with printing to pdf files, in other words using something like the following: pdf("file.pdf"); plot(x, y); dev.off() I didn't keep any of those cell contents, so I can't see exactly what I ran but I imagine it is possible I create some pdfs and didn't include a dev.off() command?
My problem is, since that session, now every cell I run in any notebook (including new blank ones) generates an unwanted pdf file. If that code involves plotting a figure, the pdf contains that figure, if the code is anything else, the pdf created is unable to be opened. I can't find any way, elegant or brutish, to stop these pdfs from being created.
If I go to a new blank notebook:
running dev.list() returns pdf: 2
running dev.cur() returns pdf: 2
running dev.off() returns null device: 1
but then, if immediately after, I run either dev.list() or dev.cur() again, they again return pdf: 2
I am able to open additional new devices, and dev.off() succeeds in closing them. But this pdf: 2 device won't go away. I tried terminating all my sessions, rebooting my machine, etc., to no avail; Suggestions?
Additionally, If I run a pdf() command from a console in Terminal (i.e., not from a notebook), my plots show as being generated by Quartz; I understand this might be a Quartz problem and not an R problem, but my question remains, how do I close this device, or otherwise stop all these pdfs from being created?
This may be a problem when a sink() has been opened but not closed, perhaps because an error occurred before the closing code was reached.
Try this to plug an open sink:
sink(NULL)
ht #mdsumner
graphics.off()
should forcefully close all devices. Check out this page for more useful information.
I am creating a package in R that will have a GUI interface through the tcltk package. A front end function will get the data from the user through a GUI and call a back end function which returns the results back to the front end. I currently have written all of the documentation for the functions, and except for this part and a bit of bug testing the functions are also complete.
To help the user out, I want to be able to print the documentation. In Rstudio this displays it in the help window (it is important to note that this window is not created by my code through the tcltk package, this window is a part of Rstudio).
If my function only interacts with the user through the command line, I can get the help screen in Rstudio to update immediately. However, if I am using the graphics, the help window won't update until after the function is done, which defeats the purpose of having it print the help screen in the first place.
Below is an example of a GUI window created through the tcltk package. I'm using var.test as an example documentation here, so make sure your help window is on something else to see when the help screen updates.
require(tcltk)
print(help(var.test))
hi <- tktoplevel() #creates a window
ok <- function() # this function is called by pushing the button defined below
{
print("Goodbye, World!")
tkdestroy(hi) # destroys the window
}
print("Hello, World!")
ok.button <- ttkbutton(hi, text = "This is a button", command = ok) #defines the button
tkgrid(ok.button) #puts the button on the window "hi"
tkfocus(hi)
tkwait.window(hi)
As you can see, even calling the help function first, before the tcltk graphics window is even created, doesn't make the help window update. The print function still seems to work, as "Hello, World" is printed before one presses the button.
For my functions to work properly, I must use the tkwait.window(), otherwise the front end won't sync with the back end.
If getting the Rstudio window to update isn't really possible, then an alternative solution that uses a different window or program would be acceptable.
Add a small delay into your code after trying to print the help:
....
print(help(var.test))
# Sys.sleep(0.01) # too short
Sys.sleep(0.5) # long enough
...
This works in Linux and Windows...
I guess RStudio is not updating the GUI while executing the R command batch (all commands that you send to R at once) because it blocks updates executes R in a "blocking sub thread" and therefore behaving like "single threading" so that the GUI cannot be updated until the execution of the R batch ends.
The sleep function seems to return the control to the RStudio (GUI?) process so that it can update the GUI.
If you reduce the sleeping time too much you can observe partial updates of the RStudio GUI.
PS: Using process.events() does not work!
I am very new to user interface using R. I have a png file. I would like to display it at the beginning of my script, keep it to stay for around 3 seconds and close it automatically.
I tried file.show(). R will pop the png file. But that is not what I want.
I prefer to make it appear in front of my IDE like a splash screen that appears before a program starts. I mean it will be similar to a welcome pic before the user really start to run the script. After 3 seconds, it will disappear and R will start to run the script automatically.
I wonder any R package can make my idea come true? Thank you.
This probably could get you started. The image will appear in the default RStudio bottom-right panel for 3 seconds and then will disappear. Warning: dev.off() will erase all your plots that you had in workspace before running the script.
#At the very beginning of the script, execute:
library(png)
img <- readPNG("path/baboon.png")
windows()
grid::grid.raster(img)
Sys.sleep(3)
dev.off()
#... your script continues here
print("Did you see that baboon??")
Edit: windows() does exactly what you need, I think