Re: mod_xinerama

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