Hello -
Excellent! The resources are working. But I discovered a few
problems with the way Xinerama window placement was being handled.
A little explanation for the patch below, which address the problem:
o Adds the corresponding Xresource for StartsOnScreen. Let me
know if you have a better name than *wmscreen. (The name
*screen causes problems with xterm.)
o Allows user to select interpretation of USPosition's, rather than
always placing relative to the global screen. (And without
breaking or changing the default behavior, but please double
check my logic.) Geometries with negative numbers work correctly too.
o Updates fvwm2.1 man page. See the explanation near:
``However, those windows which are not placed by FVWM ... ''
and removes a repeated section about StartsOnPage, which was
in there twice twice.
o The very last part of the patch slightly simplifies some of
the calculations for StartsOnPage. It is not essential,
and unrelated to the rest.
Any idea if this, and Dominik's fixed Xresource stuff can make
it into the 2.4.1 tree?
Thanks for the great stuff,
- Sidik
diff -ru fvwm/fvwm/add_window.c fvwm-patched/fvwm/add_window.c
--- fvwm/fvwm/add_window.c Sat Sep 15 13:55:50 2001
+++ fvwm-patched/fvwm/add_window.c Sat Sep 15 14:43:01 2001
@@ -56,6 +56,7 @@
#include <stdio.h>
#include "libs/fvwmlib.h"
+#include "libs/FScreen.h"
#include "fvwm.h"
#include "externs.h"
#include "cursor.h"
@@ -587,6 +588,12 @@
SSET_START_DESK(*pstyle, SGET_START_DESK(*pstyle) + 1);
}
pstyle->flags.use_start_on_desk = 1;
+ }
+ if (GetResourceString(db, "wmscreen", client_argv[0], &rm_value) &&
+ rm_value.size != 0)
+ {
+ SSET_START_SCREEN(*pstyle, FScreenGetScreenArgument(rm_value.addr, 'c'));
+ pstyle->flags.use_start_on_screen = 1;
}
if (GetResourceString(db, "page", client_argv[0], &rm_value) &&
rm_value.size != 0)
diff -ru fvwm/fvwm/fvwm2.1 fvwm-patched/fvwm/fvwm2.1
--- fvwm/fvwm/fvwm2.1 Sat Sep 15 13:55:50 2001
+++ fvwm-patched/fvwm/fvwm2.1 Sat Sep 15 16:54:45 2001
@@ -5239,7 +5239,7 @@
.IR StartsOnDesk .
For those standard Xt programs which understand this usage, the
starting desk/page can also be specified via a resource (e.g.,
-"-xrm 'Fvwm.Page: 1 0 2'").
+"-xrm '*Page: 1 0 2'").
.I StartsOnPage
in conjunction with
.I SkipMapping
@@ -5254,19 +5254,23 @@
A new window is placed on the specified Xinerama screen. The
default is to place windows on the screen that contains the mouse
pointer at the time the window is created.
-
-.I StartsOnPage
-functions exactly like
-.IR StartsOnDesk .
+However, those windows which are not placed by FVWM (i.e., those with
+a USPosition hint from a user specified geometry) are normally placed
+in a position relative to the global screen. The
+.I StartsOnScreen
+style is also useful to cause these windows to be placed relative
+to a specific Xinerama screen. For example:
+.EX
+Style * StartsOnScreen c
+.EE
+Would cause all windows, including those with their own geometry
+to be placed relative to the current Xinerama screen rather than
+the global screen.
For those standard Xt programs which understand this usage, the
starting desk/page can also be specified via a resource (e.g.,
-"-xrm 'Fvwm.Page: 1 0 2'").
-.I StartsOnPage
-in conjunction with
-.I SkipMapping
-is a useful technique when you want to start an app on some other
-page and continue with what you were doing, rather than waiting
-for it to appear.
+"-xrm '*Wmscreen: c'"). ('Wmscreen' was chosen
+because some applications already use '.screen' for other
+purposes.)
.I StartsOnPageIncludesTransients
causes the
diff -ru fvwm/fvwm/placement.c fvwm-patched/fvwm/placement.c
--- fvwm/fvwm/placement.c Tue Sep 4 05:20:33 2001
+++ fvwm-patched/fvwm/placement.c Sat Sep 15 16:58:06 2001
@@ -922,6 +922,27 @@
/* the USPosition was specified, or the window is a transient,
* or it starts iconic so place it automatically */
+ if (SUSE_START_ON_SCREEN(sflags) && flags.do_honor_starts_on_screen)
+ {
+ /*
+ * If StartsOnScreen has been given for a window, translate its
+ * USPosition so that it is relative to that particular screen.
+ * If we don't do this, then a geometry would completely cancel
+ * the effect of the StartsOnScreen style.
+ *
+ * So there are two ways to get a window to pop up on a particular
+ * Xinerama screen. 1: The intuitive way giving a geometry hint
+ * relative to the desired screen's 0,0 along with the appropriate
+ * StartsOnScreen style (or *wmscreen resource), or 2: Do NOT
+ * specify a Xinerama screen (or specify it to be 'g') and give
+ * the geometry hint in terms of the global screen.
+ */
+ tmp_win->attr.x %= screen_g.width;
+ tmp_win->attr.y %= screen_g.height;
+ tmp_win->attr.x += screen_g.x;
+ tmp_win->attr.y += screen_g.y;
+ }
+
/*
* If SkipMapping, and other legalities are observed, adjust for
* StartsOnPage.
@@ -951,30 +972,17 @@
* were only one page, no virtual desktop), then 2) readjust
* relative to the current page.
*/
- if (tmp_win->attr.x < 0)
- {
- tmp_win->attr.x =
- ((Scr.MyDisplayWidth + tmp_win->attr.x) % Scr.MyDisplayWidth);
- }
- else
- {
- tmp_win->attr.x = tmp_win->attr.x % Scr.MyDisplayWidth;
- }
+ tmp_win->attr.x =
+ ((Scr.MyDisplayWidth + tmp_win->attr.x) % Scr.MyDisplayWidth);
/*
* Noticed a quirk here. With some apps (e.g., xman), we find the
* placement has moved 1 pixel away from where we originally put it when
* we come through here. Why is this happening?
* Probably old_bw, try xclock -borderwidth 100
*/
- if (tmp_win->attr.y < 0)
- {
- tmp_win->attr.y =
- ((Scr.MyDisplayHeight + tmp_win->attr.y) % Scr.MyDisplayHeight);
- }
- else
- {
- tmp_win->attr.y = tmp_win->attr.y % Scr.MyDisplayHeight;
- }
+ tmp_win->attr.y =
+ ((Scr.MyDisplayHeight + tmp_win->attr.y) % Scr.MyDisplayHeight);
+
tmp_win->attr.x -= pdeltax;
tmp_win->attr.y -= pdeltay;
}
--
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]
