On Sun, 31 Jul 2005 09:33:25 +0200 xnowfall <[EMAIL PROTECTED]> babbled:
> > > Carsten Haitzler (The Rasterman) wrote: > > On Sun, 31 Jul 2005 05:16:16 +0200 xnowfall <[EMAIL PROTECTED]> babbled: > > > > > >> > >>Carsten Haitzler (The Rasterman) wrote: > >> > >>>>2. If I have an application open on the second display and right click > >>>>the title bar the close/iconify menu appears on the first display. > >>>>Probably just a bug though. > >>> > >>> > >>>just testing here - it works fine with mulithead and xinerama. menu comes > >up >>where it should. > >>> > >> > >>i've noticed this when opening a window (on screen 2) from an xterm (on > >>screen 1). the menu will then slide onto the screen of the xterm. if you > >>just move the new window a bit though e seems to catch on, and the menu > >>will appear on the proper screen > > > > > > can you describe in more detail? i can't reproduce here. this is e17's > > window border menu not the application menu? as in slide it actually > > animates (it starts on screen 2 and goes and slides onto screen 1) ? > > > > i have 2 screens. on the left screen is an xterm where i run say > xclock -geometry 48x48-0+0 > and the clock window opens at the top right of the rightmost screen. i > alt-right click the clock and the pointer jumps to the right border of > the left screen causing the menu, which pops up at the point where i > clicked, to start sliding towards the left screen. if i move the cursor > away from the edge the sliding stops as you'd expect. if i move the > window a bit, everything works as it should. > > this also happens in reverse, with the xterm on the right screen opening > the xclock on the left. also the middle-click window menu on the > desktop shows the window on the xterm's screen and the pager doesn't > seem to show the window at all; move the window and both are updated to > reflect its true position. the little label that pops up to show the > window position while you drag it also appear on the xterm's screen the > first time. > > so it seems that e isn't registering that the window is opened on a > separate screen from the window used to open it. > > my build of e is a couple of weeks old, so i could try upgrading if you > still don't see it, but it has always behaved this way for me as long as > i've used it (several months now). aaah now i get it. ok - much better description now. i could reproduce it. it was because the app explicitly asked for geometry that was OUTSIDE the current zone (where the mouse was) that confused e - basically all new windows get put on the current desktop in the current zone. ie where the mouse is OR the focused window. anyway - e tracks what zone (xinerama screen) the window is in when u move it etc. BUT it doesn't get it right at the start as at the start it goes "well go to the current screen" thus when u pop up a menu e THINKs its on the first screen even tho its on the 2nd and thus the menu handling goes weird (as it grabs the mouse and confines it to an invisible window the size and location of just the screen the window is on). fixed in cvs now - but u can fix this by just moving xclock from the 2nd to the first screen and back again then e will get its internal state right. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
