search for: getgraphicsev

Dear R-helpers, I've just started playing with getGraphicsEvent() in R, and was wondering if there is a simple way to stop this function waiting for input after a pre-defined time, instead of relying either on a non-NULL value from one of the event handlers or for a user-interrupt for it to halt (as per the R manual). The only way that I've thought of t...

...ay, for instance to bind a key to save the current plot to a file, or to bind keys for adjusting the time scale etc. However, I ran into two problems: (1) setGraphicsEventHandlers only works on the "Xlib" X11 device, which doesn't support buffering via dev.hold() - it flickers. (2) getGraphicsEvent and friends lack some interface features which are needed to use the functions in an asynchronous fashion. Typically, event listener library functions have a "timeout" parameter, and the ability to return already-queued events. But getGraphicsEvent() has neither - it waits indefinitely...

... I just realized that setGraphicsEventHandlers or getGraphicsEvent could have an 'onIdle' callback, to be called somewhere in the polling loop of gevents.c:163 - I think this would solve my problem #2 in a minimally disruptive way. On Mon, Jun 06, 2016 at 06:38:45PM -0700, frederik at ofb.net wrote: > Hi R-Devel, > > I've been working on...

Hi the list, I need to use getGraphicsEvent to plot two graph. On the following toy example: - the function b is ploting two graph depending on a parameter - the function a is calling b according to some user answers. It is suppose to call b until the user press Return, but it does not. b <- function(x){ dev.off(2);dev.off(3)...

Hi Frederik, >>>>> <frederik at ofb.net> >>>>> on Tue, 7 Jun 2016 15:20:05 -0700 writes: > ... I just realized that setGraphicsEventHandlers or > getGraphicsEvent could have an 'onIdle' callback, to be > called somewhere in the polling loop of gevents.c:163 - I > think this would solve my problem #2 in a minimally > disruptive way. I hope you will get some feedback about this by one of the graphics/devices experts from within...

Hey all. As in general it's a bad idea to allow an event handler to generate an event, and as comments in the code seem to suggest this isn't the intention either, I was wondering about recursion in getGraphicsEvent(). In main/gevents.c, both doMouseEvent() and doKeybd() have the following line; dd->gettingEvent = FALSE; /* avoid recursive calls */ And they reset it to TRUE before returning. The effective result of this is that the event handlers on the R side are allowed to call getGraphicsEvent()...

...to FALSE after handling) ? > > Also, for this patch and for the other two you sent, one difficulty will > be with testing the patches. I have no testing code for this, so would > need at least a test or two from you (ideally someone would also have > some regression tests, beyond ?getGraphicsEvent, to ensure continuity of > previous behaviour). > > Paul > > On 18/09/2016 3:29 a.m., Richard Bodewits wrote: >> Hey all. >> >> As in general it's a bad idea to allow an event handler to generate an >> event, and as comments in the code seem to sugges...

Hi all, I'm writing an interactive plotting function for viewing fMRI datasets. Currently, I get keypresses using grDevices::getGraphicsEvent(). Unfortunately getGraphicsEvent() only supports the X11(type="Xlib") graphics device on Unix systems. The Xlib device doesn't support buffering (i.e. dev.hold() and dev.flush()), so redrawing the plots causes lots of flickering. Is there a way to get keypresses while using the...

...e handling then reset to FALSE after handling) ? Also, for this patch and for the other two you sent, one difficulty will be with testing the patches. I have no testing code for this, so would need at least a test or two from you (ideally someone would also have some regression tests, beyond ?getGraphicsEvent, to ensure continuity of previous behaviour). Paul On 18/09/2016 3:29 a.m., Richard Bodewits wrote: > Hey all. > > As in general it's a bad idea to allow an event handler to generate an > event, and as comments in the code seem to suggest this isn't the > intention eith...

Hey all. Setting a time limit with setTimeLimit(), and then using getGraphicsEvent(), will cause graphics event handling for the current device to break on timeout, until the device is destroyed and recreated. The problem lies in do_getGraphicsEvent() checking the value of dd->gettingEvent and concluding it's being called recursively (ironically this same test fails to...

