Subject: FVWM2 Xinerama patches

From: Sidik Isani <[email-masked]>
Date: Sun, 23 Sep 2001 15:38:27 -1000 (HST)

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 <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: "Dmitry Yu. Bolkhovityanov" <[email-masked]>
Date: Mon, 24 Sep 2001 14:21:13 +0700

>   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-masked]
	  The Budker Institute of Nuclear Physics

---

From: Sidik Isani <[email-masked]>
Date: Mon, 24 Sep 2001 13:35:58 -1000 (HST)

Hello Dmitry -

  Thanks for taking a look at the patches.  Comments on your comments
  are below . . .

<Dmitry Yu. Bolkhovityanov wrote:>
|
|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 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?

  Since the patch is in PlaceWindow, I think it works for both
  USPosition and PPosition, if it enabled.  And definitely, there
  is no change in fvwm's placement behavior at all, if there are
  no StartsOnScreen styles in effect.  I wanted to be sure of that.

|(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").

  With "Style * StartsOnScreen c", the transition from multi-head
  to Xinerama has been quite painless.  Without my patch, the
  style command basically has no effect.  I just figured if you
  had the style it should do _something_, even to USPosition windows.

Thanks,

- Sidik