Displaying 20 results from an estimated 1000 matches similar to: "getGraphicsEvent() alternative for cairo graphics device?"
2016 Nov 13
4
getGraphicsEvent() alternative for cairo graphics device?
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
2016 Jul 25
2
getGraphicsEvent() alternative for cairo graphics device?
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
>
2016 Dec 08
2
getGraphicsEvent() alternative for cairo graphics device?
Hi
Just taking a bit more of a look at this today (currently fixated on
making sure I can build some good regression tests).
The best thing you can do is to keep reminding me like this :)
Paul
On 09/12/16 11:19, frederik at ofb.net wrote:
> Hi Paul,
>
> Thanks for your efforts. Do you have an idea when my patch(es) might
> be committed? Is there anything I can do to help move this
2016 Nov 14
2
getGraphicsEvent() alternative for cairo graphics device?
Great. Thanks!
Paul
On 14/11/16 13:41, frederik at ofb.net wrote:
> Hi Paul,
>
> Thank you, for some reason I didn't seem to get an email notification
> for your bugzilla comment!
>
> I will try to send you something shortly.
>
> Frederick
>
> On Mon, Nov 14, 2016 at 08:55:20AM +1300, Paul Murrell wrote:
>> Hi
>>
>> The current status is that
2016 Nov 14
2
getGraphicsEvent() alternative for cairo graphics device?
Thanks Frederick.
Mark, if you have any examples to share, they would also be gratefully
received.
Paul
On 14/11/16 14:53, frederik at ofb.net wrote:
> Hi Paul,
>
> OK I tried 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
2016 Jul 25
0
getGraphicsEvent() alternative for cairo graphics device?
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 some lines enabling
getGrahpicsEvent outside of a
2016 Nov 12
0
getGraphicsEvent() alternative for cairo graphics device?
Hi Paul,
Just checking in to see what the status is.
>From my perspective it seems logical to split off X11 into a separate
package, so development can proceed at a reasonable rate, but I
haven't yet tried to see if that's even possible.
Thanks,
Frederick
On Tue, Jul 26, 2016 at 09:23:35AM +1200, Paul Murrell wrote:
> Hi
>
> Taking a look at those patches is now on my
2016 Nov 14
0
getGraphicsEvent() alternative for cairo graphics device?
Hi Paul,
Thank you, for some reason I didn't seem to get an email notification
for your bugzilla comment!
I will try to send 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)
>
2016 Dec 08
0
getGraphicsEvent() alternative for cairo graphics device?
Hi Paul,
Thanks for your efforts. Do you have an idea when my patch(es) might
be committed? Is there anything I can do to help 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)
>
2016 Dec 08
0
getGraphicsEvent() alternative for cairo graphics device?
Hi Paul,
Thanks for keeping me posted and letting me know what I should do.
Are there regression tests for other graphics functions in R? To me
that sounds a bit unnecessary. I think you get more testing from
people who use R; and having a good turnaround for applying patches
(some have been waiting 5 years) would invite better participation.
Thank you,
Frederick
On Fri, Dec 09, 2016 at
2016 Nov 15
0
getGraphicsEvent() alternative for cairo graphics device?
Hi Paul,
No problem. Is it best if I post examples to the bug report 16951?
Kind regards,
Mark
--
Mark O'Connell, PhD student
Department of Mathematics & Statistics
231 Top Logic
National University of Ireland, Maynooth
----- Paul Murrell <paul at stat.auckland.ac.nz> wrote:
>
> Thanks Frederick.
>
> Mark, if you have any examples to share, they would also be
2016 Nov 14
0
getGraphicsEvent() alternative for cairo graphics device?
Hi Paul,
OK I tried 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
2016 Jun 09
3
getGraphicsEvent on X11 and event queuing
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
2016 Jun 07
2
getGraphicsEvent on X11 and event queuing
Hi R-Devel,
I've been working on an oscilloscope project using an Arduino
microcontroller board. I found that it's quite easy to get realtime
updates, e.g. 30+ frames per second, if I read data from the board in
a little Rcpp library. I have to use dev.hold() and dev.flush() to
keep the plot from flickering, which restricts me to the "cairo" X11
device.
I'd like to be able
2016 Sep 16
1
getGraphicsEvent() questions, minor feature/tweak request, and patch(es).
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 behavior, I figured getting
2008 Apr 13
1
getGraphicsEvent plotting two graph
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)
windows();windows(3,3,xpos=0)
dev.set(2);plot(1:x)
2016 Sep 17
2
Handlers in setGraphicsEventHandlers() can recursively call getGraphicsEvent(). Intended behavior?
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
2016 Sep 21
1
Handlers in setGraphicsEventHandlers() can recursively call getGraphicsEvent(). Intended behavior?
doKeybd() gets called in CHelpKeyIn() and NHelpKeyIn() in
library/grDevices/src/devWindows.c, where the call is encapsulated in an
'if (dd->gettingEvent)' block. So the only times this code ever calls
doKeybd() is when gettingEvent is in fact set.
Further, it's called in two locations in X11_eventHelper(), in
modules/X11/devX11.c, where the state of gettingEvent seems to be moot
2014 Mar 21
1
Memcheck: error in a switch using getGraphicsEvent
Hi the list,
One of my package has an (other) error detected by memtest that I do not manage to understand.
Here is the message that I get from Memtest
--- 8< ----------------
> try(choice(cld1))
Error in switch(EXPR = choix, Up = { : EXPR must be a length 1 vector
--- 8< ----------------
The choice function does call the choiceChangeParam function, which is:
--- 8<
2016 Jun 07
0
getGraphicsEvent on X11 and event queuing
... 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 an oscilloscope project using an