Re: FVWM2 Xinerama patches
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]
Re: FvwmButtons core dump
On Fri, Sep 21, 2001 at 01:46:28PM +0200, Olivier Chapuis wrote: On Thu, Aug 16, 2001 at 10:40:46AM +0200, Dominik Vogt wrote: On Wed, Aug 15, 2001 at 08:06:42AM +0200, Olivier Chapuis wrote: I get a FvwmButtons core dump when I change colorsets and the buttons contains swallowed shaped app. ... Thiss core dump isn't very helpful. Obviously an X error occured that was not handled and then the routine that should generate the core dump crashed (probably by accessing an array index of (unsigned char)-1 ). T'll submit a fix for the crash in XError.c. Please try to make that happen again then. Also, I tried to reproduce this, but could not. If the problem does not become obvious with a proper core dump, can you please provide more information on the bug? The fix is obvious: I've added BadPixmap as an acceptable errors in myErrorHandler ... I don't think the fix is obvious. The PrintXError... routine was called with nonsense parameters and crashed. Simply not calling it does not fix the underlying problem. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- 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 cleanup patch
On Sun, Sep 23, 2001 at 03:41:35PM -1000, Sidik Isani wrote: 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.cFri 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); } 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 Also, this fails miserably if you restart fvwm in the mean time since the new fvwm process does not become the parent of the 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 .xinitrc? For example, since netscape often hangs, I have killall -15 netscape as the last line. I'd only do this for applications that tend to hang, not Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- 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: FvwmButtons core dump
On Mon, Sep 24, 2001 at 10:59:38AM +0200, Dominik Vogt wrote: On Fri, Sep 21, 2001 at 01:46:28PM +0200, Olivier Chapuis wrote: On Thu, Aug 16, 2001 at 10:40:46AM +0200, Dominik Vogt wrote: On Wed, Aug 15, 2001 at 08:06:42AM +0200, Olivier Chapuis wrote: I get a FvwmButtons core dump when I change colorsets and the buttons contains swallowed shaped app. ... Thiss core dump isn't very helpful. Obviously an X error occured that was not handled and then the routine that should generate the core dump crashed (probably by accessing an array index of (unsigned char)-1 ). T'll submit a fix for the crash in XError.c. Please try to make that happen again then. Also, I tried to reproduce this, but could not. If the problem does not become obvious with a proper core dump, can you please provide more information on the bug? The fix is obvious: I've added BadPixmap as an acceptable errors in myErrorHandler ... I don't think the fix is obvious. The PrintXError... routine was called with nonsense parameters and crashed. Simply not calling it does not fix the underlying problem. I say it is obvious because I just have to add one line and this line can be found in some modules: [EMAIL PROTECTED] modules]$ grep -r BadPixmap * |grep ^Fvwm FvwmButtons/FvwmButtons.c: || (event-error_code == BadPixmap)) FvwmIconBox/FvwmIconBox.c: if (event-error_code == BadPixmap) FvwmIconMan/x.c: case BadPixmap: FvwmIconMan/x.c~: case BadPixmap: FvwmScript/FvwmScript.c: if((event-error_code == BadDrawable) || (event-error_code == BadPixmap) || FvwmScript/FvwmScript.c~: if((event-error_code == BadDrawable) || (event-error_code == BadPixmap) || FvwmTaskBar/FvwmTaskBar.c: if (event-error_code == BadPixmap) FvwmWinList/FvwmWinList.c: if (event-error_code == BadPixmap) however one may found a better fix (I've gotten the same core and ErrorHandler message after your handler fix). Maybe the swallowed app which cause the problem (a Window Maker applet) do something irregular or nonstandard. Olivier -- 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 in
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]
