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
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
