I am familar with matlab, but relatively new to r. I have an r script which produces many different graphical plot windows and takes some time in between each one. While this is running, I tend to be working on other things. The problem is every time a new graphics window is produced, it steals the focus, redirecting keyboard input away from what i am doing. Is there a way in r to prevent focus stealing when a graphical plot is produced?
I have searched everywhere but failed to find any reference to this. I am working in linux.
Any help greatly appreciated.
Thanks
Only on Windows: try putting a bringToTop(-1) in your function:
z <- function() {
plot(1:3)
bringToTop(-1)
}
z()
It will temporarily steal focus but then return it.
Another strategy on Windows:
z <- function(){
windows(restoreConsole=TRUE)
plot(1)
}
z()
I'm still thinking here...
If you are more interested in doing something else while the plots are being produced then I would suggest opening a pdf device so that all the plots go to a pdf file in the background and do not interfere with whatever else you are doing. Then when you are ready to look through the plots you just open the pdf file and look at the plots (and you can easily go back to previous plots this way).
If wmctrl is installed on your system, you can avoid losing focus by redefining the plot function like this:
plot <- function(...) {
graphics::plot(...)
system("wmctrl -a :ACTIVE:")
}
It seems to work quite well, in the fluxbox window manager at least. I tried different scenarios like switching to a different window during a long calculation before plot is called, and opening multiple plots.
Put it into your .Rprofile if you want it to persist.
Related
I am using the effects package in R to derive (and plot) the effects of a complicated linear model.
When I use allEffects(linearModel) I can see the results on screen and save it to a pdf file as usual. Since the model has many terms, the output is not useful as it stands.
Therefore I use effects(someTerm, linearModel) to focus on the terms of interest and the results on screen are what I need. However, when saving it to a pdf file, the file contains no useful output (though it does take up 3.5Kb of space). There is no error message from R at the console.
To ease understanding, I created a simple data set and a script for generating the effects plots, in the same way that I tried with the "real" model.
factorData.csv
A,B,C,y
a1,b1,c1,3
a1,b2,c1,4
a2,b1,c1,5
a2,b2,c1,6
a1,b1,c1,2
a1,b1,c2,3.5
a1,b2,c2,4
a2,b1,c2,5.1
a2,b2,c2,6.2
plotEffect.r
require(effects)
dataFile <- '/tmp/factorData.csv'
effectABfile <- '/tmp/effect_AB.pdf'
effectABCfile <- '/tmp/effect_ABC.pdf'
allEffectFile <- '/tmp/lm_eff.pdf'
df <- read.csv(file=dataFile,header=TRUE,sep=',')
linearModel <- lm(y~A*B*C,data=df)
lm_eff <- allEffects(linearModel)
pdf(file=effectABfile)
plot(effect('A:B',linearModel))
dev.off()
pdf(file=allEffectFile)
plot(lm_eff)
dev.off()
pdf(file=effectABCfile)
plot(Effect(c('A','B','C'),linearModel))
dev.off()
As you can see, I tried allEffects, effect and Effect; allEffects is the only one that works for me. Please note that the script assumes that the data is placed in /tmp/factorData.csv - you might need to change the path of course. I also randomised the order in which the plots are generated, with no effect.
I had a look elsewhere on stackoverflow and saving plots to pdfs fails was the closest but the advice there (to issue dev.off() after each plot to 'close' the pdf file) is something I do already, as seen in plotEffect.r.
I tried this script on 2 machines, each running Lubuntu 14.04.1 64-bit with R version 3.0.2 and the latest effects package installed within R using install.packages. The results were the same.
I would be very grateful for advice on how to fix the problem of saving (instances of) this plot type to a pdf.
Fix/workaround
As suggested by #Roland in the comments below, if you wish to save grid plots (such as the output from the effects plots in this instance) into pdf files, it is better/more reliable to generate the plots separately/manually (rather than in a script). It does not appear to be (as much of) an issue for base graphics or even ggplot2 graphics, where I for one have never encountered this problem/needed this workaround in the past. Thanks to #Roland for suggesting this fix!
#Roland also added that Sys.sleep() might help in scripts. Although it did not do so in my case, I discovered that it was possible to paste several such plotting commands and R would run them as a batch, saving the plots to pdf correctly. Therefore, I believe it should be possible to recover much of the benefits of running the script by taking these steps:
Use R to create the text representation of the pdf(), plot() and dev.off() triad of commands
The main script outputs this plotting command text (specific to each instance of a plot) to a file
Open the plotting command text in a text editor
Copy the entire contents of the commands file and paste it into the R console
Optionally, you may wish to use the command line in Step 3 and 4 - How can I load a file's contents into the clipboard? has useful advice.
This two stage procedure is a reasonable workaround, but arguably there should be no need for it.
I am using the plot() function to plot the diagnostics from the MCMCglmm package (I don't think it's important which package I'm using as the same thing happens with other packages):
fit <- MCMCglmm(.....)
plot(fit)
This then produces a page of plots, and in the console it says Waiting to confirm page change... Normally when I want to save a plot (for example to put in a word processing document) I just right-click the plot and select one of the options, such as "copy as bitmap". However, when I do this with multiple pages of plots, the right-click causes the next page to display and I am only able access the final page. Is there a way to prevent this, or another way to access the intermediate pages ?
Actually, it is important, which package you use, since usually they come with their own plot method.
E.g., plot.lm and some others have the parameter which:
fit<-lm(c(1,2,4,5,6)~c(3,4,5,6,7.2))
plot(fit)
plot(fit,which=1)
plot.MCMCglmm doesn't seem to have this parameter:
require(MCMCglmm)
data(PlodiaPO)
model1<-MCMCglmm(PO~1, random=~FSfamily, data=PlodiaPO, verbose=FALSE)
plot(model1)
plot(model1$VCV)
plot(model1$VCV[,1])
plot(model1$VCV[,2])
plot(density(model1$VCV[,1]))
plot.default(model1$VCV[,1],type="l")
The solution is quite trivial. You can press "Esc" key, to stay on the current plot and copy/save it.
Why don't you use
dev.print(width=480,height=480,device=png,paste("folder/graph",i,".png",sep=""))
This is observed running in batch. Given the following code snippet, I don't understand why R creates an empty jpeg file in Windows even though I am not calling a plot or graph. When I run similar code under Linux or OS X, the jpeg file is not created. I don't know ahead of time if the user is going to want a plot so I setup the filename(s) ahead of time and give them a name and location.
##
sink("c:\\temp\\test.lst")
jpeg(file="c:\\temp\\test%d.jpeg")
norm <- rnorm(100)
print(norm)
Any suggestions would be appreciated.
The ?jpeg help file (which also applies to bmp(), png() and tiff() devices) indicates that:
The ‘type = "windows"’ versions of these devices effectively plot
on a hidden screen and then copy the image to the required format.
This Windows-specific implementation detail most likely explains the difference in the behavior of Windows and *NIX systems.
On Windows, calling any of the functions above (and pdf() and postscript() as well) creates a file --- whether or not you then plot anything to that hidden screen. Except for pdf() (which produces files that I can't open with a viewer), the image that's registered on the plotting device is that of a white rectangle of height and width specified in the call to the specific device.
I wouldn't worry about it. if the prospect of zero-length files cluttering up the folder bothers you, you can clean up afterwards with something like
jpgs <- file.path("c:/temp", dir(pattern="c:/temp/test[0-9]*\\.jpeg"))
s <- file.info(jpgs)[["size"]]
for(i in seq_along(s))
if(s[i] == 0) file.remove(jpgs[i])
I generate a dendrogam using a collection of r commands. It worked just fine and saved the generated dendromgram into a PDF file. To improve efficiency, I wrapped these commands as a function, which does not change anything. However, the pdf is just a blank file without any graphical content. Please let me know what’s wrong with my function defintion. Thanks.
myplot<-function(inputcsv, outputfile){
library(ggdendro)
library(ggplot2)
x<-read.csv(inputcsv,header=TRUE)
d<-as.dist(x,diag=FALSE,upper=FALSE)
hc<-hclust(d,"ave")
dhc<-as.dendrogram(hc)
ddata<-dendro_data(dhc,type="rectangle")
ddata$labels$text <- gsub("\\."," ",ddata$labels$text)
ggplot(segment(ddata))+geom_segment(aes(x=x0,y=y0,xend=x1,yend=y1))
pdf(outputfile, width=30,height=35)
last_plot()
dev.off()
}
R FAQ
Wrap your ggplot call in a print() function.
ggplot and friends return an object, and the plotting only happens when the object is printed. When you do this on the command line the printing happens automatically. When you stick it in a script or function you have to do it yourself.
The debate on whether this is a good idea or a dumb thing that just generates questions like this continues...
Is it possible to source a file without printing all the charts etc (already tried with echo=F)?
In my case I call the png("filename%03d.png") device early in the script. It is not to big a hassle to comment this out - but all the charts do take a lot of time to render. (the specific file I am working with now uses base-graphics - but mostly I'll be using ggplot2 - which makes the issue somewhat more important (ggplot2 is excellent, but in the current implementation not the fastest))
Thanks
It's not a problem for ggplot2 or lattice graphics - you always have to explicitly print them when they are called in non-interactive settings (like from within a script).
Good practise for coding R means wrapping as much of your code as possible into functions. (See, e.g., Chapter 5 of the R Inferno, pdf.) If you place your plotting code inside a function, it need not be displayed when you source it. Compare the following.
File foo.r contains
plot(1:10)
When you call source('foo.r'), the plot is shown.
File bar.r contains
bar <- function() plot(1:20)
When you call source('bar.r'), the plot is not shown. You can display it at your convenience by typing bar() at the command prompt.
Perhaps this might be of some help...
"A package that provides a null graphics device; includes a vignette, "devNull", that documents how to create a new graphics device as an add on package. "
from http://developer.r-project.org/
It's not the best sounding solution, but If you might be running this script often like this, you could declare a boolean whether graphics are required (graphics_required=TRUE) and then enclose all your plot commands in if/then clauses based on your boolean, then just change the boolean to change the behaviour of the script