Dne 22 Září 2008, 12:02, Thomas Themel napsal(a): > ... > > 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.
And moreover I sometimes need to have DOUBLEFULLSCREEN window. And sometimes full(single)screen. Thus I want the root window lua-accessible. (Then I can do :attach directly to RootWin to have DoubleFuckScreen window.) P.S: It served me very well on conference, where I want to put upper half of my pdf-presentation to beamer and lower half to my laptop screen. Then I had notes for myself on my screen and the presentation itself was on beamer. > 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. What about testing its :parent() ? RootWindow has none, Screens have the rootwindow :-). I think that mod_xinerama should be rewritten to something like mod_xrandr_ng, to support screen reconfiguration in online manner. Together with some handy scripts to save layouts for each xrandr config separately. (Now I have to restart ion after screen reconfiguration, I use ioncore.set_paths() to get layout saved for actual setup.) -- . Tomas Ebenlendr . http://drak.ucw.cz/~ebik
