Every window manager creates a window over the root window?

[Carsten Haitzler (The Rasterman)]

On Wed, 30 Nov 2005 10:47:51 -0200 Carlos Eduardo Rodrigues Diogenes
<cerdiogenes at yahoo.com.br> babbled:

> Carsten Haitzler (The Rasterman) wrote:
> 
> >On Wed, 30 Nov 2005 01:31:02 +0000 (GMT) "Carlos Eduardo R. Di$(D+Q(Bgenes"
> ><cerdiogenes at yahoo.com.br> babbled:
> >
> >  
> >
> >>Hi,
> >>
> >>I read some time that some window managers creates a
> >>window over the root window and make all the
> >>operations over this created window.
> >>
> >>What I want to know is if this operation is a
> >>standard? If it's not, I would suggested that it
> >>became. I really have no idea if it's very difficult,
> >>but it is a important thing for visually impared
> >>people, because if a magnifier is running in split
> >>screen mode a lot of space is lost. So, if all window
> >>managers first create an window, we can adopt a
> >>standard to achieve the ID of this window and have
> >>methods to roll it from under the magnifier when the 
> >>pointer goes near the magnifier and the roll it back
> >>when the pointer go far. This way we don't lost
> >>desktop space and the user can have a better spacial
> >>locality.
> >>    
> >>
> >
> >come again? i don't know what you are getting at in terms of neeeding to mvoe
> >windows the wm created out of the way for a magnifier etc. and i'm no6t sure
> >you have a good idea about this "window over root" and what root is
> >
> the root window is the first window created by x window system and the 
> first window created by each client are children of the root window. 
> this is ok for you?
> 
> > and how
> >windows work
> >
> why not?
> 
> >. you need to explain in more detail your issue first. what's the
> >problem?
> >  
> >
> Ok, let's try it... if you can, start a GNOME session in your desktop 
> and do it:
> 
>     * open a terminal
>     * type "magnifier -mv" (if you have a complete GNOME installation it 
> will work)
> 
> Now, what you see? A screen that have only a half of useful space. Do 
> you think that it is good? I know that with composite we can minimize 
> this problem, but I talk with some user and test other magnifier 
> applications and a better solution is roll the screen, so the user still 
> see the non-magnified part and the magnified part. I know too that with 
> composite we can simulate this roll operation, but the cost will be to high.
> 
> If you want to see it working, switch on a window machine and install 
> Lunar or ZoomText and set these applications to split screen mode and 
> use for a while the system...

ok - instead of a magnifier overlapping part of the usable screen, while it is
active is moves everything aside. (i dont use gnome nor magnifier and thus
never really see it).

ok i see what you are thinking. you think most wm's make a window then put all
the client windows (app window frames) inside of this, and so its a simple
matter of asking the wm to just move its big container window, and allow the
magnifier app window to be outside of the container window.

if i got this right.

first - most wm's DONT do this. a very few do. most simply put app client
windows inide a frame and that frame is a direct child of root. to do this the
wm would need to move every toplevel window across - it'd need some sort of
signal to do so. basically what you are asking is hardish to do at an app level
and is easier for a wm to do internally as it knows its screen layout best.
sure we can create some hints and wait for apps. magnifiers, and wm's to do it.
technically a wm COULd treat a magnifier window specially and go move
everything aside if it sees one, and move it back when it goes away. the
problem is now the wm also needs to implement scrolling so the part moved
off-screen is accessible. the requirements blow out fairly quickly.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
$BMg9%B?(B
Tokyo, Japan ($BEl5~(B $BF|K\(B)