Re: FVWM2 Xinerama patches

2001-10-02 Thread Dmitry Yu. Bolkhovityanov
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

2001-09-24 Thread Sidik Isani
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

2001-09-24 Thread Dmitry Yu. Bolkhovityanov
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

2001-09-23 Thread Sidik Isani
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]