ratpoison-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RP] sfdump and sselect bug introduced (Was: Add xrandr support)


From: |cos|
Subject: [RP] sfdump and sselect bug introduced (Was: Add xrandr support)
Date: Wed, 23 Nov 2016 08:43:23 +0100
User-agent: NeoMutt/20161104 (1.7.1)

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]