Re: [RP] [PATCH 3/6] Disable sfdump if there is no xrandr support.

Mathieu OTHACEHE @ 2016-11-27 (Sunday), 17:58 (+0100) On the negative side, if the user unplug a screen and plug a different screen, it will have the same id as the previously unplugged screen. I would consider that expected behaviour. One could compare it with how a newly opened window

Re: [RP] [PATCH 3/6] Disable sfdump if there is no xrandr support.

Mathieu OTHACEHE writes: >> No idea whether how stable would be the mapping between Xrandr ids and >> ratpoison ids, though, as we don't control the former. There's not much >> choice though, but 1. you already have implemented a screen_sort >> function, and 2. this sounds

Re: [RP] [PATCH 3/6] Disable sfdump if there is no xrandr support.

> No idea whether how stable would be the mapping between Xrandr ids and > ratpoison ids, though, as we don't control the former. There's not much > choice though, but 1. you already have implemented a screen_sort > function, and 2. this sounds better than forcing the user to deal with > numbers

Re: [RP] [PATCH 3/6] Disable sfdump if there is no xrandr support.

Hi, > I think this is headed in the wrong direction. There is no reason to > disable this command when we can easily deal with the single available > screen. Yes I agree, it is not a very good idea after all. Maybe we could copy the old behaviour by mapping the Xrandr identifier to an integer