...ust be a length 1 vector --- 8< ---------------- The choice function does call the choiceChangeParam function, which is: --- 8< ---------------- choiceChangeParam <- function(paramChoice){ texte <- paste(" ~ Choice : menu ~\n",sep="") choix <- getGraphicsEvent(texte,onKeybd=function(key){return(key)}) switch(EXPR=choix, "Up" = { if(xy[1]>1){ paramChoice['toDo'] <- "xy" xy[2]<-1 xy[1]<-xy[1]-1 param...

...d not to make the examples too fancy. Please let me know what you think. They should probably be amended to support the Windows platform, but I think that task would be much easier for someone with access to Windows... By the way I'm Cc'ing Mark O'Connell who shared with me some great getGraphicsEvent examples - well, I found them useful, perhaps if these are going to the R distro somewhere, then his examples should be included as well. Thank you, Frederick On Mon, Nov 14, 2016 at 01:51:08PM +1300, Paul Murrell wrote: > > Great. Thanks! > > Paul > > On 14/11/16 13:41,...

...erick > > On Mon, Nov 14, 2016 at 08:55:20AM +1300, Paul Murrell wrote: >> Hi >> >> The current status is that I am keen for people to contribute some testing >> code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951) >> >> There were also some getGraphicsEvent() changes/fixes suggested by Richard >> Bodewits (cc'ed), for which I am also seeking test code. >> >> Paul >> >> On 13/11/16 09:00, frederik at ofb.net wrote: >>> Hi Paul, >>> >>> Just checking in to see what the status is. >>&g...

Hey all, new R user and first timer here. I've been using getGraphicsEvent() on an X11-Xlib device in a kind of interactive loop, and would like to be able to stop it from printing newlines in the console when I don't actually want to print a prompt. Even an empty "" value still causes a newline right now. To not break any code that depends on this behav...

Hi Taking a look at those patches is now on my todo list, so I may be in touch with both of you at some point to request some testing. Paul On 26/07/16 07:17, frederik at ofb.net wrote: > Dear Daniel Greenidge, > > To enable getGraphicsEvent on Cairo, you have two patches to choose > from: > > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364 > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951 > > The second one is by me, and the first one is from five years ago by > Hugo Mildenberger. > >...

Hi The current status is that I am keen for people to contribute some testing code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951) There were also some getGraphicsEvent() changes/fixes suggested by Richard Bodewits (cc'ed), for which I am also seeking test code. Paul On 13/11/16 09:00, frederik at ofb.net wrote: > Hi Paul, > > Just checking in to see what the status is. > > From my perspective it seems logical to split off X11 into a separ...

Dear Daniel Greenidge, To enable getGraphicsEvent on Cairo, you have two patches to choose from: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364 https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951 The second one is by me, and the first one is from five years ago by Hugo Mildenberger. Both patches are very simple, they move so...

...nd you something shortly. Frederick On Mon, Nov 14, 2016 at 08:55:20AM +1300, Paul Murrell wrote: > Hi > > The current status is that I am keen for people to contribute some testing > code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951) > > There were also some getGraphicsEvent() changes/fixes suggested by Richard > Bodewits (cc'ed), for which I am also seeking test code. > > Paul > > On 13/11/16 09:00, frederik at ofb.net wrote: > > Hi Paul, > > > > Just checking in to see what the status is. > > > > From my perspec...

...move this along? Thanks, Frederick On Mon, Nov 14, 2016 at 08:55:20AM +1300, Paul Murrell wrote: > Hi > > The current status is that I am keen for people to contribute some testing > code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951) > > There were also some getGraphicsEvent() changes/fixes suggested by Richard > Bodewits (cc'ed), for which I am also seeking test code. > > Paul > > On 13/11/16 09:00, frederik at ofb.net wrote: > > Hi Paul, > > > > Just checking in to see what the status is. > > > > From my perspec...

...wrote: > Hi > > Taking a look at those patches is now on my todo list, so I may be in touch > with both of you at some point to request some testing. > > Paul > > On 26/07/16 07:17, frederik at ofb.net wrote: > > Dear Daniel Greenidge, > > > > To enable getGraphicsEvent on Cairo, you have two patches to choose > > from: > > > > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364 > > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951 > > > > The second one is by me, and the first one is from five years ago by &g...