On Wed, 30 Nov 2005 10:47:51 -0200 Carlos Eduardo Rodrigues Diogenes <[EMAIL PROTECTED]> babbled:
> Carsten Haitzler (The Rasterman) wrote: > > >On Wed, 30 Nov 2005 01:31:02 +0000 (GMT) "Carlos Eduardo R. Diógenes" > ><[EMAIL PROTECTED]> 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) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
