similar to: devX11.c -- questions about expose events and XBell

I am currently attempting to install R (v0.62.3) on our DEC Alpha computer, and have solved one problem but now am having another: When issuing the 'make' (after ./configure), I get the error shown at the end of this output: ============================================================================ ======= cd main; make make[3]: Entering directory `/usr/local/src/R-0.62.3/src/main'

Dear R developers, I've been experimenting with embedding R X11 windows into another application using KDE's QXEmbed on linux. Attempting to do so will crash R (with R 2.4.0, trunk, and I know the bug has been around in prior versions). I used to think this was related to bug #848, but I'm not sure, if / how the solution suggested there still applies to current versions of R.

Hello, I use a software that outputs the data in a form/dialect(?) of xml (I think its called "SpreadsheetML", see below for an excerpt). It allows (admittedly) easy import of such files into Excel. I would like, however, to import it directly into R. I am familiar how to do that with standard xml-files (mostly thanks to Duncan Temple Lang's help). But I haven't found the right

Hi, [I'm Using redhat linux 7.1 with R-1.4.1 rpms.] Last summer, Henrik Bengtsson wrote to R-help: > Is there a way to turn of the (annoying) beep that occurs when one calls the > locator() command and clicks the mouse. Try > > plot(0) > locator(n=10) > > I am running Rterm on WindowsMe/Cygwin bash and I don't know if this is the > case on other platforms.

Hi, there are two problems in devX11.c. The one is an undocumented nuisance and the other isn't a bug until you try to embed an X11 device in another window (think tktoplevel() in tcltk package...). Let's take a look at locator() first: Assuming you call locator() with a current X11 device, this call is handled in X11_Locator (src/unix/X11/devX11.c). When you have one window open and

I've done some work getting the patches from http://starcraft-wine.sourceforge.net/ working with CVS wine. Using the patch I'm including, starcraft works perfectly on my machine, run as root using DGA on a 640x480 XF86 layout. In particular the changes to event.c enable the mouse and keyboard with DGA. The changes to input.c make the mouse acceleration work the same in all directions.

Attached are my draft patches to add edge + mouse button to the actions It is useful because the edge bindings are too easily triggered, an edge + mouse button is good because it confirms the action. An additional side benefit is that the mouse wheel can be used for rotating the cube and for the switcher (it is an excellent alternative to alt-tab). I wanted to share the patches before cleaning

Has anyone else noticed that their normal system beep (from XBell() and the like) no longer works after upgrading to CentOS 4? Here's a list of my sound modules: snd_intel8x0m 14276 0 snd_intel8x0 26528 1 snd_ac97_codec 67296 2 snd_intel8x0m,snd_intel8x0 snd_pcm_oss 47652 0 snd_mixer_oss 16384 2 snd_pcm_oss snd_pcm 79880

Hi, I'm Luca from Savona, Italy. I'm using Compiz and I'm writing an application with Xlib to draw two windows, let's say window_A and window_B. I would like to keep fixed the relative position between two established corners of them that they have when mapped. So that if I move or resize one of the window, the other if necessary automatically moves to observe the condition.

[accidentally was sent to the R-help-owner only; MM] ** when I compile R-0.62.3 on RedHat 5.1, the following messages appear: ... f77 -export-dynamic -o R.binary ... ../lib/libunix.a(dataentry.o): In function `NextEvent': /home/ming/R-0.62.3/src/unix/dataentry.c:1286: undefined reference to `XNextEvent' ../lib/libunix.a(dataentry.o): In function `GetKey':

Hi Luca, In recent versions of compiz (0.9.10) if you have lazy positioning on (org.compiz.move 'lazy-positioning') other clients won't get a configure notification until the end of the move. This is a performance optimization to avoid a slow path on the nvidia drivers with vsync. If you want such notifications you need to turn this option off. Either that or implement this as a

Hello. System info: OS: FC6 x86_64 video: Nvidia GF 7900 GT, driver version 97.55 compiz version: git config backend used: ccp I can reproduce this crash every time on my system. When blur plugin is active and I try to access any right-click menu, regular application menu or drop-down list, compiz crashes. Backtrace produced by crashhandler plugin shows crash in blur.c in function

(Hope this is the right place to post this message.) Hi all, I am working on a small movie player which can play full screen movie using Xserver. It works fine in Single Head Mode. But is I set the Xserver in Dual Head Mode. I can't see any thing on both screens. The Code to Init the display is shown as below: > display = XOpenDisplay(NULL); > if (display == NULL) >

(Hope this is the right place to post this message.) Hi all, I am working on a small movie player which can play full screen movie using Xserver. It works fine in Single Head Mode. But is I set the Xserver in Dual Head Mode. I can't see any thing on both screens. The Code to Init the display is shown as below: > display = XOpenDisplay(NULL); > if (display == NULL) >

Hi Sorry, I can't offer an explanation for the commented-out line. However, regarding your final question of avoiding the R-core bottleneck, you do have the option of creating a third-party graphics device package. See, for example, the 'tikzDevice' and 'svglite' packages on CRAN. Does that provide you with a way forward ? Paul On 20/04/2019 5:27 p.m., frederik at

OK, so I did the archaeology anyway.... This was the story, R-core November 29, 2001. Part of thread "X11 still segfaults". ------------>> ..... Gah. I've been too tired today. Why did that take me so long? The culprit seems to be R_ProcessEvents((void*) NULL) in newX11DeviceDriver This gets called *before* this stuff at the end of Rf_addX11Device dd =

I had a look at the current code, and AFAICT it has essentially the same structure as it did back then. I think it may have finally dawned upon me what the issue really is: The logic is that in Rf_addX11Device, we have if (!X11DeviceDriver(dev, display, width, height, ps, gamma, colormodel, maxcubesize, bgcolor, canvascolor,

OK, this is now in R-devel, but only superficially tested (b/c this is a Mac). Please check it out. -pd > On 30 Apr 2019, at 23:09 , Paul Murrell <paul at stat.auckland.ac.nz> wrote: > > Hi Peter > > Yes, that looks roughly right to me. I would be in favour of your option (b), partly because it is probably easiest and partly because that retains the basic graphics device

Dear R Devel, I know that someone put this line in src/modules/X11/devX11.c:2824 for a reason, because commenting it out causes R to miss an important ConfigureNotify event in my window manager. The result is that plots are initially drawn off the window borders, unreadable. R_ProcessX11Events((void*) NULL); Unfortunately for me, this line is commented in the standard release of R, it has

I don't recall exactly what I did 18 years ago eiher and I likely don't have the time to dig into the archives and reconstruct. I can imagine that the issue had to do with the protocol around creating and mapping windows. Presumably the segfault comes from looking for events on a window that hasn't been created yet, or has already been destroyed, leading to a NULL reference somewhere.