[xmonad] Bug in program depends on number of tiled windows
wirtwolff at gmail.com
Sun Mar 11 22:54:18 CET 2012
Excerpts from John Jumper's message of Sat Mar 10 21:24:31 -0700 2012:
> I am trying to isolate and/or work around a bug in the R statistics software
> (r-project.org), and the bug seems to depend on how many windows are managed
> by a tiling layout, regardless of how many windows are in a float layout. I
> am using R 2.14.2 and Xmonad 0.9.2.
> Steps to reproduce:
> $ R
> > dev.new() ; plot(1, main='plot 1')
> > dev.new() ; plot(1, main='plot 2')
> > dev.new() ; plot(1, main='plot 3')
> > # plot 2 is now blank
> > # floating any of the plot windows and then resizing the tiled layout causes
> > # all plot windows to draw correctly
> > dev.new() ; plot(4, main='plot 4') # now plot 3 is blank
I'm looking into this bit by bit, but I suspect I've not enough X11 and
C knowlege, nor time, to do more than list symptoms. The R codebase is
pretty well documented, but it's large and complex.
I can definitely reproduce something like this, although what draws and
doesn't draw seems to be a bit different here. I'm still cataloging
results under different conditions, so I've not made much sense of it
yet. FWIW I'm running R in a small urxvt floating scratchpad, not a
tiled terminal. Also FWIW R doesn't set resize hints (which would be
very plot dependent anyway.) It sets only location and size.
With two, three, or four, all but the newest are blank until resized, so
far as I can tell with just a few tests.
Mod-n to refresh and focus changes do nothing, but any xmonad operation
that resizes triggers redrawing.
Another weird symptom is that with 3 plots, the third plotted and the
first two blank... changing to an empty workspace and then back to the
plot workspace draws two of the plots but not consistently. Sometimes 1
and 3 get drawn, and other times 2 and 3. :/
Toggling plots to and from full-screen also give unpredictable behavior.
However, if I leave the misbehaving workspace on one monitor, and then
plot some more on the other monitor (move the scratchpad to that
monitor) they all consistently plot fine.
It's very confusing so far.
I tried your reproduction steps with a very minimal build of R, to
eliminate the cairo and tk code from consideration, and before that with
my normal build. Both acted strangely with tiling layouts.
So far here it seems as if already drawn plots get cleared when the new
one resizes all of them, and they don't get redrawn until they are
resized again, but that's not the whole story even if it's correct.
As a workaround till the real problem gets identified, my normal R
workflow /might/ work for you. I have always floated my R plots, since I
want to preview them at correct size to print to pdf or png. Using the
hook className =? "" --> doFloat accomplishes that. That in itself is
enough to draw plots correctly, but forces you to specify sizes and
possibly locations in the code, unless you manually move them around and
I use Actions.Navigation2D for the navigation, as it easily moves
between the float and tiled layer and navigates or swaps directionally.
I use the mouse to move the windows, and if needed resize, via
A.FlexibleManipulate. For z-order, I use swapUp swapDown on the
Also, there are snap and float key modules in xmonad-contrib, for
manipulating floats from the keyboard that might be useful if you work
with a lot of plots at once.
> Is there an important property that distinguishes tiled and floating
> windows from the perspective of X, rather than Xmonad?
Perhaps some of the X11 experts on the list can help with that question.
More information about the xmonad