On Sat, Sep 13, 2014 at 10:17:15PM +0100, Thomas Adam wrote: > On Sat, Sep 13, 2014 at 10:06:01PM +0100, Dominik Vogt wrote: > > 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. > > Well, I like to think I can just about handle free()ing the things which > are allocated, but I'm human so I'll always make mistakes. ;) However, > I'm only working with the API XRandR gives me, and that inherently works > with strings as monitor names/identifiers, not numbers. > > What's irritating though is XRandR allows you to configure the > "ordering" of monitors---rather, their placement with respect to one > another. But that's wishy-washy with respect to ascertaining that > ordering. Take the following from my workstation here at home: > > % xrandr -q > Screen 0: minimum 320 x 200, current 3840 x 1080, maximum 8192 x 8192 > VGA1 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) > 477mm x 268mm > 1920x1080 60.00*+ > 1600x1200 60.00 > 1680x1050 59.95 > 1280x1024 60.02 > 1440x900 59.89 > 1280x960 60.00 > 1280x800 59.81 > 1024x768 60.00 > 800x600 60.32 56.25 > 640x480 60.00 > HDMI1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) > 477mm x 268mm > > That's the ordering from xrandr itself, and you canm see it lists VGA1 > first, despite the fact that it's technically right of HDMI1 (look at > the geometry strings!)
Urks. > I'll see if I can enumerate the monitors based on some logical > positioning without the need to refer to them by name, but I fear it > might be a bit hit-and-miss when the "usefulness" of the API with > respect to referring to monitors by names is being thrown away. It's perfectly allright if the *User* specifies these strings, but it would greatly simplify the internal logic if the strings could be translated to numbers in FScreen. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
