Yesterday I got around to recompiling my ratpoison with the xrandr support
enabled and testing it out. I must say it's a very welcome feature addition.
However one thing that breaks my scripts is that the output of sfdump no
longer can be fed directly as input to sselect. When running sfdump with the
xrandr patch applied I now get this output:
% ratpoison --command sfdump
(frame :number 1 :x 0 :y 0 :width 1280 :height 998 :screenw 1280 :screenh
1024 :window 39845897 :last-access 48 :dedicated 0) 66,(frame :number 0 :x
0 :y 0 :width 1280 :height 979 :screenw 1280 :screenh 1024 :window
23068751 :last-access 47 :dedicated 0) 68
Please note how the screen numbers are 66 and 68. Previously they have been
0 and 1.
For completeness, I should mention that sselect still expects the screens to
be in the range that sfdump previously returned.
% ratpoison --command "sselect 66"
sselect: out of range
My interpretation of the documentation suggests that one should expect the
output of sfdump to be possible to be fed as the argument to sselect. The
manpage descriptions of mentioned commands are quoted below.
sfdump Output all frames similar to fdump, but not limited to one screen,
but all screens at once and with the screen number after each frame.
sselect screennumber
Switch to the screen screennumber. (If you have multiple physical
ones.)
I realize commit b5c1e280 disables sfrestore as broken, but have not looked
much more closely at the code than that. I have never ever used sfrestore,
but get the hunch that whatever broke that command might be connected with
this.
_______________________________________________
Ratpoison-devel mailing list
Ratpoison-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/ratpoison-devel
