duplicate geometry handling
I was using the fvwm distributed in the Debian Testing distribution (based
on 2.2.5), and I noticed that if the configuration had two
*FwwmPagerGeometry settings (eg, one in the system config file, one in the
user config file), they would interfere with each other. For example, the
default /etc/X11/fvwm/system.fvwm2rc has
*FvwmPagerGeometry -0-0
and my own ~/.fvwm/post.hook (part of Debian's config setup) has
*FvwmPagerGeometry -0+0
but the result is that the pager appears in the lower-right corner, instead
of the upper-right.
The reason is that the config reader in FvwmPager.c updates the parts of the
geometry independently, based on what was specified in the geometry string.
So my geometry string doesn't override the fact that YNegative was already
set by the system geometry string.
I downloaded 2.4.4 and found that it had been fixed in the obvious way, by
resetting all components of the geometry every time a new geometry setting
is encountered. But I poked around a little more and discovered that
several other files have the same bug. Below is a patch that corrects every
instance I found (by grepping for ParseGeometry in **/*.c) in a recent
snapshot. I tried to address only the cases where the geometry might
plausibly be specified more than once.
I compiled this but did not run it. This is the first time I've looked at
the fvwm sources, so please take only what makes sense.
Making these changes was a pain, because I had to hunt down the default
values of all the geometry parts and duplicate them (which sucks for future
maintenance). I note that some modules (such as FvwmTaskBar) do something
much simpler and saner: they store only the geometry string when reading the
config, and parse it (ie, the last one read) after the whole config is read.
This is a better solution if someone feels like doing it.
I'm not subscribed, so please Cc: me on any follow-ups.
Andrew
diff -uNr fvwm-snap-20011228.orig/modules/FvwmButtons/parse.c
fvwm-snap-20011228/modules/FvwmButtons/parse.c
--- fvwm-snap-20011228.orig/modules/FvwmButtons/parse.c Mon Aug 27 07:30:03 2001
+++ fvwm-snap-20011228/modules/FvwmButtons/parse.c Sun Jan 6 18:38:22 2002
@@ -1325,6 +1325,8 @@
break;
UberButton->w = 0;
UberButton->h = 0;
+ UberButton->x = 0;
+ UberButton->y = 0;
if (flags&WidthValue)
button_width = width;
if (flags&HeightValue)
@@ -1636,6 +1638,8 @@
flags = FScreenParseGeometry(geom,&g_x,&g_y,&width,&height);
UberButton->w = 0;
UberButton->h = 0;
+ UberButton->x = 0;
+ UberButton->y = 0;
if (flags&WidthValue)
w = width;
if (flags&HeightValue)
diff -uNr fvwm-snap-20011228.orig/modules/FvwmDragWell/fvwmDragWell.c
fvwm-snap-20011228/modules/FvwmDragWell/fvwmDragWell.c
--- fvwm-snap-20011228.orig/modules/FvwmDragWell/fvwmDragWell.c Mon Sep 17
07:00:08 2001
+++ fvwm-snap-20011228/modules/FvwmDragWell/fvwmDragWell.c Sun Jan 6
17:38:43 2002
@@ -610,6 +610,13 @@
} else if (StrEquals(resource, "Geometry")) {
int g_x,g_y,flags;
unsigned width,height;
+ xg.w = 48;
+ xg.h = 48;
+ xg.x = 0;
+ xg.y = 0;
+ xg.xneg = 0;
+ xg.yneg = 0;
+ xg.usposition = 0;
flags = FScreenParseGeometry(arg1,&g_x,&g_y,&width,&height);
if (flags & WidthValue) {
xg.w = width;
@@ -634,6 +641,10 @@
} else if (StrEquals(resource, "DragWellGeometry")) {
int g_x,g_y,flags;
unsigned width,height;
+ xg.dbw = 30;
+ xg.dbh = 30;
+ xg.dbx = 9;
+ xg.dby = 9;
flags = FScreenParseGeometry(arg1,&g_x,&g_y,&width,&height);
if (flags & WidthValue) {
xg.dbw = width;
diff -uNr fvwm-snap-20011228.orig/modules/FvwmForm/FvwmForm.c
fvwm-snap-20011228/modules/FvwmForm/FvwmForm.c
--- fvwm-snap-20011228.orig/modules/FvwmForm/FvwmForm.c Mon Oct 15 07:00:05 2001
+++ fvwm-snap-20011228/modules/FvwmForm/FvwmForm.c Sun Jan 6 17:38:51 2002
@@ -432,6 +432,10 @@
int y = 0;
int flags;
unsigned int dummy;
+ CF.gx = 0;
+ CF.gy = 0;
+ CF.xneg = 0;
+ CF.yneg = 0;
while (isspace(*cp))
cp++;
diff -uNr fvwm-snap-20011228.orig/modules/FvwmIconBox/FvwmIconBox.c
fvwm-snap-20011228/modules/FvwmIconBox/FvwmIconBox.c
--- fvwm-snap-20011228.orig/modules/FvwmIconBox/FvwmIconBox.c Thu Dec 6
07:30:03 2001
+++ fvwm-snap-20011228/modules/FvwmIconBox/FvwmIconBox.cSun Jan 6
17:39:06 2002
@@ -1651,6 +1651,12 @@
{
if (strncasecmp(tline,CatString3("*", MyName, "Geometry"),Clength+9)==0)
{
+ num_columns = 6;
+ num_rows = 1;
+ geom_x = -1;
+ geom_y = -1;
+ xneg = 0;
+ yneg = 0;
tmp = &tline[Clength+9];
while(((isspace((unsigned char)*tmp))&&(*tmp != '\n'))&&(*tmp != 0))
tmp++;
diff -uNr fvwm-snap-20011228.orig/modules/FvwmWharf/FvwmWharf.c
fvwm-snap-20011228/modules/FvwmWharf/FvwmWharf.c
--- fvwm-snap-20011228.orig/modules/FvwmWharf/FvwmWharf.c Mo
Re: Notification: incoming/837
On Sun, 2002-01-06 at 02:14, Dominik Vogt wrote: > On Sat, Jan 05, 2002 at 03:50:28AM -0600, fvwm-bug wrote: > > FVWM Bug Tracking notification > > > > new message incoming/837 > > > > Version: all newer than fvwm2-2.2.4-9 > > CVS_Date: > > OS: redhat 7.x > > X_Server: 4.0.3 > > Submission from: (NULL) (147.229.25.195) > > > > > > Hello, > > > > I am still using fvwm2-2.2.4-9 because newer versions have a bug. > > I use two different keyboard layouts (Czech and US) and I toggle > > between them by pressing left and right shift simultaneously. > > I found this problem: > > Is this problem in 2.2.4 or in 2.4.x? If it is only in 2.2.4, > please tell the bug that you mentioned above. If it is in 2.4.x, > please provide the scripts and the keymaps you are using so that > I can try this myself. > I tried there versions: fvwm2-2.2.5-4 ... OK fvwm2-2.2.4-9 ... OK fvwm-2.4.0... bug fvwm-2.4.3... bug fvwm-2.4.4... bug As for the X server, I also tried XFree86-4.1.0-3 but with the same result. :-( > > 1) I open an xterm (or rxvt) > > 2) I exit the xterm > > > 3) when the Czech keyboard layout is active, fvwm ignores all > >key presses. > > What does this mean? Do other windows still get input or is the > keyboard completely frozen? If only fvwm specific keystrokes do > not work anymore, please check if Q 5.5 from our FAQ helps > solving the problem. > I don't know how to find where the the keystrokes get lost. But now I found something that could help to localize the problem: If I exit ANY application, the resulting state is that no window has focus. When no window has focus, the problem occurs. But on the other hand I do not know if windows get input - because no window has focus :-( I wrote you that after exiting rxvt (xterm) the problem occurs - it is not correct. It happens, when no window has focus. Toggling keyboard to US and back to Czech does not help! Sorry for confusing, I made mistake. So I will try to define the problem once more: ___ || When no window has focus, the keyboard layout must be US. || --- As for the FAQ 5.5 - I don't understand that :-( I tried to to turn off "ClickToFocus" but the result is the same. This is the output of xmodmap on my X server: 21:05:22 ~$ xmodmap xmodmap: up to 2 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1Alt_L (0x40) mod2 mod3Mode_switch (0x71) mod4 mod5 I use a non-standard keyboard layout - my friend Yeti has made a rpm package so I send that as an attachment. But I don't think it is the source of problem. Please tell me, what more diagnostics should I do. > -- > 5.5 Why do NumLock, CapsLock and ScrollLock interfere with > ClickToFocus and/or my mouse bindings? > > A: Because they are treated as modifiers. You can use the >IgnoreModifiers command to turn individual modifiers off for >bindings. With XFree86 the right command is > > IgnoreModifiers L25 > >If you changed your modifiers manually or are using a different >X server use the 'xmodmap' command to find out which modifiers >correspond to the keys you want to switch off. > >This command creates a lot of extra network traffic, depending >on your CPU, network connection, the number of Key Mouse commands >in your configuration file and the number of modifiers you want to >ignore. If you do not have a lightning fast machine or very few >bindings you should not ignore more than two modifiers. So do >not ignore scroll-lock if you have no problem with it. > >A better way to solve this problem is to modify the keyboard >mapping of your X server. The commands > > xmodmap -e "clear Lock" > xmodmap -e "clear Mod2" > xmodmap -e "clear Mod5" > >remove the CapsLock, NumLock and ScrollLock from the keyboard map. >Pressing these keys has no effect then. To re-add them try this: > > xmodmap -e "add Lock = Caps_Lock" > xmodmap -e "add Mod2 = Num_Lock" > xmodmap -e "add Mod5 = Scroll_Lock" > >Fvwm has to be restarted to use the changes made by xmodmap. >Please refer to the man page of the xmodmap command for further >details. > -- > > > The only way to restore the state is to toggle the keyboard to US. > > After that it is also possible to toggle it to Czech again and > > fvwm starts working properly. Czech keyboard itself is not a problem, > > fvwm works OK with it, but something wrong happens after exiting an > > xterm. > > > > I do not know what configuration files should I add, because I don't > > kn
Re: cvs checkout is broken
On Sun, Jan 06, 2002 at 06:02:57PM -0600, Jason L Tibbitts III wrote: > Is it better now? > Thanks. It seems that I do cvs add hints/ -m "new directory" in the place of cvs add -m "new directory" hints/ and this probably cause the problem. Olivier -- Visit the official FVWM web page at 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]
CVS domivogt: * Updated Q 5.5.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/01/07 06:34:25 Modified files: docs : ChangeLog FAQ Log message: * Updated Q 5.5. -- Visit the official FVWM web page at 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]
CVS domivogt: * IgnoreModifiers is passed to modules.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/01/07 06:30:24 Modified files: . : ChangeLog fvwm : bindings.c fvwm2.1 modconf.c module_interface.c module_interface.h libs : Parse.c defaults.h modules: ChangeLog modules/FvwmIconMan: FvwmIconMan.c FvwmIconMan.h fvwm.c readconfig.c x.c Log message: * IgnoreModifiers is passed to modules. * FvwmIconMan uses IgnoreModifiers. * Cleaned up module config code a bit. -- Visit the official FVWM web page at 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: Notification: incoming/837
On Sun, Jan 06, 2002 at 09:32:18PM +0100, Hana Stara wrote: > On Sun, 2002-01-06 at 02:14, Dominik Vogt wrote: > > On Sat, Jan 05, 2002 at 03:50:28AM -0600, fvwm-bug wrote: > > > FVWM Bug Tracking notification > > > > > > new message incoming/837 > > > > > > Version: all newer than fvwm2-2.2.4-9 > > > CVS_Date: > > > OS: redhat 7.x > > > X_Server: 4.0.3 > > > Submission from: (NULL) (147.229.25.195) > > > > > > > > > Hello, > > > > > > I am still using fvwm2-2.2.4-9 because newer versions have a bug. > > > I use two different keyboard layouts (Czech and US) and I toggle > > > between them by pressing left and right shift simultaneously. > > > I found this problem: > > > > Is this problem in 2.2.4 or in 2.4.x? If it is only in 2.2.4, > > please tell the bug that you mentioned above. If it is in 2.4.x, > > please provide the scripts and the keymaps you are using so that > > I can try this myself. > > > I tried there versions: > > fvwm2-2.2.5-4 ... OK > fvwm2-2.2.4-9 ... OK > fvwm-2.4.0... bug > fvwm-2.4.3... bug > fvwm-2.4.4... bug > > As for the X server, I also tried XFree86-4.1.0-3 but > with the same result. :-( > > > > 1) I open an xterm (or rxvt) > > > 2) I exit the xterm > > > > > 3) when the Czech keyboard layout is active, fvwm ignores all > > >key presses. > > > > What does this mean? Do other windows still get input or is the > > keyboard completely frozen? If only fvwm specific keystrokes do > > not work anymore, please check if Q 5.5 from our FAQ helps > > solving the problem. > > > I don't know how to find where the the keystrokes get lost. > But now I found something that could help to localize the problem: > If I exit ANY application, the resulting state is that no window has > focus. When no window has focus, the problem occurs. But on the > other hand I do not know if windows get input - because no window > has focus :-( > > I wrote you that after exiting rxvt (xterm) the problem occurs > - it is not correct. It happens, when no window has focus. > > Toggling keyboard to US and back to Czech does not help! > Sorry for confusing, I made mistake. So I will try to define the > problem once more: I am still not sure what the problem is you encounter. Please answer these questions: - After the problem appears, can you still focus a window by moving the mouse ofer it or by clicking on its title? - If yes, can you type into that newly focused window? - Do your fvwm keyboard shortcuts still work? - Can you still move windows with the mouse? Are you saying that you can't focus a win > ___ > || When no window has focus, the keyboard layout must be US. || > --- And if it isn't? What exactly happens then? > As for the FAQ 5.5 - I don't understand that :-( My point was: if its only fvwm internal bindings that do not work this may be caused by some modifier keys like num-lock changing state when the keymap is changed. Toggling that key again would help in this case. But with your explanations above I don't think that is your problem. > I use a non-standard keyboard layout - my friend Yeti has made > a rpm package so I send that as an attachment. Um, can you just send the files in a tar.gz? I don't like to install rpm packages on my system because I can't control where they end up. Also, please post your fvwm config file. > But I don't think it is the source of problem. I don't think it's the source of the problem either, but I need it to reproduce the problem. > Please tell me, what more diagnostics should I do. > > > -- > > > > > The only way to restore the state is to toggle the keyboard to US. > > > After that it is also possible to toggle it to Czech again and > > > fvwm starts working properly. Czech keyboard itself is not a problem, > > > fvwm works OK with it, but something wrong happens after exiting an > > > xterm. > > > > > > I do not know what configuration files should I add, because I don't > > > know where the problem is. But if you e-mail me, I will cooperate > > > and do what you want. Please reply to fvwm-workers@fvwm.org, not to me personally. 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 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: CVS olicha: * Fixed transparent animated menu
Hi! Nice to hear that fvwm will have support for that fancy transparency feature. Just a few comments. On Sat, 5 Jan 2002, Dominik Vogt wrote: [SNIP] > > Unfortunately, it does not seems that there is a standard > > for this but some programs use the ESETROOT_PMAP_ID and the > > _XROOTPMAP_ID atoms. > > Anyway, ParentRelative doe not really give transparency for top > level windows. You don't see what is behind the window, only the > contents of the root window there. Of course, ParentRelative gives you not the "contents" of the parent window, but only its BackgroundPixmap with a correct offset. So, if there's something more than just a wallpaper on a root window (e.g. Windoze-style icons/shortcuts), they aren't copied. Of course, unless they are drawn on the same pixmap that is a BackgroundPixmap. [SNIP] > > In any case, a pixmap copy of the root window may be better > > than the ParentRelative pixmap under certain situation. > > Both approchaes have one big problem: X doesn't do the updates > itself. When you move a 'transparent' window, X moves whatever > background it has. You have to redraw the background yourself. > This looks very unpleasant. The right way to do transparency in X > is to use the Shape extension. But then, applications have to be > specifically written to use it. You don't have to redraw the background yourself, all you have to do is call XClearArea(). The server will update the background itself and send you an ExposeEvent, upon receipt of which the app should only redraw all "foreground" elements. I.e., in no case should the app redraw the background -- if either the BackgroundPixmap or BackgroundPixel are specified, the server will do the dirty work itself. This feature significantly improves performance, especially if the server and the app are on different machines. The only exception is when BackgroundPixmap=None, but that means that app knows what it is doing. [SNIP] > Also, remember that a copy of the screen can be very big:i > 1600x1200 pixels with 32 bit planes = 7.5 MB. That's the reason > why I did not go this way in the past. > > > But what do you mean by "double buffer". > > Keep a copy of the screen in a pixmap, draw into the pixmap, then > copy the pixmap (or parts of it) onto the screen. There's an extension of double buffering: when the same pixmap is used as a BackgroundPixmap and as a "shadow buffer". In that case one has to manually copy parts of that pixmap onto the screen only upon changes, and all the subsequent redraws are done by the server -- the app may completely ignore Expose events for such shadow-buffered windows. As to "ParentRelative" in general: I've tried to use it in Motif apps to make nice "wallpapered" dialog windows. This feature *is* useful, since you don't have to manually put/assign parent's background pixmap to all widgets (labels, checkboxes etc.). But a lot of work yet have to be done by the program, since the top/bottom shadows, "focused widget" rectangles etc. should be correctly generated taking the background into account. _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia -- Visit the official FVWM web page at 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]
