Hi, Timandahaf ([EMAIL PROTECTED]) wrote on 2008-09-21: > I haven't poked around to see why this happens, but if you could shed > some light on the issue and why that line appeared in the latest version > (and if it also crashes for you while restarting), that would be great.
That line was a rather short-sighted fix to the problem indicated by the comment - goto_next_scr and goto_prev_scr didn't properly wrap around with the way mod_xinerama is implemented (i.e. goto_next_scr on the last screen didn't go to the first screen and the other way around). The problem is that the root window has its own WScreen object, which contains the Xinerama screens as children, and whenever we hit that screen in goto_*_scr, it simply stays where it is. I though I could just fix it by removing the extra screen for the root window from the ioncore_g.screens list, but this then causes the crash on restart, since the destructor for a WScreen object assumes that the object is in the list. How would one do this properly? From my analysis of ioncore_goto_*_scr, it doesn't seem possible to exempt a screen from the iteration list. They also _seem_ to be intended to do wrapping, but I don't see how this would ever have worked (but I don't have the old Xinerama code around to really check). The next thing I though of was writing lua wrappers to goto_*_screen which would just skip the default screen, but it appears that there is no easy way to distinguish the root window screen from the Xinerama screens in lua. About the only thing I can think of is that it's the only screen that can't be found ioncore.find_screen_id(), but that is starting to feel like too much of a crutch. ciao, -- [*Thomas Themel*] Tim has been implying that I am a pinko, gold nut, and [extended contact] randroid, which sort of hints that Ayn Rand is too pink [info provided in] for him. [*message header*] - James A. Donald about Tim May on cypherpunks
