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 <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]
