Java and fvwm
Hello - Turns out no patches were needed to get Java working reasonably well: I've found comments from others on the 'net claiming things like I went back and tried Java under MWM and it worked OK, but under FVWM I have problems with window size and positions. Don't let this fool you into thinking that MWM has work-arounds for Java bugs, or that FVWM broken. I think neither are the case, because Java's AWT is the one checking to see which window manager is running and it drops down to more standard behavior if it is MWM. So the fix for us is quite simple. We already run with Emulate MWM, but we need to emulate one more feature of MWM: _MOTIF_WM_INFO. Motif applications can also change their behavior when MWM is running, so this could affect them too, but things seem fine so far. We can't separate the two, because both check for _MOTIF_WM_INFO on the root window. The option Dan seems to have put in a while back, ModalityIsEvil, was the key to getting Java working better for us. All it does is cause FVWM to emulate MWM's _MOTIF_WM_INFO: BugOpts ModalityIsEvil 1 Style AWT* UsePPosition,UseTransientPPosition You might try with and without ``Style AWT* BackingStore'' too, since Java draws everything as pixmaps, which can be quite slow. Good luck, - Sidik P.S.: This is with Sun JDK 1.3.1 and fvwm 2.4.1 with some patches. -- 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]
Java's AWT misbehaves
Hello - Apparently Java's AWT widget stuff has a bad habit of taking over functions which are probably better left to the WM. For example, allegedly it wants a way to figure out the width of the border which the WM added around it :-( In 1999, the Enlightenment people had some discussion about this. It's gone from their news page, but google still has it cached: http://www.google.com/search?q=cache:MZArZ-4gVDU:www.deepsky.com/~e/news.html+AWT+window+position+resize+%22window+manager%22hl=en [search for AWT] and the mail thread which led me there: http://www.mail-archive.com/java-linux@java.blackdown.org/msg09689.html We run jdk-1.3.1. Windows pop up in the wrong places under FVWM1, but the sizes are correct. Under FVWM2, windows themselves, or sometimes the widgets within the windows, pop up as 0x0! Then when you try to resize the window, they flip back to the right size. Needless to say, this is pretty unusable for most people. I'm guessing Java is doing something non-standard, because FVWM2 has been working quite flawlessly with every other application. (Although, I did have a search string not found popup from netscape which also came up 0x0 size just once ... strange.) I've experimented with all of the *Transient options, BackingStore (which, by the way, causes the window to be blank most of the time!?), No/UsePPosition,No/UseTransientPPosition,No/UseUSPosition, No/UseTransientUSPosition, SkipMapping, etc. Nothing helps. Has anyone seen this before? Some kind of hack Style which we could apply to AWT* in our .fvwm2rc's as a work-around could be useful. Reportedly, CDE, KDE, and Enlightenment now work (but Sun supposedly put a special hack into Java just for Enlightenment). FVWM1 also kind of worked. Do they do anything fundamentally differently from FVWM2? If this is a new problem, can someone give me some advice on how to capture a log of what the misbehaving windows are trying to do? 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM2 Xinerama patches
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
Re: FVWM2 cleanup patch
Hello Dominik - Regarding the clean-up patch I posted: Given the way you illustrate going from one window manager to another (with the xinitrc), it's clear that you'd want it to be optional, or don't include it at all. Indeed you can do almost the same thing from the xinitrc, but it is considerably more complex that way ... |That patch may cause a lot of trouble if X does not exit when fvwm |does. For example, I often have these two lines near the end of my |.xinitrc: | | # start fvwm without any config file | fvwm2 -f /dev/null | # fall back to normal config file after exiting | fvwm2 Well, the behavior would be all processes launched by the first fvwm2 would be cleaned up before the second fvwm2 starts. Maybe not what you wanted, but note that things do work fine if fvwm2 is used to restart itself or another window manager instead. |Also, this fails miserably if you restart fvwm in the mean time |since the new fvwm process does not become the parent of the Actually it does work. When you restart, fvwm2 exec()'s itself or a new window manager. Either way, its PID stays the same and all windows launched since the beginning of the session remain child processes (which are reached by the kill(0, ...)). The whole concept isn't even that non-standard. If you launch a bunch of stuff from a terminal and then close that window, all the processes in the group see a SIGHUP too. (So it's not a wrong or bad way to shut down programs. They all expect it, or they will detach from the terminal so they won't see this signal.) The feature just brings that simple but effective concept for terminal sessions up to a window session. |windows. Neither does it help if windows are started from outside |of fvwm, e.g. from .xinitrc. Why don't you simply do this in The way our xinitrc's are set up, it does. The last thing xinitrc does is exec fvwm2. fvwm2 nicely inherits any clients already started by the xinitrc. |.xinitrc? For example, since netscape often hangs, I have | | killall -15 netscape That would kill a netscape I have running on another X-Terminal in another room. Not good. And some of our machines don't have killall. But even with grep/awk junk in our scripts, the list was getting rather long, and I was tired of seeing half logged out X-Terminals in our computer room. kill(0, SIGHUP) was a much easier fix. Hey, how about a simple exec fvwm2 -cleanup ... usage? That would make it obvious within the script where fvwm2 is invoked, and where it matters, what behavior required. Default behavior unchanged. Seem like a good idea? Be seeing you, - Sidik P.S.: We also use fvwm on some very tight, embedded systems where having the xinitrc be able to turn into the window manager with an exec is both clean and wise to conserve memory/resources. -- 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]
FVWM2 Xinerama patches
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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM2 Xinerama patch 1
diff -ru fvwm-snap-20010916/libs/FScreen.c fvwm-2.5.0-cfht/libs/FScreen.c
--- fvwm-snap-20010916/libs/FScreen.c Sat Sep 15 01:00:05 2001
+++ fvwm-2.5.0-cfht/libs/FScreen.c Tue Sep 18 20:41:10 2001
@@ -528,6 +528,27 @@
return 0;
}
+/* Returns the screen of which (global_x, global_y) is a pixel, and
+ * returns the screen-relative (x,y) if x and y are not NULL.
+ */
+int FScreenGetScreenXY(
+ int global_x, int global_y, int *x, int *y)
+{
+ int screen = FindScreenOfXY(global_x, global_y);
+
+ if (screen == 0)
+ {
+if (x) *x = global_x;
+if (y) *y = global_y;
+ }
+ else if (screen 0)
+ {
+if (x) *x = global_x - screens[screen].x_org;
+if (y) *y = global_y - screens[screen].y_org;
+ }
+ return screen;
+}
+
/* Returns the specified screens geometry rectangle. screen can be a screen
* number or any of the values FSCREEN_GLOBAL, FSCREEN_CURRENT,
* FSCREEN_PRIMARY or FSCREEN_XYPOS. The arg union only has a meaning for
diff -ru fvwm-snap-20010916/libs/FScreen.h fvwm-2.5.0-cfht/libs/FScreen.h
--- fvwm-snap-20010916/libs/FScreen.h Fri Sep 14 01:00:08 2001
+++ fvwm-2.5.0-cfht/libs/FScreen.h Tue Sep 18 20:20:24 2001
@@ -44,6 +44,8 @@
void FScreenSetPrimaryScreen(int scr);
/* Screen info */
+int FScreenGetScreenXY(
+ int global_x, int global_y, int *x, int *y);
Bool FScreenGetScrRect(
fscreen_scr_arg *arg, int screen, int *x, int *y, int *w, int *h);
void FScreenGetResistanceRect(
--
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]
FVWM2 Xinerama patch 2
diff -ru fvwm-snap-20010916/fvwm/fvwm2.1 fvwm-2.5.0-cfht/fvwm/fvwm2.1
--- fvwm-snap-20010916/fvwm/fvwm2.1 Sun Sep 16 01:00:02 2001
+++ fvwm-2.5.0-cfht/fvwm/fvwm2.1Sat 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-snap-20010916/fvwm/add_window.c fvwm-2.5.0-cfht/fvwm/add_window.c
--- fvwm-snap-20010916/fvwm/add_window.cSun Sep 16 01:00:02 2001
+++ fvwm-2.5.0-cfht/fvwm/add_window.c Sat Sep 15 20:38:13 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)
--
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]
FVWM2 Xinerama patch 3
diff -ru fvwm-snap-20010916/fvwm/placement.c fvwm-2.5.0-cfht/fvwm/placement.c
--- fvwm-snap-20010916/fvwm/placement.c Fri Sep 7 04:37:27 2001
+++ fvwm-2.5.0-cfht/fvwm/placement.cTue Sep 18 20:27:14 2001
@@ -922,6 +922,31 @@
/* 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)
+{
+ int global_x = tmp_win-attr.x;
+ int global_y = tmp_win-attr.y;
+
+ /*
+ * 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.
+ */
+ FScreenGetScreenXY(global_x, global_y,
+tmp_win-attr.x, tmp_win-attr.y);
+
+ tmp_win-attr.x += screen_g.x; /* Back to global coordinates, but */
+ tmp_win-attr.y += screen_g.y; /* forced to the right screen now. */
+}
+
/*
* If SkipMapping, and other legalities are observed, adjust for
* StartsOnPage.
--
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]
FVWM2 Xinerama patch 4
diff -ru fvwm-snap-20010916/fvwm/move_resize.c
fvwm-2.5.0-cfht/fvwm/move_resize.c
--- fvwm-snap-20010916/fvwm/move_resize.c Fri Sep 7 04:37:27 2001
+++ fvwm-2.5.0-cfht/fvwm/move_resize.c Tue Sep 18 20:27:18 2001
@@ -457,11 +457,17 @@
{
char str [100];
int offset;
+ int screen_x, screen_y;
+ /*
+ * Translate x,y into local screen coordinates, in case Xinerama is used.
+ */
+ FScreenGetScreenXY(x, y, screen_x, screen_y);
+
if (Scr.gs.do_hide_position_window)
return;
position_geometry_window(eventp);
- (void) sprintf (str, GEOMETRY_WINDOW_POS_STRING, x, y);
+ (void) sprintf (str, GEOMETRY_WINDOW_POS_STRING, screen_x, screen_y);
if (Init)
{
XClearWindow(dpy, Scr.SizeWindow);
--
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]
FVWM2 cleanup patch
We've been using the fvwm-1.24r for years with the following patch to prevent clean-up problems when users log out. The problem was sometimes users start things from their window manager menus which are not intended to be daemons, but also do not launch any windows, or the windows do not respond to the right signals to clean up when fvwm2 exits. At the very least, we frequently were left with bogus processes still running, and in the worst cases, the X greeter would not restart. Maybe someone else understands this better, but simply having the window manager try to clean up all its child processes when it exits (not restarts) has worked quite well: diff -ru fvwm-snap-20010916/fvwm/fvwm.c fvwm-2.5.0-cfht/fvwm/fvwm.c --- fvwm-snap-20010916/fvwm/fvwm.c Fri Sep 14 01:00:07 2001 +++ fvwm-2.5.0-cfht/fvwm/fvwm.c Tue Sep 18 19:55:12 2001 @@ -1675,6 +1675,17 @@ */ ClosePipes(); + /* Any processes which FVWM started should also exit now, if they are + * still running in the same process group. Any program that wants to + * continue running after the user's window manager session is gone + * should create its own process group. + */ + signal(SIGHUP, SIG_IGN); + signal(SIGTERM, SIG_IGN); + kill(0, SIGHUP); + sleep(4); + kill(0, SIGTERM); + exit(0); } -- 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]
a little CVS help
Hi folks - What's the CVS checkout tag we are using for the 2.4.x releases? 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]
StartsOnPage / X-resources
Hello - The section in the fvwm2 manpage which talks about: [ . . . ] your .Xdefaults file: XTerm*Desk: 1 or XTerm*Page: 3 2 1 Doesn't seem to work for me. If there is a way to fix this, can we add an equivalent way to do StartsOnScreen from .Xdefaults also? If not, how difficult would a StartsAtPosition (or StartsAtGeometry) Style be to implement? (Which would imply NoUSPosition and NoPPosition.) The problem is I'd like to have _one_ config file where I control which screen, and where on that screen all windows pop up. Right now I can only control the screen from .fvwm2rc with StartsOnScreen N, and I can only control the position with Xresources... Any advice? Thanks for you help, - 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]
FvwmM4 -m4-prefix-defines
Hello -
We need this at our site: If you run FvwmM4 on unsuspecting
users, FvwmM4 -m4-prefix prevents problems with include, but
there are still problems with $HOME in an exec becoming $/home/user.
With the following patch, no default behavior is changed, but
if FvwmM4 is also started with -m4-prefix-defines, all of the
built-in defines that *it* provides will start with m4_.
(So both $HOME and m4_HOME can be used.)
This makes FvwmM4 completely transparent to the non-m4 user,
as long as they don't have any strings starting with m4_ in
their fvwm2rc.
Be seeing you,
- Sidik
P.S.: Thanks for adding the new XineramaSls syntax. I'll test it on
a real SLS display next week. (It needs the fix posted by Giuseppe
with screens_xi.)
diff -ru fvwm/modules/FvwmM4/FvwmM4.1 fvwm-patched/modules/FvwmM4/FvwmM4.1
--- fvwm/modules/FvwmM4/FvwmM4.1Mon Jul 2 21:23:07 2001
+++ fvwm-patched/modules/FvwmM4/FvwmM4.1Thu Sep 6 22:38:57 2001
@@ -46,6 +46,10 @@
.IP -m4-prefix
I think this makes all the m4 directives require the prefix m4_.
+.IP -m4-prefix-defines
+Causes built-in defines to be prefixed with m4_ (i.e., m4_HOME
+is defined instead of HOME, etc.)
+
.TP
-m4opt \fIoption\fP
Lets you pass an option to the m4 program. Not really needed as any
diff -ru fvwm/modules/FvwmM4/FvwmM4.c fvwm-patched/modules/FvwmM4/FvwmM4.c
--- fvwm/modules/FvwmM4/FvwmM4.cSat Feb 10 06:56:33 2001
+++ fvwm-patched/modules/FvwmM4/FvwmM4.cThu Sep 6 22:43:26 2001
@@ -63,10 +63,11 @@
static char *MkNum(char *name,int def);
static char *m4_defs(Display *display, const char *host, char *m4_options,
char *config_file);
#define MAXHOSTNAME 255
-#define EXTRA 50
+#define EXTRA 56
int m4_enable; /* use m4? */
int m4_prefix; /* Do GNU m4 prefixing (-P) */
+int m4_prefix_defines;/* Add m4_ to the names of the
defines */
char m4_options[BUFSIZ];/* Command line options to m4 */
char m4_outfile[BUFSIZ] = ; /* The output filename for m4 */
char *m4_prog = m4; /* Name of the m4 program */
@@ -105,6 +106,7 @@
m4_enable = True;
m4_prefix = False;
+ m4_prefix_defines = False;
sprintf(m4_options, -I '%s' , FVWM_DATADIR);
m4_default_quotes = 1;
@@ -138,6 +140,10 @@
{
m4_prefix = TRUE;
}
+ else if(strcasecmp(argv[i],-m4-prefix-defines) == 0)
+ {
+ m4_prefix_defines = TRUE;
+ }
else if(strcasecmp(argv[i],-m4opt) == 0)
{
/* leaving this in just in case-- any option starting with '-'
@@ -505,6 +511,8 @@
else
strcpy(cp, define();
+ if (m4_prefix_defines)
+strcat(cp, m4_);
strcat(cp, name);
/* Tack on , and 2 sets of starting quotes */
--
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]
FVWM single-logical-screen patch
Hello FVWM workers -
I've just generated a small patch against fvwm-snap-20010831
to allow Xinerama behavior to be emulated correctly on our
HP SLS (Single Logical Screen) configurations. What I added
was a way to tell FVWM where the divisions between the monitors
are for cases where there is no Xinerama extension to query.
It is like a fvwm2rc-configurable version of XINERAMA_EMULATION,
(but I don't draw the white lines, and all monitors must be the
same resolution.) I also moved the generation of the FScreen
configuration command for modules into FScreen.c so it is near
the point where it is also decoded.
I should probably test the patch some more, but I'd like to
get your thoughts on the way I did it to see if you agree, or
would rather have it implemented another way. The man page
has been updated to show how two more (optional) parameters
can be added to the Xinerama line to specify how many equal-sized
monitors widehigh the screen which FVWM sees is composed of.
You can test it on a regular screen.
This patch shouldn't break anything since it just adds optional
parameters to the Xinerama command. Please let me know what you
think of it, and thanks for your time!
Be seeing you,
- Sidik
P.S.: Dominik, the previous file I sent you was gzipped. Maybe
something remove the .gz? The final size is 7574 bytes, and
I put a copy at:
http://software.cfht.hawaii.edu/fvwm2-xinerama-sls.patch
and here it is in plain text, since the Welcome message says
patches are appropriate...
diff -ru fvwm-snap-20010831/fvwm/fvwm2.1 fvwm-snap-20010831-sls/fvwm/fvwm2.1
--- fvwm-snap-20010831/fvwm/fvwm2.1 Tue Aug 21 01:30:03 2001
+++ fvwm-snap-20010831-sls/fvwm/fvwm2.1 Mon Sep 3 15:51:13 2001
@@ -6520,7 +6520,7 @@
then the scroll amount is measured in pixels.
.TP
-.BI Xinerama [ bool | primary-screen ]
+.BI Xinerama [ bool | primary-screen [ wide high ] ]
Enables Xinerama support if the boolean argument is true and
disables it if the argument is false. If instead an integer
argument is given as
@@ -6531,6 +6531,23 @@
as the primary screen's number. Any negative value disables the
primary screen feature. Calling this command without arguments
turns on Xinerama support with the primary screen 0 if it was disabled before
and turns it off if it was enabled.
+
+For multi-screen implementations other than Xinerama, such as
+Single Logical Screen, it is possible to simulate a Xinerama
+configuration if the total screen seen by FVWM is made up of
+equal sized monitors in a rectangular grid. Add two more arguments,
+.IR wide ,
+which must be an integer value dividing evenly into the
+total desktop width, and
+.IR high ,
+which must be an integer value dividing evenly into the
+total desktop height. For an example with two monitors side-by-side
+which appear as one screen through the X-Server, use:
+.EX
+Xinerama 1 2 1
+.EE
+to simulate Xinerama with screen 1 as the primary. These extra
+parameters should not be added if the X-Server supports Xinerama.
.SS COMMANDS FOR USER FUNCTIONS AND SHELL COMMANDS
diff -ru fvwm-snap-20010831/fvwm/modconf.c fvwm-snap-20010831-sls/fvwm/modconf.c
--- fvwm-snap-20010831/fvwm/modconf.c Mon Aug 27 01:30:02 2001
+++ fvwm-snap-20010831-sls/fvwm/modconf.c Mon Sep 3 12:41:08 2001
@@ -220,13 +220,7 @@
static void send_xinerama_state(int modnum)
{
- char msg[100];
- int scr;
-
- scr = (FScreenIsEnabled()) ? FScreenGetPrimaryScreen() : -1;
- sprintf(msg, %s %d, XINERAMA_CONFIG_STRING, scr);
- SendName(modnum, M_CONFIG_INFO, 0, 0, 0, msg);
-
+ SendName(modnum, M_CONFIG_INFO, 0, 0, 0, FScreenGetConfiguration());
return;
}
diff -ru fvwm-snap-20010831/fvwm/module_interface.c
fvwm-snap-20010831-sls/fvwm/module_interface.c
--- fvwm-snap-20010831/fvwm/module_interface.c Mon Aug 27 01:30:02 2001
+++ fvwm-snap-20010831-sls/fvwm/module_interface.c Mon Sep 3 12:41:55 2001
@@ -1225,13 +1225,7 @@
**/
void broadcast_xinerama_state(void)
{
- char buf[100];
- int scr;
-
- scr = (FScreenIsEnabled()) ? FScreenGetPrimaryScreen() : -1;
- sprintf(buf, %s %d, XINERAMA_CONFIG_STRING, scr);
- BroadcastConfigInfoString(buf);
-
+ BroadcastConfigInfoString(FScreenGetConfiguration());
return;
}
diff -ru fvwm-snap-20010831/fvwm/virtual.c fvwm-snap-20010831-sls/fvwm/virtual.c
--- fvwm-snap-20010831/fvwm/virtual.c Mon Aug 27 01:30:03 2001
+++ fvwm-snap-20010831-sls/fvwm/virtual.c Mon Sep 3 15:19:53 2001
@@ -337,15 +337,17 @@
void CMD_Xinerama(F_CMD_ARGS)
{
- int val;
+ int n, val[3];
int toggle;
Scr.flags.do_need_window_update = True;
Scr.flags.has_xinerama_state_changed = True;
- if (GetIntegerArguments(action, NULL, val, 1) == 1)
+ if ((n = GetIntegerArguments(action, NULL, val, 3)) = 1)
{
+if (n = 3)
+ FScreenSingleLogicalScreen(val[1], val[2]);
+
