On Sat, Sep 13, 2014 at 09:57:33PM +0100, Thomas Adam wrote: > On Sat, Sep 13, 2014 at 09:49:06PM +0100, Dominik Vogt wrote: > > It's really crap that with xrandr you have to address monitors by > > name. Can't we restore all the old logic for the users of > > FScreen.[ch] and just sort the xrandr monitors in a way that > > matches the old numbering, i.e. 0 = global monitor and the rest in > > a constant order that doesn't change when new monitors are added? > > Maybe. But the problem there is two-fold: > > 1. Mapping existing Xinerama screens with their ordering to the _same_ > screens which XRandR reports (which we don't know, unfortunately); > > 2. This assumes XRandR enumerates its screens in some deterministic > order. Maybe it does, I haven't looked. > > I'm not sure what the problem is though---is there some significant > overhead I'm overlooking?
With Xinerama the first screen was always "0" and the second "1". This allowed me to make a config line Read .fvwm2rc.$[screen] to add special tuning to the first and second screen, and that worked on any machine. Now, the name of the screens may be different on another machine and I need a config file for each new name. Apart from that, the interfaces now need to fiddle with allocated strings which may lead to memory leaks and crashes. The old integer return value was safe in that respect. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
