Re: FVWM2 Xinerama patches
Hi! Sorry for replying so late (and Dominik had applied the patch anyway), but still... On Mon, 24 Sep 2001, Sidik Isani wrote: [SNIP] > | Second, regarding translation of program-supplied geometry to > |non-global screen: what will happen to those programs which save their > |windows' geometries on exit and use them on restart? Wouldn't the > > They should work correctly. My first patch, with %'ing (which would > have broken on unequal screen sizes) is no longer needed either. > Here's why: Let's say an application is started with > > Xresource: foo.wmscreen: 1 > Command: foo -geometry +6+10 > > and we're using your example screen layout: > > |+---+---+---+ 1024*3 > || 0 | 1 | 2 | > |+---+---+---+ > > The application doesn't even look at "wmscreen", but it requests > a position of +6+10 on the global screen. GetScreenXY figures out that > this pixel falls on screen 0 and returns screen-relative coordinates > of +6+10. This is added to screen_g.x,y, the origin of screen 1 > (because of the *wmscreen: 1) resulting in global +1030+10. The window > pops up on screen 1 (no matter what the current screen is.) > > If the application saves this as its position, let's see what happens: > GetScreenXY sees +1030+10, but figures out that this pixel falls on > screen 1 this time, and in screen-relative coordinates this is +6+10. > It returns 1 (which we ignore right now) and the coordinates +6+10. > This is again added to screen_g.x,y for the same global +1030+10. Don't understand these two last paragraphs: if the app saves its position, how will you distinguish between a "legal" +1030 request, and a position on screen #1? Let's take the following example (a usual CRT screen as #0 and 1600SW as #1): +---+---+ |0: |1: | | 1280x1024| 1600x1024| | | | +---+---+ What "+1300+10" would mean: [EMAIL PROTECTED], or [EMAIL PROTECTED] Other similar pitfalls and ambiguities are definitely possible. Maybe I'm wrong, but I simply don't fully grok the logic of your patch (and I want to, since "making old apps behave correctly under Xinerama setup" is a very interesting and important topic). Anyway, cay you please play with GIMP (it does save the main window position and uses it on subsequent run)? BTW, Sidik, are you on the list or should i keep CC:ing to you? _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM2 Xinerama patches
Hello Dmitry - Thanks for taking a look at the patches. Comments on your comments are below . . . | |On Sun, 23 Sep 2001, Sidik Isani wrote: | |> Hello - |> |> I have a suggestion for Xinerama, but I don't know enough about |> automake to provide a patch: we could use "configure" options |> telling fvwm2 where to look for the library and include files. |> |> Also related to Xinerama, here are better versions of some patches |> I posted before (now everything properly goes through the FScreen |> layer to calculate Xinerama screen coordinates.) We're upgrading |> from isolated multi-head displays to Xinerama, and with the following |> patches, we were able to keep the same geometry resources we use on |> separate DISPLAY's (:0.0, :0.1, :0.2, :0.N) and translate them to |> '*wmscreen: N' resources. FVWM2 looks very stable so far on our |> Linux/Solaris/HP-UX mix. Thanks a lot to all who worked on this. |> |> XINERAMA PATCH 1: Adds a new function to FScreen to convert global coords. |> XINERAMA PATCH 2: Adds a check for a *wmscreen resource. |> XINERAMA PATCH 3: Uses function in PATCH 1 to make USPosition windows |> obey StartsOnScreen Style/*wmscreen resource. |> XINERAMA PATCH 4: Uses PATCH 1 to cause window positions displayed while |> moving a window to be screen-relative whenever possible. |> |> I might not be good to put any of this in the 2.4.3 release, but |> I hope it is useful to someone. #4 probably needs a config file |> option associated with it to turn it on/off. Adding "@N" to the |> string it displays would make it nicer too. |> |> Please let me know if there's anything else needed to make these |> patches generally useful. | | Just two notes. | | First, isn't FScreenGetScreenXY() just a | |FScreenGetScrRect(arg, FSCREEN_XYPOS, &dst_x, &dst_y, NULL, NULL) | |(well, a separate call may be more handy, but Dominik has removed most of |FScreenGetZZZScrRect() in favour of FScreenGetScrRect, an that looks |reasonable)? OK, I see now how it could be used to convert between coordinate systems. We'd still have to subtract (dst_x,dst_y) from the original coordinate, since GetScrRect returns the rectangle, not transformed coordinates. And we don't have a way to get the screen number. I guess another parameter could be added to GetScrRect, "int *screen", if you don't like the separate function for a coordinate transform? | Second, regarding translation of program-supplied geometry to |non-global screen: what will happen to those programs which save their |windows' geometries on exit and use them on restart? Wouldn't the They should work correctly. My first patch, with %'ing (which would have broken on unequal screen sizes) is no longer needed either. Here's why: Let's say an application is started with Xresource: foo.wmscreen: 1 Command: foo -geometry +6+10 and we're using your example screen layout: |+---+---+---+ 1024*3 || 0 | 1 | 2 | |+---+---+---+ The application doesn't even look at "wmscreen", but it requests a position of +6+10 on the global screen. GetScreenXY figures out that this pixel falls on screen 0 and returns screen-relative coordinates of +6+10. This is added to screen_g.x,y, the origin of screen 1 (because of the *wmscreen: 1) resulting in global +1030+10. The window pops up on screen 1 (no matter what the current screen is.) If the application saves this as its position, let's see what happens: GetScreenXY sees +1030+10, but figures out that this pixel falls on screen 1 this time, and in screen-relative coordinates this is +6+10. It returns 1 (which we ignore right now) and the coordinates +6+10. This is again added to screen_g.x,y for the same global +1030+10. Same logic works for "StartsOnScreen c", and also for foo -xrm '*wmscreen: 1' -geometry +6+10 with _no_ StartsOnScreen style or global Xresource. In this last case, the application saves its position as +1030+10, and since StartsOnScreen +1030+10 is interpreted relative to the global screen. As far as I can tell (and have tested), all cases work properly. Ok, well there is one small obscure "feature": - If you specify negative geometry instead of positive (i.e., to place a window some distance from the bottom and/or right screen edge) AND - If a StartsOnScreen Style is in effect for the window AND - The selected screen is a different size from the farthest screen then the window will pop up relative to the bottom/right of the screen you selected, but as if the selected screen was the size of the last screen. Basically, if someone has all three of these conditions, then use positive geometries! (And the application will never save its own geometry as negative, so that works too, since positive coordinates are not susceptible to this.) |[...] | Of course, a good program should specify PPosi
Re: FVWM2 Xinerama patches
On Sun, 23 Sep 2001, Sidik Isani wrote: > Hello - > > I have a suggestion for Xinerama, but I don't know enough about > automake to provide a patch: we could use "configure" options > telling fvwm2 where to look for the library and include files. > > Also related to Xinerama, here are better versions of some patches > I posted before (now everything properly goes through the FScreen > layer to calculate Xinerama screen coordinates.) We're upgrading > from isolated multi-head displays to Xinerama, and with the following > patches, we were able to keep the same geometry resources we use on > separate DISPLAY's (:0.0, :0.1, :0.2, :0.N) and translate them to > '*wmscreen: N' resources. FVWM2 looks very stable so far on our > Linux/Solaris/HP-UX mix. Thanks a lot to all who worked on this. > > XINERAMA PATCH 1: Adds a new function to FScreen to convert global coords. > XINERAMA PATCH 2: Adds a check for a *wmscreen resource. > XINERAMA PATCH 3: Uses function in PATCH 1 to make USPosition windows > obey StartsOnScreen Style/*wmscreen resource. > XINERAMA PATCH 4: Uses PATCH 1 to cause window positions displayed while > moving a window to be screen-relative whenever possible. > > I might not be good to put any of this in the 2.4.3 release, but > I hope it is useful to someone. #4 probably needs a config file > option associated with it to turn it on/off. Adding "@N" to the > string it displays would make it nicer too. > > Please let me know if there's anything else needed to make these > patches generally useful. Just two notes. First, isn't FScreenGetScreenXY() just a FScreenGetScrRect(arg, FSCREEN_XYPOS, &dst_x, &dst_y, NULL, NULL) (well, a separate call may be more handy, but Dominik has removed most of FScreenGetZZZScrRect() in favour of FScreenGetScrRect, an that looks reasonable)? Second, regarding translation of program-supplied geometry to non-global screen: what will happen to those programs which save their windows' geometries on exit and use them on restart? Wouldn't the following happen: app is started on current screen +---+---+---+ 1024*3 | 0 | 1 | 2 | +---+---+---+ (which is #1, +1024+0), it saves window position (e.g. +1030+10), and on next run (current screen is still #1) supplies it to fvwm, which translates to +(1030+1024)+10, so that the window effectively goes to screen #2? Patch #3 doesn't include %'ing the coords, which was present in previous version (yet not sure if that did the right thing). Of course, a good program should specify PPosition in this case, not USPosition, but a) I haven't tested what such apps supply (and those (mainly commercial or binary-only) progs are known to be bogus in many aspects); b) do patch #3 belongs to "PPosition" branch only? Hope this is a false alarm, but I think it is worth mentioning. (An obvious question is "why specifying StartsOnScreen for such programs?", but this feature is so handy that there's a desire to use "Style * StartsOnScreen c"). _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM2 Xinerama patches
Hello - I have a suggestion for Xinerama, but I don't know enough about automake to provide a patch: we could use "configure" options telling fvwm2 where to look for the library and include files. Also related to Xinerama, here are better versions of some patches I posted before (now everything properly goes through the FScreen layer to calculate Xinerama screen coordinates.) We're upgrading from isolated multi-head displays to Xinerama, and with the following patches, we were able to keep the same geometry resources we use on separate DISPLAY's (:0.0, :0.1, :0.2, :0.N) and translate them to '*wmscreen: N' resources. FVWM2 looks very stable so far on our Linux/Solaris/HP-UX mix. Thanks a lot to all who worked on this. XINERAMA PATCH 1: Adds a new function to FScreen to convert global coords. XINERAMA PATCH 2: Adds a check for a *wmscreen resource. XINERAMA PATCH 3: Uses function in PATCH 1 to make USPosition windows obey StartsOnScreen Style/*wmscreen resource. XINERAMA PATCH 4: Uses PATCH 1 to cause window positions displayed while moving a window to be screen-relative whenever possible. I might not be good to put any of this in the 2.4.3 release, but I hope it is useful to someone. #4 probably needs a config file option associated with it to turn it on/off. Adding "@N" to the string it displays would make it nicer too. Please let me know if there's anything else needed to make these patches generally useful. Be seeing you, - Sidik -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]