Re: CVS domivogt: * New command ModuleListenOnly.
On Sat, Jun 24, 2006 at 01:23:11PM +, Mikhael Goikhman wrote: On 24 Jun 2006 06:52:13 -0500, FVWM CVS wrote: Changes by: domivogt06/06/24 06:52:13 Modified files: modules/FvwmPerl: FvwmPerl.1 This man page (like several others) is generated from FvwmPerl.in by make _FvwmPerl.1. Any changes done to FvwmPerl.1 will be lost. Yes, I changed it in the source when I noticed my mistake but wasn't aware the man page is in CVS. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: ModuleListenOnly command
On Sat, Jun 24, 2006 at 02:08:43PM +, Mikhael Goikhman wrote: On 24 Jun 2006 13:58:30 +0200, Dominik Vogt wrote: I have just checked in the new command ModuleListenOnly. It works like Module, but fvwm does not send any messages to such a module. I am using it to attach a shell script to the module interface that periodically updates titles of FvwmButtons to display a clock (in the format I prefer, xclock is too stupid) and the process that currently consumes most cpu. I can't say I am very happy about this. Actually, I would not be happy about any new feature added without discussion before 2.6.0. :) Hm, I don't see that happen in the foreseeable future. Nobody is doing anything in that direction. The problem with this solution is that in order to use it, every script should include non obvious parts of the module interface, and once the interface is changed such scripts stop to work correctly. Oh, but it doesn't. All it relies on are the command line arguments and the message format. Both is documented. The only thing I did not care to find out in my script is the size and byte order of a long. (The SET_MASK stuff was left over from the pre-ModuleListenOnly version and can be removed). AddToFunc InitFunction + I ModuleListenOnly /home/users/bin/fvwm_periodic ... AddToFunc RestartFunction + I ModuleListenOnly /home/users/bin/fvwm_periodic ... I would use StartFunction here, once. But, if I understand correctly, the script does not quit when you quit or restart fvwm (because a pseudo module does not really communicate with fvwm), so you also need to kill it in ExitFunction. It exits when it gets a SIGPIPE, just like any other module. Of course you have to code it that way: trap 0 1 2 3 9 13 15 exit I may see several solutions using the existing commands and not having such problems. FvwmCommandS and Exec is one solution that doesn't require the module protocol knowledge. There are several perl-based solutions. Fact is, starting FvwmCommand every time I want to send a command disturbs the system because it needs to start a process. With the exception of the ps- and sort-commands, my fvwm_periodic module is a pure zsh-script, and that's because I could not figure how to do it without calling an external command. And eventually I wasn't able to find out how to do it with FvwmPerl by reading the man page (I'm a zsh-person, not a Perl-person). We may write a module FvwmButtonsUpdater that gets an FvwmButtons module name (alias) and a list of entries, each is: a button id, its update frequency and a shell command to invoke for title updates (for example, 'date +%T' or 'ps -A --format %C %P %c | sort -n -r | head -1'). Maybe someone will write such configurable module, useful for everybody. That's the idea. My script should eventually end up with its portability issues fixed (although I don't see how all this could be done without zsh). It is not very hard after reading fvwm-perllib man. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: ModuleListenOnly command
On Sun, Jun 25, 2006 at 03:22:57AM +1000, Scott Smedley wrote: We may write a module FvwmButtonsUpdater that gets an FvwmButtons module name (alias) and a list of entries, each is: a button id, its update frequency and a shell command to invoke for title updates (for example, 'date +%T' or 'ps -A --format %C %P %c | sort -n -r | head -1'). Maybe someone will write such configurable module, useful for everybody. It is not very hard after reading fvwm-perllib man. Why use a module for something so simple? AddToFunc MyPeriodicFunc + I PipeRead 'echo SendToModule FvwmButtons ChangeButton clock Title $(date +%R %a %d.%m.)' + I PipeRead 'str=$(/bin/ps -A --format %C %P %c | sort -n -r | tail -n1) ; echo SendToModule FvwmButtons ChangeButton topproc Title $str' + I Schedule 15000 MyPeriodicFunc Schedule 3000 MyPeriodicFunc The topproc calculation can be tidied up. This is just a proof-of-concept. Two reasons: (1) Schedule is an unreliable hack and (2) this starts a shell every 15 seconds and my goal was to waste as little cpu as possible (as it interferes with certain time-critical applications - okay - games). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: manual placement quirk: window not always placed at outline
On Tue, May 30, 2006 at 09:34:06PM -0700, Andrew Pimlott wrote: On Tue, May 30, 2006 at 11:11:11PM +0200, Dominik Vogt wrote: On Mon, May 29, 2006 at 02:27:15PM -0700, Andrew Pimlott wrote: To resolve this issue, we must 1. decide whether the outline should initially appear snapped or unsnapped; Unsnapped. In case of moving a window, placing it before touching the mouse should not move the window at all. Hmm, I didn't really think about this case. However, I'm not sure that makes the most sense. Surely if you initiate a move, you want to put the window someplace other than where it was? And as soon as you move a single pixel (which most people would do without even meaning to, assuming they are using the mouse), the window will snap, causing a jarring discontinuity. I think I would rather have the snap happen right away. Anyhow, if we go with your answer, fixing the code is non-trivial. The whole event loop would probably need to be cleaned up. I don't think I'm up to doing it myself. It actually wasn't this bad. The idea behing the test in the ButtonReleasee handler was to make sure the window is snapped if the window did not move before, but the pointer position in the release event moved the window. In my eyes, the window should not move at all if the pointer does not move (i.e. the user changes her mind or is just playing with the mouse, as I often do). == The window should not be snapped The patch I have just committed makes sure the ButtonRelease applies the snapped position, even if the pointer did not move. Initial snapping in your patch was flawed because it ignored the do_snap flag which was not set at that time (you'd have to query the X server for it). I removed the initial snapping, but with in outline mode you sometimes (or maybe always) get initial snapping because some EnterNotify or LeaveNotify event triggers a faked motion event. This does not happen in opaque mode. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Quoting extended variables
On Sun, Jun 04, 2006 at 12:50:19AM +, Mikhael Goikhman wrote: I think the ultimate solution is explained in file doc/todo-vars. Among other things, it says that we only have variables in format $[], all one letter variables are deprecated, and that a user may request not to quote a value or choose from several quoting styles. However, we should decide about the default behaviour of variables (when no explicit filters are specified). All variables with integer value like $[w.x] or fixed string value like $[version.num] should not be quoted by default. All window name related variables should be qingle-quoted by default. There is no question here, because names are really arbitrary. However, it is not clear about other less-arbitrary strings. I.e. should $. be quoted? Currently it is quoted, but there is almost no chance someone has quote characters in fvwm directories. On the other hand, spaces are a bit more likely, so quoting here has pluses (less to type) and minuses (may be surprised). Should $[w.iconfile] and $[w.miniiconfile] be quoted by default? I don't know. And finally, should $[ENV_VAR] like $[PATH] be quoted by default? Hm. I see pros and cons to do this. Most of variable values (even $PATH) has an expected value, so a user may guess about a proper quoting on his own. On the other hand, the consistent solution would be to always quote any string var. Hm, isn't the right way to fix this mess to rewrite the parser from scratch? I have the impression that we're trying to solve problems that are caused bay the flawed design. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Title font color broken
On Sat, Jun 03, 2006 at 07:28:11PM +0100, Thomas Adam wrote:
On Sat, Jun 03, 2006 at 11:57:58AM -0400, Dan Espen wrote:
It's been a while since I've updated to CVS Maybe a month or 2 .
After the last update, the text in my window titles is black. These
commands have no effect:
Style * ForeColor HilightFore
Last I heard those commands were being deprecated in favour of using
colorsets.
They are not desprecated at the moment.
I know about this problem and I'm quite sure which particular
commit caused it:
2006-02-09 Dominik Vogt ...
...
* libs/Flocale.c (FlocaleFontStructDrawString):
(FlocaleDrawString):
set the foreground colour before drawing a string
(diff attached).
Unfortunately I never got any feedback on this from the person who
reported it first. The problem was that in some cases the GC used
to draw the title was not set before drawing, but it seems the old
code relied on this not being done.
I'd be grateful if someone could look into this problem or at
least give me a minimal config to reproduce it.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Index: Flocale.c
===
RCS file: /home/cvs/fvwm/fvwm/libs/Flocale.c,v
retrieving revision 1.75
retrieving revision 1.76
diff -u -B -b -u -r1.75 -r1.76
--- Flocale.c 26 Nov 2005 21:55:12 - 1.75
+++ Flocale.c 9 Feb 2006 11:49:33 - 1.76
@@ -617,6 +617,9 @@
is_string16, dpy, d, gc, xt, yt,
fws-e_str, fws-str2b, len);
}
+ }
+ if (has_fg_pixels)
+ {
XSetForeground(dpy, gc, fg);
}
xt = gstp_args.orig_x;
@@ -909,7 +912,6 @@
dpy, fws-win, my_gc, xpsh, ypsh, rotated_w,
rotated_h);
}
- XSetForeground(dpy, my_gc, fg);
}
xpsh = gstp_args.orig_x;
ypsh = gstp_args.orig_y;
@@ -1932,8 +1935,8 @@
dpy, fws-win, flf-fontset, fws-gc,
xt, yt, fws-e_str, len);
}
- XSetForeground(dpy, fws-gc, fg);
}
+ XSetForeground(dpy, fws-gc, fg);
xt = gstp_args.orig_x;
yt = gstp_args.orig_y;
XmbDrawString(
@@ -2001,8 +2004,8 @@
buf2,
strlen(buf2));
}
- XSetForeground(dpy, fws-gc, fg);
}
+ XSetForeground(dpy, fws-gc, fg);
xt = gstp_args.orig_x;
yt = gstp_args.orig_y;
XmbDrawString(
signature.asc
Description: Digital signature
Re: bug in the 'Scroll' command
On Thu, Jun 01, 2006 at 07:21:35PM +0400, Serge (gentoosiast) Koksharov wrote: Hello, It looks like I found bug in 'Scroll' command. Excerpt from manpage: If the horizontal and vertical percentages are multiplied by 1000 then scrolling wraps around at the edge of the desktop. If Scroll 10 0 is executed over and over fvwm moves to the next desktop page on each execution and wraps around at the edge of the desktop, so that every page is hit in turn. This example works. But now try, for example, command 'Scroll 5 0'. In this case fvwm should move to the half of the next right desktop page. But as a matter of fact it moves to the extreme right page. So it obviously a bug. Actually, any value smaller than 10 can not wrap anyway because it does not go far enough across the screen edge. But the real reason why values between 1000 and 9 do not wrap is that the code has to cope with values given in pixels, e.g. 1280p. With the current syntax it is not possible to code a properly working Scroll command. Instead we should have additional options to activate wrapping, e.g. Scroll 100 0 wrapx Scroll 200 150 wrapy with values = 10 still triggering wrapping for compatibilty. I've clarified this in the man page for now. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: manual placement quirk: window not always placed at outline
On Mon, May 29, 2006 at 02:27:15PM -0700, Andrew Pimlott wrote:
I have been bothered by a situation where I create a window and manually
place it at one location, but the window actually appears in a different
location. It is easy to reproduce with a very small .fvwm2rc:
Style * ManualPlacement
EdgeResistance 0 100
Start by placing an xterm in the lower right corner of the screen,
touching the side and bottom. Place the mouse near the upper left
corner of the window, within the window. Type xterm and press enter.
You will see the new window outline appear exactly over the border of
the first xterm; that is, it appears snapped to the edges of the screen.
Press enter to place the window. Note that it is placed not where the
outline was, but at the pointer position.
I investigated the code in __move_loop, in move_resize.c. (I am using
fvwm 2.5.16, but the file is identical in the 20060529 snapshot I just
checked). The problem is that in case ButtonRelease (line 2445),
there is a test that says if the mouse is in the same position it
started in, don't apply the snap. This idea is that if the mouse didn't
move, the outline never snapped, so the window shouldn't snap either.
This is an ill-conceived test for two reasons. One, the mouse could
have moved and moved back to its original position! It's not actually
that hard to achieve this. Two, there are cases other than mouse
movement that causes the window outline to snap. For example, if an
EnterNotify or LeaveNotify event is received (2301), a MotionNotify
event is faked up, and in case MotionNotify (2483), DoSnapAttract is
called to snap the outline. This is in fact what happens in the test
case above.
However, it is not always the case that the initial outline is snapped.
If there were not already a window below the mouse when I ran xterm, no
EnterNotify event would have been received, and thus the outline would
have appeared unsnapped, at the pointer. This inconsistency is cause of
further confusion to the user: Why does the outline initially appear
snapped sometimes and not other times?
To resolve this issue, we must 1. decide whether the outline should
initially appear snapped or unsnapped;
Unsnapped. In case of moving a window, placing it before touching
the mouse should not move the window at all.
2. ensure that the outline in
fact initially appears snapped or unsnapped consistently;
Ok.
3. ensure that
the window gets placed where the outline appeared.
Ok.
I took what seems to be the simplest approach (a necessity for me, given
the serpentine nature of this function), which is also the behavior I
find the most natural: I decided that the outline should always start
out snapped. It is only a couple of lines to snap the outline at the
top of the function, and then unconditionally snap on ButtonRelease.
The below patch Works For Me.
Andrew
PS. Please Cc: me, as I am not subscribed.
--- move_resize.c.orig2006-05-29 14:15:16.0 -0700
+++ move_resize.c 2006-05-29 14:18:37.0 -0700
@@ -2197,6 +2197,10 @@
xl_orig = xl;
yt_orig = yt;
+ /* Without this, the outline sometimes initially shows snapped,
+ * sometimes unsnapped. At least this is consistent. */
+ DoSnapAttract(fw, Width, Height, xl, yt);
+
/* draw initial outline */
if (!IS_ICONIFIED(fw)
((!do_move_opaque !Scr.gs.do_emulate_mwm) || !IS_MAPPED(fw)))
@@ -2463,15 +2467,9 @@
xl = xl2;
yt = yt2;
}
- if (xl != xl_orig || yt != yt_orig || vx != Scr.Vx ||
- vy != Scr.Vy)
+ if (do_snap)
{
- /* only snap if the window actually moved! */
- if (do_snap)
- {
- DoSnapAttract(
- fw, Width, Height, xl, yt);
- }
+ DoSnapAttract(fw, Width, Height, xl, yt);
}
*FinalX = xl;
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: What are the hide windows in frame.c?
On Wed, May 10, 2006 at 04:40:19PM +0200, Viktor Griph wrote: On Wed, 10 May 2006, Dominik Vogt wrote: On Wed, May 10, 2006 at 12:17:38AM +0200, Dominik Vogt wrote: On Tue, May 09, 2006 at 11:25:41PM +0200, Viktor Griph wrote: On Fri, 5 May 2006, Dominik Vogt wrote: On Thu, May 04, 2006 at 08:54:25PM +0200, Viktor Griph wrote: When are the hide windows useful in frame.c? The call to frame_reparent_hide_windows in frame_create_move_resize_args casue X to generate extra VisibilityNotify events to clients during capture and redecoration (bug #3977). The hide windows are emtpy windows (with a None background pixmap). I introduced them to reduce flickering of the window decorations when a window is resized, and - more important - shaded or unshaded. The problem is that when you resize a window, you can tell X which border its subwindows should stick to. But you can not tell it where the subwindows of subwindows should go, and it's not possible to resize subwindows in the same operation. Because of this, I use the hide windows to cover some parts of the decorations, resize the window, redraw the the changed parts of the decorations windows (using a background pixmap, not using the foreground), then unmap the hide windows to uncover the changed decorations. Usually, the hide windows stay invisible because htey have no contents and just show what was below them until they are covered by something else. Now I understand the need for them for resize operations. Would it be possible to narrow down the need for that function call to some specific case? I don't see any way but at the expense of flickering decorations and subwindows, especially with opaque resizing. Am I right if I say that the hide windows do no good if it is a setup request and the frame size has not changed? I'm not sure how the initial mapping is treated, but I believe they do no good for that either. It's just a little harder to seed that condition from withing the function. I'm not entirely sure about this, but as far as I remember the hide windows are resized to cover only the relevant parts of the window. I.e. if the window size does not change, the hide windows do not cover anything (I'm not sure if the hide windows are used at all in that case). There may be some room for optimizing here. I just checked the code. As far as I can see, the hide windows just cover the decorations if the window size does not change. Unless the size calculations are going wrong I can not see why this causes extra Expose/VisibilityNotify events on the client window. Something is wrong with the calculations. I don't have time to check them now but there seems to be problems with borderless windows and windows with with no title at top. You may try to open a FvwmConsole and do # Move the title to a non-top position Current WindowStyle TitleAtLeft # The following works fine i.e. no extra redraw Style * !Button 0 # This one on the other hand casue a redraw of the top of the console # compareable to title height Style * !Button 0 # Now move the title to the right Current WindowStyle TitleAtRight # this will cause a redraw of the area where the title last were present. Style * !Button 0 This may be due to other bugs, but it's the hide windows that casue the observable effect. Similar, but not equal, effect may be observed if Style * is replaced by Current WindowStyle. I believe the windows aren't moved until after they are shown, or that some in other way old information is used to calculate the size of the hide windows. Actually, the hide_window code does not deal with decoration layout changes; it assumes the decoration sizes on each side of the window are constant in a setup operation. It's just meant to allow smooth resizing and shading. We can live with this specific problem, I guess. Also windows with no borders get hide windows covering the client window. Uh, the hide windows get a random size in this case. Instead, they should not be mapped at all. I'll fix this. As it stands now I'm not sure if any of this is related to bug #3977. I've not been able to reproduce the said flickering with xdvi, nor am I able to reproduce the events with an xev window. In fact I believe the bug must be due to some specific configuration. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: What are the hide windows in frame.c?
On Wed, May 10, 2006 at 12:17:38AM +0200, Dominik Vogt wrote: On Tue, May 09, 2006 at 11:25:41PM +0200, Viktor Griph wrote: On Fri, 5 May 2006, Dominik Vogt wrote: On Thu, May 04, 2006 at 08:54:25PM +0200, Viktor Griph wrote: When are the hide windows useful in frame.c? The call to frame_reparent_hide_windows in frame_create_move_resize_args casue X to generate extra VisibilityNotify events to clients during capture and redecoration (bug #3977). The hide windows are emtpy windows (with a None background pixmap). I introduced them to reduce flickering of the window decorations when a window is resized, and - more important - shaded or unshaded. The problem is that when you resize a window, you can tell X which border its subwindows should stick to. But you can not tell it where the subwindows of subwindows should go, and it's not possible to resize subwindows in the same operation. Because of this, I use the hide windows to cover some parts of the decorations, resize the window, redraw the the changed parts of the decorations windows (using a background pixmap, not using the foreground), then unmap the hide windows to uncover the changed decorations. Usually, the hide windows stay invisible because htey have no contents and just show what was below them until they are covered by something else. Now I understand the need for them for resize operations. Would it be possible to narrow down the need for that function call to some specific case? I don't see any way but at the expense of flickering decorations and subwindows, especially with opaque resizing. Am I right if I say that the hide windows do no good if it is a setup request and the frame size has not changed? I'm not sure how the initial mapping is treated, but I believe they do no good for that either. It's just a little harder to seed that condition from withing the function. I'm not entirely sure about this, but as far as I remember the hide windows are resized to cover only the relevant parts of the window. I.e. if the window size does not change, the hide windows do not cover anything (I'm not sure if the hide windows are used at all in that case). There may be some room for optimizing here. I just checked the code. As far as I can see, the hide windows just cover the decorations if the window size does not change. Unless the size calculations are going wrong I can not see why this causes extra Expose/VisibilityNotify events on the client window. Actually, if applications like xdvi have a below par redraw algorithm (i.e. they redraw whenexer they receive an Expose event), that's the applications' problem and not the problem of the window manager. It's true that the application may be behaving badly, but there are several application that show similar flickering due to the exrtra events on a redecoration. if it's possible to work around the events with the window mannager it's a good thing to do, but not at the expense of some other functionality. Just for reference the thing that annoys me most about this is the fact that my titleless pager and xbuffy flash whenever I redecorate (including even disable an already disabled title bar button) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Trivial typos fixes
On Tue, May 09, 2006 at 10:21:17PM +0400, Serge (gentoosiast) Koksharov wrote: Greetings, Here is a patch which fixes several trivial typos in fvwm 2.5.x CVS tree which I recently discovered: silde - slide somthing - something unkown - unknown unknow - unknown PGraphicsCreateTransprency - PGraphicsCreateTransparency (renamed function everywhere in the source tree) Also, I fixed typo in 'TitleColorset' style description in the 'fvwm' manpage. Thanks! I've applied the patch. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: What are the hide windows in frame.c?
On Tue, May 09, 2006 at 11:25:41PM +0200, Viktor Griph wrote: On Fri, 5 May 2006, Dominik Vogt wrote: On Thu, May 04, 2006 at 08:54:25PM +0200, Viktor Griph wrote: When are the hide windows useful in frame.c? The call to frame_reparent_hide_windows in frame_create_move_resize_args casue X to generate extra VisibilityNotify events to clients during capture and redecoration (bug #3977). The hide windows are emtpy windows (with a None background pixmap). I introduced them to reduce flickering of the window decorations when a window is resized, and - more important - shaded or unshaded. The problem is that when you resize a window, you can tell X which border its subwindows should stick to. But you can not tell it where the subwindows of subwindows should go, and it's not possible to resize subwindows in the same operation. Because of this, I use the hide windows to cover some parts of the decorations, resize the window, redraw the the changed parts of the decorations windows (using a background pixmap, not using the foreground), then unmap the hide windows to uncover the changed decorations. Usually, the hide windows stay invisible because htey have no contents and just show what was below them until they are covered by something else. Now I understand the need for them for resize operations. Would it be possible to narrow down the need for that function call to some specific case? I don't see any way but at the expense of flickering decorations and subwindows, especially with opaque resizing. Am I right if I say that the hide windows do no good if it is a setup request and the frame size has not changed? I'm not sure how the initial mapping is treated, but I believe they do no good for that either. It's just a little harder to seed that condition from withing the function. I'm not entirely sure about this, but as far as I remember the hide windows are resized to cover only the relevant parts of the window. I.e. if the window size does not change, the hide windows do not cover anything (I'm not sure if the hide windows are used at all in that case). There may be some room for optimizing here. Actually, if applications like xdvi have a below par redraw algorithm (i.e. they redraw whenexer they receive an Expose event), that's the applications' problem and not the problem of the window manager. It's true that the application may be behaving badly, but there are several application that show similar flickering due to the exrtra events on a redecoration. if it's possible to work around the events with the window mannager it's a good thing to do, but not at the expense of some other functionality. Just for reference the thing that annoys me most about this is the fact that my titleless pager and xbuffy flash whenever I redecorate (including even disable an already disabled title bar button) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
style matching in current CVS
First, this code from style.c generates a warning:
if (SID_GET_HAS_NAME(s_id) (fw-style_name == NULL
(matchWildcards(SID_GET_NAME(s_id), fw-class.res_class) == TRUE ||
matchWildcards(SID_GET_NAME(s_id), fw-class.res_name) == TRUE ||
matchWildcards(SID_GET_NAME(s_id), fw-name.name) == TRUE)) ||
matchWildcards(SID_GET_NAME(s_id), fw-style_name ) == TRUE)
{
return True;
}
style.c: In function `fw_match_style_id':
style.c:176: warning: suggest parentheses around within ||
Second, the code may access a NULL pointer style_name if neither
of the first three matchWildcards is true.
Also, I think even if style_name is not NULL, the usual style name
matching should be done:
if (SID_GET_HAS_NAME(s_id))
{
if (matchWildcards(SID_GET_NAME(s_id), fw-class.res_class) ==
TRUE)
{
return True;
}
if (matchWildcards(SID_GET_NAME(s_id), fw-class.res_name) ==
TRUE)
{
return True;
}
if (matchWildcards(SID_GET_NAME(s_id), fw-name.name) == TRUE)
{
return True;
}
if (fw-style_name == NULL
matchWildcards(SID_GET_NAME(s_id), fw-class.res_class) ==
TRUE)
{
return True;
}
}
(I have committed this code to CVS, but feel free to change it).
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: mkstemp bug in the FVWM 2.5 branch with possible security consequences
On Tue, Apr 04, 2006 at 02:38:21AM +0400, Serge (gentoosiast) Koksharov wrote: Good (day|morning|night) everyone, During examination of FvwmM4 '--debug' option I decided to examine FVWM's temporary file creation mechanism. Can you believe what I dig out: In libs/System.c there is a pragma '#ifdef HAVE_SAFTY_MKSTEMP'. This construction decides based on configure script system check whether to use underlying OS's mkstemp function (if it considered secure) or FVWM's internal one, which lies at the bottom of the same libs/System.c file. But acinclude.m4 defines 'HAVE_SAFETY_MKSTEMP' pragma, not 'HAVE_SAFTY_MKSTEMP' which found in libs/System.c. So, in any case FVWM's internal implementation of mkstemp used even if the OS have its own _much more secure_ version of this function. This bug probably existed for almost three years and was introduced on 2003-08-27 according to main Changelog. I attached patch which applies cleanly against 2.5.x CVS sources. It also corrects all other 'safty' typos in the source tree. Somebody on the list needs to verify stable 2.4 branch also. This example shows that a single typo can potentially lead to the big disaster. I hope it will be good lesson to all of us. In future, all workers should review every commit more attentively. It's much easier to not introduce newer bugs and typos than to find and fix them afterwards. I wonder, was FVWM's code extensively audited? Who knows that may be lurking inside? I have committed this patch. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: style matching in current CVS
On Thu, Apr 06, 2006 at 11:13:03AM +0200, Dominik Vogt wrote:
First, this code from style.c generates a warning:
if (SID_GET_HAS_NAME(s_id) (fw-style_name == NULL
(matchWildcards(SID_GET_NAME(s_id), fw-class.res_class) == TRUE ||
matchWildcards(SID_GET_NAME(s_id), fw-class.res_name) == TRUE ||
matchWildcards(SID_GET_NAME(s_id), fw-name.name) == TRUE)) ||
matchWildcards(SID_GET_NAME(s_id), fw-style_name ) == TRUE)
{
return True;
}
style.c: In function `fw_match_style_id':
style.c:176: warning: suggest parentheses around within ||
Second, the code may access a NULL pointer style_name if neither
of the first three matchWildcards is true.
Also, I think even if style_name is not NULL, the usual style name
matching should be done:
if (SID_GET_HAS_NAME(s_id))
{
if (matchWildcards(SID_GET_NAME(s_id), fw-class.res_class) ==
TRUE)
{
return True;
}
if (matchWildcards(SID_GET_NAME(s_id), fw-class.res_name) ==
TRUE)
{
return True;
}
if (matchWildcards(SID_GET_NAME(s_id), fw-name.name) == TRUE)
{
return True;
}
if (fw-style_name == NULL
matchWildcards(SID_GET_NAME(s_id), fw-class.res_class) ==
TRUE)
{
return True;
}
}
(Note that multi-line conditions with mixed and || operators
are hard to read. If you happen to edit such a condition, please
split it into separate conditions.)
(I have committed this code to CVS, but feel free to change it).
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: style matching in current CVS
On Thu, Apr 06, 2006 at 11:42:17AM +0200, Viktor Griph wrote: Just some conciderations: The manpage states that styles are search for in a specific order. I really fail to see how this information is useful while examining the logic, other than for the face that matchig early will save some comparitions. Am I missing something? Do you mean this text: They are searched in the reverse order stated. When two conflicting styles apply to the same window, the style that was changed last wins. This just means that style lines issued later override earlier styles. The text is confusing, though. I've committed a copy-paste-error fix (you never compared with style_name). :-P By the way, the function fw_match_style_id wasn't mentioned in your original ChangeLog entry. Please try to always mention *all* changed functions. This simplifies code maintenance enormously. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: style matching in current CVS
On Thu, Apr 06, 2006 at 12:13:17PM +0200, Viktor Griph wrote: On Thu, 6 Apr 2006, Dominik Vogt wrote: On Thu, Apr 06, 2006 at 11:42:17AM +0200, Viktor Griph wrote: Just some conciderations: The manpage states that styles are search for in a specific order. I really fail to see how this information is useful while examining the logic, other than for the face that matchig early will save some comparitions. Am I missing something? Do you mean this text: They are searched in the reverse order stated. When two conflicting styles apply to the same window, the style that was changed last wins. I've always thought the first sentece They are searched in the reverse order stated. referre back to the order given in the previous statement, i.e I've read stated as stated here. Now that you say it it is fullt pssible, and probably makes more sence to interpet it as some sort of double information the the second sentence you quoted. Hm, I think this text has to be rewritten. Facts are: * Styles issued later override styles issued earlier. * Multiple styles in a single style line are parsed from left to right, i.e. Style * MouseFocus, SloppyFocus is equivalent to Style * MouseFocus Style * SloppyFocus (SloopyFocus wins). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: XResources and styles
On Sat, Mar 25, 2006 at 10:36:18AM +0100, Viktor Griph wrote: On Sat, 25 Mar 2006, Dominik Vogt wrote: On Fri, Mar 24, 2006 at 06:32:18PM +0100, Viktor Griph wrote: Hi, does it exist any standard regulating the use of XResources? The reason I ask is that I recently found out that fvwm honors the resources Desk, Page and fvwmscreen for initial window positioning, and I find them quite neat to use together with apps supporting the -xrm option. I think that it would be good with a way to specify a style with resources in a similar way. The idea was that under AddWindow, before lookup_styles, add a resource lookup for some resource, say fvwmstyle, and if present map it to a WindowStyle command with rhe resource value as the style. All in all it comes down to two questions: Would adding such a resource break any standard? I don't think so. Good. Then I think it's ok as long as the resource starts with fvwm. and Is the feature described above something that should be added to fvwm? I think it's a good idea, but I wouldn't export the style syntax to the X resources. Instead, it should just add the style name to use for the application, i.e. (wahtever the correct syntax is). -xrm fvwmstyle: foobar The correct syntax for that would be -xrm *fvwmstyle:foobar. would tell fvwm to use the style foobar for the application (instead of the application name). This way, the whole configuration is still in the config file and there is no need to allocate styles dynamically (which is slow and potentially buggy). Sounds good, still if all you want is SkipMapping in addition to some default styles for the application, and want that for several different applications, that can result in many styles. That depends on how you do it: Style __skip_mapping_style SkipMapping $ xterm -xrm *fvwmstyle:__skip_mapping_style $ foobar -xrm *fvwmstyle:__skip_mapping_style However I belive that this way will be better with fvwm 3, so I'll give a try to implement it. I alrady have a draft implementaton[1] of my earlier suggested behaviour that I did while waiting for a reply. Implementing the suggested functionality will require an addition to the window structure. That also raise the question if a provided style name should be used for anything but style lookups, and if these should be any other ways, but resources, to set the provided style name. While this can be decided later, it's good to think of it aleady. One possiblity would be a SetStyle command that changes the style name used by a window. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Removing EWMH support?
On Fri, Mar 24, 2006 at 11:10:00PM +0100, Olivier Chapuis wrote: Ethan Blanton a écrit : Olivier Chapuis spake unto us the following wisdom: Now a note on _NET_CURRENT_DESKTOP (and _NET_DESKTOP_VIEW PORT), the EWMH spec says that this property (as a client msg) is for a pager. Thus if gtk_window_present() uses this property (and one may understand that it uses it in the *view of the doc*), you may understand that you go beyond what an application is espected to do at startup: is gaim a Pager? After some discussion with the Gaim folk who grok Gtk+, we have some questions ... are you actually _seeing_ _NET_CURRENT_DESKTOP or _NET_DESKTOP_VIEWPORT? I do not know I do not use gaim (I use psi). But I read the discussion on the forum and Dominik conclude that such msg was send by gaim. Moreover, my gtk_window_present() doc says: Presents a window to the user. This may mean raising the window in the stacking order, deiconifying it, moving it to the current desktop, and/or giving it the keyboard focus, possibly dependent on the user's platform, window manager, and preferences. So the doc says that gtk_window_present() may send a _NET_CURRENT_DESKTOP client msg. Maybe this depends on the version of gtk ... As best we can tell, gtk_window_present() calls gtk_window_show() when the window is not visible, and gtk_window_focus() when it is. We suspect that the gtk_window_focus is the problem, as it raises _NET_ACTIVE_WINDOW. Is it possible that fvwm is actually seeing _NET_ACTIVE_WINDOW, this causes it to switch desktops/pages? If so, is this an inappropriate client message (I don't believe it is.) It is clearly causing a behavior that at least some users are not pleased with. I think that Dominik ask the user with the gaim problem to disable _NET_ACTIVE_WINDOW msg for fvwm and the switching was still there. Dominik? I'm not entirely sure which message is sent. I suspected _NET_DESKTOP_VIEWPORT, but on the forum I was told that it was probably _NET_ACTIVE_WINDOW or NET_CURRENT_DESKTOP. I think we can rule out the second one because it does not match the behaviour the user saw. I do not think that _NET_ACTIVE_WINDOW is an inappropriate msg if the source indication is set to 2 (indicating a normal application msg). gtk does that with gtk_window_show() I think. I will add: a normal application can set the source indication to 1 (taskbar/pager) or send a _NET_CURRENT_DESKTOP msg if and only if this depends on a direct user action or if this is a (non default) option of the app (e.g., maybe some user like to have focus problems and want that an IM msg force the focus to the discussion window :o). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: XResources and styles
On Fri, Mar 24, 2006 at 06:32:18PM +0100, Viktor Griph wrote: Hi, does it exist any standard regulating the use of XResources? The reason I ask is that I recently found out that fvwm honors the resources Desk, Page and fvwmscreen for initial window positioning, and I find them quite neat to use together with apps supporting the -xrm option. I think that it would be good with a way to specify a style with resources in a similar way. The idea was that under AddWindow, before lookup_styles, add a resource lookup for some resource, say fvwmstyle, and if present map it to a WindowStyle command with rhe resource value as the style. All in all it comes down to two questions: Would adding such a resource break any standard? I don't think so. and Is the feature described above something that should be added to fvwm? I think it's a good idea, but I wouldn't export the style syntax to the X resources. Instead, it should just add the style name to use for the application, i.e. (wahtever the correct syntax is). -xrm fvwmstyle: foobar would tell fvwm to use the style foobar for the application (instead of the application name). This way, the whole configuration is still in the config file and there is no need to allocate styles dynamically (which is slow and potentially buggy). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: tweak for speed of TaskBar
On Thu, Mar 02, 2006 at 04:25:10PM -0500, Mark Allman wrote: I have just done a little re-config of my fvwm2 setup. I am going to try out the TaskBar module. But, in only using it for a couple of hours I can already feel my life wasting away while waiting for it to un-hide itself. I tried not hiding, but I do like the hiding. I went into the code and hacked the inc_y value in RevealTaskBar() to make the thing come up faster. I also played with inc_y in HideTaskBar() -- but, I ended up going back to the default (how fast the thing goes away is less of an issue for me). Might I suggest that the AutoHide config take a couple more parameters, so something like: AutoHide pixels reveal_speed hide_speed Or, just one speed knob for both operations would work, too. While I didn't go to the trouble of figuring out the code enough to determine how to make this happen, I imagine that for you gurus who know the code that has to be a pretty straightforward change. Just a suggestion ... maybe worth what you paid for it! :-) Actually, I'm not fond of the Autohide feature at all. It has many quirks, and there are functions for more robust autohiding in the FAQ that work with any application, not just the taskbar. I wouldn't spend any more time and patches to repair a feature that is fundamentally broken. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: fvwm-2.5.16: configure misparses 4-part version numbers
On Wed, Feb 22, 2006 at 03:14:34PM -0700, Steven Taschuk wrote: The configure script of fvwm 2.5.16 attempts to detect the versions of various packages installed and to verify that they are of an acceptably recent version. The code misparses version numbers that have more than three components. For example, on my machine the problem arises with Xft: $ ./configure [ ... several lines omitted ... ] checking for Xft - version = 2.0.0... ./configure: line 10146: test: 2.2: integer expression expected ./configure: line 10149: test: 2.2: integer expression expected yes [ ... several lines omitted ... ] Here's how it happens: The version number is detected by running xft-config --version, then parsing the output with a sed script: $ sed -n '1405,1406p' fvwm-2.5.16/acinclude.m4 xft_config_major_version=`$XFT_CONFIG $xft_config_args --version | \ sed 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\1/'` (With similar code on subsequent lines, and elsewhere for other packages.) The sed script replaces a three-part version number such as 2.0.1 with just its first component. However, on my system we have $ xft-config --version 2.1.2.2 The sed replaces the leading 2.1.2 with 2, resulting in 2.2, which confuses the subsequent comparison with the minimum required major version number. Perhaps something like xft-config --version | cut -d. -f1 (and the like) would be more robust; the attached patch to acinclude.m4 implements this notion, both for the xft autodetection and in the similar code for gtk, imlib, freetype2, and fontconfig. Thanks for the patch. I have rewritten the sed-expressions based on it as I don't want to introduce a new tool in the configure process (i.e. I want to avoid 'cut'). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Menu Title patch
On Tue, Feb 14, 2006 at 07:27:55PM +0100, Viktor Griph wrote: On Thu, 9 Feb 2006, Dominik Vogt wrote: I have applied the patch with some changes and bugfixes: * The text of the menuitem is always drawn in the given colour set (this required a bugfix in the text drawing library). I don't think this should be done if no colorset is specified for the title. In that case I belive it should use the color of the normal items, or old configs using other color than black will get a black title color. That's exactly what I said (or maybe wanted to say). Currently: * No TitleColorset given - normal item colours are used. * TitleColorset given - foreground of cs is used. * TitleColorset and HilightTitleBack given - foreground and background of cs ase used. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Comments
On Tue, Feb 14, 2006 at 09:10:09PM +0100, Viktor Griph wrote: Right now Style * Colorset 1 #, HilightColorset 2 is the same as Style * Colorset 1, HilightColorset 2 i.e. the # is simply ignored, which is somewhat correct according to the man page. In-line comments were never meant to work anyway. However most users familiar with shell-scripts and perl scripts would think that the end of the first line is a comment, also the fact that fvwm does not warn about ignoring unused arguments to style parts makes it really hard to spot such a misstake in a config file. (I actually didn't know that fvwm-comments had to start on the first character of a line until I looked it up in the man page right now. (and the emacs mode does not deal with that either ;))) However, it's not entierly sure that commetns only start on the beginning of a line, but they can also be before any command in stacked commands. No, not in the way you may think. In that case they are taken as part of the command and the '#' eventually becomes the first character of a command line and is interpreted as a comment. They *do not* comment out the rest of the line in which they occured. This in all can confuse some users (me included) alot. I think it would be good to think over the comment syntax, and maybe extend it to allow end of line comments as well. Since this would beak config file compability (if someone actually needs a '#' somewhere in the config file that is not on the beginning of line (s)he would have to escape it) it will have to wait until after 2.6 is realeased. I don't think that's a good idea at all. People who think that fvwm syntax is shell syntax are going to have a problem anyway. Fvwm's command line parser is undoubtedly strange, and I always had a vague plan to clean up parsing and command syntax radically in 3.0. It would be nice to have a real parser, maybe leveraged from zsh. Worrying just about comment syntax won't take us anywhere. Thoughts? One thing that probably can be done now, without to mush effort would be to add a warning for unconsumed non-whitespace characters following style options. It would also trap missing commas. Yes, that wouldn't hurt. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Menu Title patch
On Wed, Feb 15, 2006 at 09:46:45AM +0100, Viktor Griph wrote: On Wed, 15 Feb 2006, Dominik Vogt wrote: On Wed, Feb 15, 2006 at 09:25:11AM +0100, Viktor Griph wrote: On Wed, 15 Feb 2006, Dominik Vogt wrote: On Tue, Feb 14, 2006 at 07:27:55PM +0100, Viktor Griph wrote: On Thu, 9 Feb 2006, Dominik Vogt wrote: I have applied the patch with some changes and bugfixes: * The text of the menuitem is always drawn in the given colour set (this required a bugfix in the text drawing library). I don't think this should be done if no colorset is specified for the title. In that case I belive it should use the color of the normal items, or old configs using other color than black will get a black title color. That's exactly what I said (or maybe wanted to say). Currently: * No TitleColorset given - normal item colours are used. * TitleColorset given - foreground of cs is used. * TitleColorset and HilightTitleBack given - foreground and background of cs ase used. In that case it's not working, because I don't have a TitleColorset, and my menu title is black, while the rest of the items are khaki. Works perfectly for me. Can you post an example config that shows the problem? Just the following is ennough: Colorset 0 fg khaki,bg rgb:dd/00/00 MenuStyle * MenuColorset 0 Fixed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS domivogt: * Committed UnderMousePlacement patch.
On Sat, Feb 11, 2006 at 04:21:43PM +, Mikhael Goikhman wrote: On 11 Feb 2006 09:50:34 -0600, FVWM CVS (Dominik) wrote: * Committed UnderMousePlacement patch. Will we apply new patches without any discussion now? :) ;-) Sometimes I just have to do some work on new features so that I don't lose motivation completely. I'd love to see 2.6 out the door, but I can't help much pushing the process. I think this patch was better (both the name and the functionality): Hm, I linke UnderMousePlacement more than UnderCursorPlacement. http://www.mail-archive.com/fvwm-workers@hpc.uh.edu/msg05522.html Except that I would use short instead of int in the style struct. And I am not sure whether a window should be forced fully on screen. It should. Window position is quite random with UnderMousePlacement; it wouldn't drive the user mad to have the window title off screen constantly. I don't know when I'll get around looking at the other patch, but I'm open to any improvements. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Module.h bug and sugestion
On Fri, Feb 10, 2006 at 11:37:51PM +, seventh guardian wrote: On 2/10/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Fri, Feb 10, 2006 at 05:03:09PM +, seventh guardian wrote: I happende to step on this when I was trying the wiki: DV What about the future? Well, the work for the next stable series DV (2.6.x) is proceeding very well. Fvwm will go into feature freeze DV again near the end of the year so that 2.6 is ready before fvwm's DV tenth birthday on 1st of June, 2003. I have vague plans for a DV big event on that day to remind people that fvwm is still there DV and that it can easily compete with any other window manager. DV After that there are plans for a version 3.0 that would change a DV lot of the syntax and introduce fantastic new features, but that's DV too far from now. It has been a long time, and there are no major bugs now. Can we proceed to the next level? It's just a matter of doing the tedious work, and it looks like nobody has the time to do it right now. We have a todo-2.6 that lists all the open issues, but that is several years old and needs updating. Here goes the 3rd patch (maybe the last), for the work I've done until yesterday. I will put this project on hold now, and see if I can help bringing 2.6 to life. Applied. Please try to list *every* function changed. I know it has become a custom to omit that lately (especially under modules/), but it has often saved me lots of work. I've even added a ChangeLog script for vim to the utils/ directory, so there is no excuse not to do this for vim, emacs and xemacs users. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Patch: placing new windows under cursor position
On Sat, Feb 11, 2006 at 01:14:57PM +0100, Arwed von Merkatz wrote: giving it another try to get this patch applied :) It adds a new placement mode 'UnderMousePlacement' to fvwm, placing new windows centered under the current cursor position. I've been using this for over a year now without problems. I've committed it to CVS with a couple of changes: * Re-indented code. * Check the return code of FQueryPointer. Otherwise the window may end up in a random location (when the pointer is on a different screen). Also, please supply ChengeLog entries for any future patches (including the names of any functiont that have been changed). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Simulate button press in FvwmButtons, try 2
On Fri, Feb 10, 2006 at 11:37:29AM +0300, George 'Nephrite' Potapov wrote:
Looks like Mikhael committed cleaned up version of FvwmButtons so I'm
resubmitting my patch for button press simulation. I cleaned the code up as
requested.
I have committed the patch. Some random comments, but nothing
really important.
* The patch to the Loop() function did not apply to current CVS,
but it was easy to fix.
* You changed the wrong ChangeLog. There is a modules/ChangeLog
file too.
* The mousebutton variable was used uninitialized if
GetQuotedString returned NULL.
* The text length in the NEWS file is limited to 66 characters
(Just stop before the text exceeds the length of the dashed
lines).
* It would be nice to include the funtion names in ChangeLog
entries too. That helps a lot to find out when some bug
appeared. It was pretty easy to do manually with yout patch.
+ rest = GetQuotedString(rest, buttonn, , NULL, NULL, NULL);
+ if (buttonn)
+ {
+ mousebutton = atoi(buttonn);
+ free(buttonn);
+ }
else
{
mousebutton = 1;
}
+ if (mousebutton= 0 ||
+ mousebutton NUMBER_OF_EXTENDED_MOUSE_BUTTONS)
+ mousebutton = 1;
...
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: Simulate button press in FvwmButtons, try 2
On Fri, Feb 10, 2006 at 01:29:18PM +0100, Dominik Vogt wrote: * The patch to the Loop() function did not apply to current CVS, but it was easy to fix. Oops, I just forgot to update from CVS first. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Module.h bug and sugestion
On Fri, Feb 10, 2006 at 05:03:09PM +, seventh guardian wrote: I happende to step on this when I was trying the wiki: DV What about the future? Well, the work for the next stable series DV (2.6.x) is proceeding very well. Fvwm will go into feature freeze DV again near the end of the year so that 2.6 is ready before fvwm's DV tenth birthday on 1st of June, 2003. I have vague plans for a DV big event on that day to remind people that fvwm is still there DV and that it can easily compete with any other window manager. DV After that there are plans for a version 3.0 that would change a DV lot of the syntax and introduce fantastic new features, but that's DV too far from now. It has been a long time, and there are no major bugs now. Can we proceed to the next level? It's just a matter of doing the tedious work, and it looks like nobody has the time to do it right now. We have a todo-2.6 that lists all the open issues, but that is several years old and needs updating. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: todo-2.6: E6 - rename FvwmProxy
On Fri, Feb 10, 2006 at 08:10:33PM +, Mikhael Goikhman wrote: On 10 Feb 2006 18:06:55 +, Thomas Adam wrote: On Fri, Feb 10, 2006 at 05:45:21PM +, seventh guardian wrote: Anyway, on that list there's the entry E6, saying FvwmProxy should be renamed. I agree, and suggest FvwmWinTag. I'm indifferent. Proxy makes sense to me in this case -- they're proxy windows that are bound to the current windows on the screen. A name like FvwmWindowLabels or FvwmProxyWindows makes even more sense. Please everyone who cares vote: http://fvwm.lair.be/viewtopic.php?t=1202 Although I don't want any more modules that begine with FvwmWin, FvwmWindowLabels is a good name. I'd even vote if the confirmation email for registering on the forum ever arrives (probably never). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Menu Title patch
On Sat, Feb 04, 2006 at 08:51:33PM +, David Maciver wrote: On Sat, 21 Jan 2006 04:17:43 +, David Maciver wrote: Hello, I've written a patch that lets you configure the menu title and colorset separately from the rest of the menu. I've added menustyle options HilightTitle, TitleColorset and TitleFont. Here is an example of what it looks like: http://metawire.org/~frogb/menu2.png Patch against CVS: http://metawire.org/~frogb/menutitle.patch Could this be included in fvwm? This sort of configuration seems quite popular in other window managers. It was originally posted on the fvwm forum[1] where people seem to want it. It seems to work ok for me but is there anything that should be changed/fixed in the code, or any reason this cannot be accepted? [1] http://fvwm.lair.be/viewtopic.php?t=1141 I have applied the patch with some changes and bugfixes: * The text of the menuitem is always drawn in the given colour set (this required a bugfix in the text drawing library). * Renamed the HilightTitle option to HilightTitleBack. It just controls whether the background of the title is hilighted. * Corrected the calculations of the area to hilight. Now it always hilights the whole title, not just the area with the relief on menu items (which can be smaller if the ItemFormat style is used). For future patches, please include * NEWS entries for new features and bugfixes. * Documentation in the man page (fvwm.1.in). * ChangeLog entries including the names of all files and functions changed and a short comment. * Optionally an entry for the AUTHORS file. This cuts down the time I spend to handle patches a lot because if you don't write it, I have to do it (which is much more work because I have to learn everything from the code first). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Module.h bug and sugestion
On Thu, Feb 09, 2006 at 03:32:44PM +, seventh guardian wrote: On 2/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Wed, Feb 08, 2006 at 02:05:14PM +, seventh guardian wrote: I've committed the patch to CVS (and removed the FARGS macro from FvwmConsole). For further patches, please always add a list of modified functions to the ChangeLog after the name of the .c file. This simplifies maintenance enormously. Here goes a second patch. I've added the list of modified functions after the file name, except for the main function. I followed the style of some of your entries in the changelogs, hope I've done it ok. Actually, its not my personal style but what xemacs (and emacs?) generate when you move the cursor into a function and the press ctrl-x 4 a. (Unfortunately more recent versions of xemacs changed the style of the function list which makes it more difficult to grep through it. As you said once, the command line syntax isn't going to change that much, even for 3.0. But even so, some coding styles make it difficult to use properly the ParseModuleArgs (or functions alike) regarding the module aliases. I wonder if there could be fixed a standard for aliases. I mean a true standard that modules using aliases should follow. The argv[6] rule would be ok, but it would break some config files. Obviosly some kind of wrapper could be used to avoid those breakings, like in FvwmRearrange. I wonder what you think about this. The one problem with that approach is that such a change would break all third-party modules. Without a proper standard, some modules using ParseModuleArgs won't be as clean as they should be. I'm skipping them for now, wainting for a definite solution. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Module.h bug and sugestion
On Thu, Feb 09, 2006 at 04:08:00PM +, seventh guardian wrote: On 2/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Thu, Feb 09, 2006 at 03:32:44PM +, seventh guardian wrote: On 2/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Wed, Feb 08, 2006 at 02:05:14PM +, seventh guardian wrote: I've committed the patch to CVS (and removed the FARGS macro from FvwmConsole). For further patches, please always add a list of modified functions to the ChangeLog after the name of the .c file. This simplifies maintenance enormously. Here goes a second patch. I've added the list of modified functions after the file name, except for the main function. I followed the style of some of your entries in the changelogs, hope I've done it ok. Actually, its not my personal style but what xemacs (and emacs?) generate when you move the cursor into a function and the press ctrl-x 4 a. (Unfortunately more recent versions of xemacs changed the style of the function list which makes it more difficult to grep through it. As you said once, the command line syntax isn't going to change that much, even for 3.0. But even so, some coding styles make it difficult to use properly the ParseModuleArgs (or functions alike) regarding the module aliases. I wonder if there could be fixed a standard for aliases. I mean a true standard that modules using aliases should follow. The argv[6] rule would be ok, but it would break some config files. Obviosly some kind of wrapper could be used to avoid those breakings, like in FvwmRearrange. I wonder what you think about this. The one problem with that approach is that such a change would break all third-party modules. Hum, you're right. What about making the change only for official modules, those using Module.h? Hm, what about passing the module alias as an environment variable? It's ugly, but we're already doing it with FVWM_VISUALID and FVWM_COLORMAP. An FVWM_MODULE_ALIAS wouldn't do further harm. However, this doesn't solve the syntax issue on the fvwm side. What can we do about invocations like FvwmButtons ColourTable (right from my config file)? Okay, let's see how big the mess is: 1) Modules that currently support the syntax modulename [alias] without further command line args: Animate, CommandS, Form, Gtk, IconBox, TaskBar 2) Modules which do not accept any command line options, icluding aliases: Backer, DragWell, Ident, Proxy, Save, SaveDesk, Scroll, Theme, Wharf 3) Modules which do not have any config lines: Auto, Save, SaveDesk 4) Modules which only accept command line options beginning with '-': Console, Debug, GtkDebug, Rearrange, Tabs 5) Modules which accept a list of '-' options followed by a single argument that does not begin with '-' (and is not an alias): Cpp, M4 6) Modules that accept a single non-alias argument: Banner, Script 7) Weird cases: * Buttons Possible arguments are ['-'options] [alias] [cfgfile] Iterates over its arguments. For each argument it checks if it's an option with '-' first. If not (or the same option was encountered earlier), it's taken as the alias. If the alias is already define, it's taken as the cfgfile. If the cfgfile is already defined, it's ignored. YUCK! * OldDebug Can be invoked as one of OldDebug OldDebug alias OldDebug -v OldDebug -v alias OldDebug alias -v YUCK! * Event Can be invoked as one of Event Event -audio Event alias * IconMan Can be invoked as IconMan IconMan alias IconMan transient IconMan -transient IconMan transient alias IconMan -transient alias * Pager Same as IconMan, but may be followed by one or two desk numbers or asterisks. * Perl Can be invoked as Perl ['-'options] [alias] * WindowMenu Takes options without a '-' prefix but no alias. * WindowList Same as IconMan. Classes (2) and (3) are no problem at all while (1), (4) and (5) are relatively easy to cope with. Class (6) modules are broken at the moment, i.e. it's not possible to kill them with KillModule Modulename because their argument is interpreted as an alias name. WindowMenu, Tabs and Perl are new in 2.5.x, so we can change their interface without worrying about incompatibilities. Event and Perl have the alias name at the end of their option Any ideas for a clean interface that breaks only configs that are really weird? I don't know if third party modules use Module.h, but they will break anyway if that file changes.. Module.h is not part of the external interface, so we don't need to care about modules using it. Without a proper standard, some modules using ParseModuleArgs won't be as clean as they should be. I'm skipping them for now, wainting
Re: Module.h bug and sugestion
On Thu, Feb 09, 2006 at 11:25:42PM +, seventh guardian wrote: On 2/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Thu, Feb 09, 2006 at 04:08:00PM +, seventh guardian wrote: On 2/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Thu, Feb 09, 2006 at 03:32:44PM +, seventh guardian wrote: [snip] As you said once, the command line syntax isn't going to change that much, even for 3.0. But even so, some coding styles make it difficult to use properly the ParseModuleArgs (or functions alike) regarding the module aliases. I wonder if there could be fixed a standard for aliases. I mean a true standard that modules using aliases should follow. The argv[6] rule would be ok, but it would break some config files. Obviosly some kind of wrapper could be used to avoid those breakings, like in FvwmRearrange. I wonder what you think about this. The one problem with that approach is that such a change would break all third-party modules. Hum, you're right. What about making the change only for official modules, those using Module.h? Hm, what about passing the module alias as an environment variable? It's ugly, but we're already doing it with FVWM_VISUALID and FVWM_COLORMAP. An FVWM_MODULE_ALIAS wouldn't do further harm. Do you mean something like Module ALIAS=mypager FvwmPager ? No, I don't know how to handle the command line yet, but maybe FvwmPager --alias foobar ... which would be recognized and handled by the fvwm core, or perhaps a separate ModuleAlias command, but that might be confusing, as many people don't use the Module command at all. But that was not my point. I was talking about a way to pass the alias to the module without putting it on the command line args of the module. The envvar allows to provide the module with an alias without disturbing its command line. Using an evironment var for the alias would break third party modules, unless we also provide it via command args. No, it wouldn't because aliases are not an official part of the module interface, as far as I know. The module classes (1) to (6) could easily be adapted to that logic without touching the way they interpret their arguments. Even discarding that, wouldn't it need major changes in the way fvwm interprets the config file? However, this doesn't solve the syntax issue on the fvwm side. What can we do about invocations like FvwmButtons ColourTable (right from my config file)? Okay, let's see how big the mess is: 1) Modules that currently support the syntax modulename [alias] without further command line args: Animate, CommandS, Form, Gtk, IconBox, TaskBar 2) Modules which do not accept any command line options, icluding aliases: Backer, DragWell, Ident, Proxy, Save, SaveDesk, Scroll, Theme, Wharf 3) Modules which do not have any config lines: Auto, Save, SaveDesk 4) Modules which only accept command line options beginning with '-': Console, Debug, GtkDebug, Rearrange, Tabs 5) Modules which accept a list of '-' options followed by a single argument that does not begin with '-' (and is not an alias): Cpp, M4 6) Modules that accept a single non-alias argument: Banner, Script 7) Weird cases: * Buttons Possible arguments are ['-'options] [alias] [cfgfile] Iterates over its arguments. For each argument it checks if it's an option with '-' first. If not (or the same option was encountered earlier), it's taken as the alias. If the alias is already define, it's taken as the cfgfile. If the cfgfile is already defined, it's ignored. YUCK! Mikhael is going to clean this one up. Maybe it could be redesigned, who knows? The question is: Does anyone rely on that strange parsing rules? * OldDebug Can be invoked as one of OldDebug OldDebug alias OldDebug -v OldDebug -v alias OldDebug alias -v YUCK! OldDebug doesn't even compile anymore, and no one complained. I believe it may be removed from the building tree.. Fine. * Event Can be invoked as one of Event Event -audio Event alias Is the -audio option used at all? Yes! FvwmEvent is installed as FvwmEvent and symlinked as FvwmAudio. I believe not, but I may be wrong.. Even so, it only supports only either -audio or an alias, so I believe it's broken. As a side note, the module does two distinct things, so shouldn't it be splitt up into FvwmEvent and FvwmAudio? Is the Audio part used anyway? The -audio option and invoking it as FvwmAudio is the result or merging the old FvwmAudio module back into FvwmEvent. It was once split from FvwmEvent (I think) and shared most of the code. Probably FvwmAudio did not support module aliases, so there is no mode to have both
Re: Module.h bug and sugestion
On Fri, Feb 10, 2006 at 01:19:26AM +, seventh guardian wrote: Then we have two options: - Modules don't pass a matching string to fvwm and fvwm is entirely responsible of the module's aliases. - Modules continue to pass the matching string and fvwm translates it if an alias is defined in the core. Hm, would that break the old way FvwmIconMan requested its config liens? I mean *FvwmIconMan*1*foobar ... Instead of the new *FvwmIconMan: 1 foobar ... Or is that completely transparent to the modules? Mikhael? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Simulate button press in FvwmButtons
On Wed, Feb 08, 2006 at 05:22:29PM +0300, George Nephrite Potapov wrote:
On Wed, Feb 08, 2006 at 05:11:48PM +0300, George Nephrite Potapov wrote:
I'm very sorry but there was a small error in my previous message with patch.
Here is the correct one. I'm very very sorry.
Thats a nice patch with an important feature.
I have some minor change requests though:
1) Please supply ChangeLog and NEWS entries for the patch (and
optionally an AUTHORS entry).
2)
+static int buttons[] =
+{
+0, Button1, Button2, Button3, Button4, Button5, NULL
+};
I think there shouldn't be a NULL pointer at the end of an int
array.
Please do not hard-code the number of mouse buttons. The macro
NUMBER_OF_MOUSE_BUTTONS in libs/defaults.h defines how many
buttons are handled by fvwm.
+rest = GetQuotedString(
+rest, buttonn, , NULL, NULL, NULL);
+if (buttonn) {
+mousebutton = atoi(buttonn);
+
+free(buttonn);
+}
+if (!mousebutton) {
+mousebutton = 1;
+}
+
+CurrentButton = b;
+act = GetButtonAction(b, buttons[mousebutton]);
This reads past the end or beginning of the array if the user
requests a button 0 or 5. And because Button1 == 1, ...,
Button5 == 5 you can as well just write
if (mousebutton = 0 ||
mousebutton NUMBER_OF_EXTENDED_MOUSE_BUTTONS)
{
mousebutton = 1;
}
/*...*/
act = GetButtonAction(b, mousebutton);
and remove the buttons[] array.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: argb visual patch against recent cvs
On Wed, Feb 01, 2006 at 04:45:29AM +0100, Marc Lehmann wrote:
Hi!
The new argb visuals introduced by xorg have a serious drawback, namely,
they don't work correctly unless the toplevel window has an ARGB visual.
With my limited knowledge, I'd say this is a design problem within Xorg, but
I seem to be alone with that notion. This means that each and every window
manager needs special support just to support ARGB in client windows.
Here is a small patch I wrote that implements such support for fvwm:
http://data.plan9.de/fvwm-2.5-argb-visual.patch
Small to medium sized patches can be sent directly to the mailing
list. That makes life for us much easier:
Index: fvwm/add_window.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.c,v
retrieving revision 1.374
diff -u -p -r1.374 add_window.c
--- fvwm/add_window.c 29 Jan 2006 09:57:18 - 1.374
+++ fvwm/add_window.c 1 Feb 2006 15:17:11 -
@@ -782,9 +782,31 @@ static void setup_frame_window(
FvwmWindow *fw)
{
XSetWindowAttributes attributes;
- int valuemask;
+ int valuemask = CWBackingStore | CWBackPixmap | CWEventMask |
CWSaveUnder | CWCursor;
+int depth;
+Visual *visual;
+
+/*
+ * We assume that a truecolour visual of depth 32 is
+ * actually an ARGB visual (hard to detect otherwise)
+ * in this case, clone the window visual/cmap etc.
+ */
+if (fw-attr_backup.visual-class == TrueColor
+ fw-attr_backup.depth == 32)
+ {
+depth = fw-attr_backup.depth;
+visual = fw-attr_backup.visual;
+attributes.colormap = fw-attr_backup.colormap;
+attributes.background_pixel = -1;
+attributes.border_pixel = -1;
+valuemask |= CWColormap | CWBackPixel | CWBorderPixel;
+ }
+else
+ {
+depth = CopyFromParent;
+visual = CopyFromParent;
+ }
- valuemask = CWBackingStore | CWBackPixmap | CWEventMask | CWSaveUnder;
attributes.backing_store = NotUseful;
attributes.background_pixmap = None;
attributes.cursor = Scr.FvwmCursors[CRS_DEFAULT];
@@ -793,8 +815,8 @@ static void setup_frame_window(
/* create the frame window, child of root, grandparent of client */
FW_W_FRAME(fw) = XCreateWindow(
dpy, Scr.Root, fw-frame_g.x, fw-frame_g.y,
- fw-frame_g.width, fw-frame_g.height, 0, CopyFromParent,
- InputOutput, CopyFromParent, valuemask | CWCursor, attributes);
+ fw-frame_g.width, fw-frame_g.height, 0, depth,
+ InputOutput, visual, valuemask, attributes);
XSaveContext(dpy, FW_W(fw), FvwmContext, (caddr_t) fw);
XSaveContext(dpy, FW_W_FRAME(fw), FvwmContext, (caddr_t) fw);
What it does is simply check wether the client window has an ARGB visual
and, if yes, creates the frame window in the same visual. Nothing else
should be changed by this patch.
The only relevant problem I see is the detecting part, as xlib gives no
indication about alpha channels (would need to use XRender just for that),
so it assumes that 32 bit TrueColour means there is an alpha channel (one
could check bits_per_rgb or so to be = 8, which means something weird is
certainly going on, as 3*8 leave s8 bits unaccounted for).
The other small uncleanlieness is the hardwired -1 for the pixel values,
but that should hardly create any problems (all bits set boil down to
opaque white - its not visible anyways, and is guarenteed to exist in such
visuals).
But doesn't this change break normal (non-ARGS) 32 bit TrueColor
visuals?
I was not sure what to do with the patch, I wrote it mainly for testing
some things (not being a transparency geek myself), so I thought I'd send
it to you to decide what to do with it :)
Thanks for your attention, and thanks for maintaining fvwm2 :)
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: Module.h bug and sugestion
On Thu, Feb 02, 2006 at 10:57:43AM +, seventh guardian wrote:
On 2/2/06, Dominik Vogt [EMAIL PROTECTED] wrote:
On Wed, Feb 01, 2006 at 02:58:27PM +, seventh guardian wrote:
Hi.
First of all, there's a minor bug in libs/Module.h: the funcion
SendFinishedStartupNotification() is declared twice (on lines 147 and
166).
With that asside, I'm writing a module for Fvwm to support the xorg's
Xevie extension. I really don't like to reinvent the wheel, so I'm
creating it inside the building tree, using Module.h and other helping
libs. (that's the reason why I found that bug).
I also found that there's a nice parsing function which is rarely used
by any of the other modules, ParseModuleArgs().
Actually it is not used at all.
It returns a struct
with the module args, including the two communication pipes. The
problem here is that the structure itself is strange to use, because
the other all the other functions genericaly require a pipe array,
fd*, with the first element as transmit pipe and the other as a
receive. So there are two alternatives here.
Um, I can't think of any function that needs a pipe array in any
module or the module library. Can you give examples?
void GetConfigLine(int *fd, char **tline)
{
(.)
SendText(fd, Send_ConfigInfo, 0);
(.)
packet = ReadFvwmPacket(fd[1]);
}
Very well. Note that fd[0] is the write pipe and fd[1] is the
read pipe - unlike in an array created with pipe() where fd[0] is
the read pipe and fd[1] is the write pipe. See the comments below.
Either to ALLWAYS pass
them the to_fvwm pipe, which works because of their order in the
struct (but makes the code a little cryptic, like Receive(to_fvwm)),
There is no guarantee that this works.
or to copy them to an array fd[2], which uses twice as much memory
(not a real problem most of the times, but definitelly a bug).
With that said, my suggestion is this: to use a struct to store the
interface data (file descriptors, name, etc) and to make the functions
use that struct instead of the particular elements.
But ParseModuleArgs already allows this. It parses the module
arguments and passes back a structure that contains the number and
an array of options not yet parsed. It's easy to write more
parsing functions with this information, but it's actually not a
very good idea because modules should be configured by the config
file, not the command line (with some exceptions).
Yes, I know. But now functions rely on having two pipes and read/write
on them in a raw way. Having a proper (more complete) struct and
functions to work with it would make the code actually independent of
the real interface. Modules could communicate by TCP/IP and the module
wouldn't notice it at all (hum can't see the advantage of that, but I
guess you got my point).
Actually I'm quite unhappy with the pipe-approach because of its
shortcomings (limited size of data that can be transmitted), but
changing that would be a major effort.
That way more
helper functions would come up, such as a function that requests the
config info and calls a user defined parsing function to handle the
lines as they come up. Or a function to wait on the pipe for packets
and also passing them to a user defined parsing function. Having a
struct instead of scatered global vars makes that task easyer, as they
are all passed at once inside the struct.
Also, that way if someday (fvwm 3 maybe?) the module interface
changes, the modules themseves woudn't need to change that much.
The module packet interface changes once in a while, but I don't
see the command line changing anytime soon.
It
woudn't be that difficult to change the current modules to use the new
functions. Besides, all already compiled modules would work without
any change, and unofficial ones would compile perfectly as long as
they don't use the new Module.h. Also there could be an adaptation
time where both libs were supplied..
Those were my thoughts. Please comment..
Streamlining the module interface code is definitely worthwhile.
It's just that there are so many modules and so much work to do.
The first step would be to just *use* ParseModuleArguments
everywhere (without breaking all the existing code). Any further
changes can be made after that. I'm open to any patches.
Ok, I was suggesting to improve ParseModuleArguments before that, but
I believe I can do it. Of course there's got to be a change in that
example function (above) and maybe others..
So, the work can be split into several smaller steps:
1. Make all the modules use ParseModuleArgs() and copy the fds
from the ModuleArgs struct to the arrays that are currently
used by the modules.
2. Remove the fd arrays in the modules and use the fds in the
ModuleArgs instead.
3. Make the service
Re: argb visual patch against recent cvs
On Thu, Feb 02, 2006 at 01:42:44PM +0100, Marc Lehmann wrote: On Thu, Feb 02, 2006 at 09:11:40AM +0100, Dominik Vogt [EMAIL PROTECTED] wrote: http://data.plan9.de/fvwm-2.5-argb-visual.patch Small to medium sized patches can be sent directly to the mailing list. That makes life for us much easier: Will do next time. The other small uncleanlieness is the hardwired -1 for the pixel values, but that should hardly create any problems (all bits set boil down to opaque white - its not visible anyways, and is guarenteed to exist in such visuals). But doesn't this change break normal (non-ARGS) 32 bit TrueColor visuals? Sure, but is there reason to believe such weird beasts exist? I don't see anything that forbids it. Even if no X Server implements them, there may be future extensions in servers other than X.org that misuse the depth (break the specs?) for similar or other reasons. We should at least check that the X server supports the ARGB extension (with XQueryExtension) before making assumptions about interpreting the depth in such a peculiar way. This would be done somewhere in the startup code (fvwm.c). One could improve the test by checking wether all masks or'ed together are less than 32 bit. However, I just had a look at xlib, and it detects argb visuals simply by comparing the depth against 32 (without any further tests, even): if (dp-depth == 32 getenv (XLIB_SKIP_ARGB_VISUALS)) So this seems to be the expected way to detect those visuals at the moment. Is there any documentation about how to detect ARGB? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: argb visual patch against recent cvs
On Thu, Feb 02, 2006 at 01:42:44PM +0100, Marc Lehmann wrote: On Thu, Feb 02, 2006 at 09:11:40AM +0100, Dominik Vogt [EMAIL PROTECTED] wrote: http://data.plan9.de/fvwm-2.5-argb-visual.patch Small to medium sized patches can be sent directly to the mailing list. That makes life for us much easier: Will do next time. The other small uncleanlieness is the hardwired -1 for the pixel values, but that should hardly create any problems (all bits set boil down to opaque white - its not visible anyways, and is guarenteed to exist in such visuals). But doesn't this change break normal (non-ARGS) 32 bit TrueColor visuals? Sure, but is there reason to believe such weird beasts exist? One could improve the test by checking wether all masks or'ed together are less than 32 bit. However, I just had a look at xlib, and it detects argb visuals simply by comparing the depth against 32 (without any further tests, even): if (dp-depth == 32 getenv (XLIB_SKIP_ARGB_VISUALS)) So this seems to be the expected way to detect those visuals at the moment. Thinking more about the whole issue I come to the conclusion that the ARGB extension is simply broken if it cannot handle the CopyFromParent depth and visual. Is there any reason why one should have to do that manually? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Module.h bug and sugestion
On Wed, Feb 01, 2006 at 02:58:27PM +, seventh guardian wrote: Hi. First of all, there's a minor bug in libs/Module.h: the funcion SendFinishedStartupNotification() is declared twice (on lines 147 and 166). With that asside, I'm writing a module for Fvwm to support the xorg's Xevie extension. I really don't like to reinvent the wheel, so I'm creating it inside the building tree, using Module.h and other helping libs. (that's the reason why I found that bug). I also found that there's a nice parsing function which is rarely used by any of the other modules, ParseModuleArgs(). Actually it is not used at all. It returns a struct with the module args, including the two communication pipes. The problem here is that the structure itself is strange to use, because the other all the other functions genericaly require a pipe array, fd*, with the first element as transmit pipe and the other as a receive. So there are two alternatives here. Um, I can't think of any function that needs a pipe array in any module or the module library. Can you give examples? Either to ALLWAYS pass them the to_fvwm pipe, which works because of their order in the struct (but makes the code a little cryptic, like Receive(to_fvwm)), There is no guarantee that this works. or to copy them to an array fd[2], which uses twice as much memory (not a real problem most of the times, but definitelly a bug). With that said, my suggestion is this: to use a struct to store the interface data (file descriptors, name, etc) and to make the functions use that struct instead of the particular elements. But ParseModuleArgs already allows this. It parses the module arguments and passes back a structure that contains the number and an array of options not yet parsed. It's easy to write more parsing functions with this information, but it's actually not a very good idea because modules should be configured by the config file, not the command line (with some exceptions). That way more helper functions would come up, such as a function that requests the config info and calls a user defined parsing function to handle the lines as they come up. Or a function to wait on the pipe for packets and also passing them to a user defined parsing function. Having a struct instead of scatered global vars makes that task easyer, as they are all passed at once inside the struct. Also, that way if someday (fvwm 3 maybe?) the module interface changes, the modules themseves woudn't need to change that much. The module packet interface changes once in a while, but I don't see the command line changing anytime soon. It woudn't be that difficult to change the current modules to use the new functions. Besides, all already compiled modules would work without any change, and unofficial ones would compile perfectly as long as they don't use the new Module.h. Also there could be an adaptation time where both libs were supplied.. Those were my thoughts. Please comment.. Streamlining the module interface code is definitely worthwhile. It's just that there are so many modules and so much work to do. The first step would be to just *use* ParseModuleArguments everywhere (without breaking all the existing code). Any further changes can be made after that. I'm open to any patches. PS: there's a real bug on top of all this text ;) Hint: Write two mails for two different topics to minimize the risk the bad issue is forgotten. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FvwmIconBox Png Format
On Sun, Jan 29, 2006 at 01:50:40AM -0200, big-di wrote: FvwmIconBox seems to not support png files. I've tried many different ways, and, whatever the reason is, it always falls back to the standard window icon. I've tried setting the Icon on Style, but then the icon on FvwmIconBox is omitted. When set from FvwmIconBox itself the icon isnt loaded (standard takes place). I may have done smth wrong, but i believe this is a bug. First, check whether fvwm has png support sompiled in: $ fvwm --version It should list PNG in the with support for: line. If not, fvwm was not compiled with PNG-Support. If PNGs work in other parts of fvwm or other modules, there is a configuration problem with your FvwmIconBox. If not you have a general configuration problem with fvwm. If you post your FvwmIconBox config to the list along with all other Style lines that affect icons and your ImagePath/PixmapPath..., we will take a look. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: fvwm starts when other window manager is already activeOrganization:
On Sat, Jan 28, 2006 at 05:47:34PM +0100, Viktor Griph wrote:
On Sat, 28 Jan 2006, Dominik Vogt wrote:
On Sat, Jan 28, 2006 at 02:20:13PM +0100, Viktor Griph wrote:
On Thu, 22 Sep 2005, Manoj Srivastava wrote:
[snip]
are unable to detect other window managers.(Tested with ratpoison and
woody's icewm, sarge's icewm, icewm-gnome, wm2, qvwm and
enlightment. Also fluxbox, blackbox, ion3, xfwm4, wmaker and twm,
making this almost every other window manager other than fvwm
itself).
[anip]
I've done some tests and belive that this bug is due to a change in X with
XOrg 6.8. I've tested fvwm 2.5.16, 2.5.10 and 2.5.4 from the 2.5.x branch,
and all have the bug. However I'm sure that the bug was not present when I
used 2.5.4 (and probably not 2.5.10) actively. Thus it must be something
else that has changed since then. The bug is however not present in
2.4.19, so it must be soemthing that has changed in the early 2.5.x
versions, which I weren't able to compile now.
No, the only change since at least 2.3.0 was introducing the
-replace option. We haven't touched this code in *ages*.
Have you not?
You're right. I was under the impression we were talking about
the code that detects ICCCM2 compliant window managers because of
the sheer size of the window manager list. It looks like nobody
bothers to set the corresponding property in any window manager.
$ cvs log -r1.290 -N fvwm.c
revision 1.290
date: 2002/03/17 17:34:15; author: domivogt; state: Exp; lines: +7 -10
* Replaced Xsync with XFlush almost everywhere. Note: it's rarely
necessary to use XSync. XFlush usually suffices and is faster.
* More work on frame layout.
* Some general clean up.
The relevant part of the cvs diff -r 1.289 -r 1.290 fvwm.c:
Index: fvwm.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/fvwm.c,v
retrieving revision 1.289
retrieving revision 1.290
diff -u -r1.289 -r1.290
--- fvwm.c 15 Mar 2002 17:02:25 - 1.289
+++ fvwm.c 17 Mar 2002 17:34:15 - 1.290
@@ -557,21 +559,21 @@
CWEventMask | CWOverrideRedirect |
CWColormap
| CWBackPixmap | CWBorderPixel,
attributes);
XMapWindow(dpy, Scr.NoFocusWin);
-
SetMWM_INFO(Scr.NoFocusWin);
FOCUS_SET(Scr.NoFocusWin);
- XSync(dpy, 0);
+ frame_init();
+ XFlush(dpy);
if(debugging)
{
sync_server(1);
}
- SetupICCCM2 (replace_wm);
+ SetupICCCM2(replace_wm);
XSetErrorHandler(CatchRedirectError);
XSetIOErrorHandler(CatchFatal);
XSelectInput(dpy, Scr.Root, XEVMASK_ROOTW);
- XSync(dpy, 0);
+ XFlush(dpy);
XSetErrorHandler(FvwmErrorHandler);
I think that last XSync really should be there since, if I understand the
test correctly it relies on an error to be generated if a window manager
already exists, and XSync does wait until all requests are processed, and
the errors handled, but XFlush just flushes the output buffer.
Actually an error *is* generated, but it is processed by the wrong
error handler (i.e. by FvwmErrorHandler). It's not enough to put
an XSync after XSelect input, there should also be one *before*
XSetErrorHandler to prevent that other errors are mistaken as a
clue that another wm is running. I'll commit a patch.
I guess
it's up to the threadin model of the X-server weather or not any errors
generated by recently flushed requests are handled before or after the
request to change error handler to FvwmErrorHandler is processed.
No, not at all. XSetErrorHandler is processed locally in Xlib
without any protocol requests to the X server, so only the kernel
scheduling algorithm has some influence on this.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: fvwm starts when other window manager is already activeOrganization:
On Sat, Jan 28, 2006 at 02:20:13PM +0100, Viktor Griph wrote: On Thu, 22 Sep 2005, Manoj Srivastava wrote: Hi, [Please retain the CC to [EMAIL PROTECTED] so that the Debian BTS has a record of your input] This was reported by a Debian user. Recent versions of fvwm, while being able to detect other versions of fvwm currently running: -- __ fvwm [FVWM][SetupICCCM2]: ERROR another ICCCM 2.0 compliant WM is running, try -replace -- are unable to detect other window managers.(Tested with ratpoison and woody's icewm, sarge's icewm, icewm-gnome, wm2, qvwm and enlightment. Also fluxbox, blackbox, ion3, xfwm4, wmaker and twm, making this almost every other window manager other than fvwm itself). Older versions of fvwm used to display this warning: -- [FVWM][CatchRedirectError]: ERROR another WM is running -- But the newer ones do not, for reasons I could not debug. This is a regression, and the other window managers are able to detect fvwm and refuse to run. Please see http://bugs.debian.org/328621 for details. manoj I've done some tests and belive that this bug is due to a change in X with XOrg 6.8. I've tested fvwm 2.5.16, 2.5.10 and 2.5.4 from the 2.5.x branch, and all have the bug. However I'm sure that the bug was not present when I used 2.5.4 (and probably not 2.5.10) actively. Thus it must be something else that has changed since then. The bug is however not present in 2.4.19, so it must be soemthing that has changed in the early 2.5.x versions, which I weren't able to compile now. No, the only change since at least 2.3.0 was introducing the -replace option. We haven't touched this code in *ages*. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: configure is stopped after checking iconv_open
On Fri, Jan 20, 2006 at 03:47:37PM +0900, Kan Sasaki wrote: Hi, FVWM version: 2.5.16 (from cvs) Configure with iconv is stopped after checking iconv_open. When libiconv was found, check for libcharset is called. This is defined in configure.ac line 771 as follows: -- # * libiconv found check for libcharset to get the good iconv charset if test x$with_lib_iconv = xyes; then CHECK_LIBCHARSET fi -- CHECK_LIBCHARSET is defined in acinclude.m4 as follows: -- AC_DEFUN([CHECK_LIBCHARSET],[ exit 77 (snip) -- I guess that staring with 'exit 77' means CHECK_LIBCHARSET always fails. Is this a bug? It's a piece of debug code. Remove it from the file acinclude.m4 and everything works fine. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
fvwm-2.5.16 has been released and uploaded
Tarballs and ANNOUNCE are in the usual place. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: bell on failed grab
On Wed, Jan 18, 2006 at 12:40:14PM +, Tavis Ormandy wrote:
On Wed, Jan 18, 2006 at 12:44:26PM +0100, Dominik Vogt wrote:
On Sun, Jan 15, 2006 at 10:24:01PM +, Tavis Ormandy wrote:
Hello, I would really like to appeal for the removal of the XBell()
at line 1029 in fvwm/functions.c, part of execute_complex_function().
That's fine with me, so if someone makes a patch I'd apply it.
Ciao
Dominik ^_^ ^_^
Great! How about this oneliner
--- functions.c 19 Oct 2005 06:25:18 - 1.270
+++ functions.c 18 Jan 2006 12:37:56 -
@@ -1026,7 +1026,10 @@
if (!GrabEm(CRS_NONE, GRAB_NORMAL))
{
func-use_depth--;
- XBell(dpy, 0);
+ fvwm_msg(ERR,
+ ComplexFunction,
+ Grab failed in function %s, unable to execute immediate
action,
+ action);
__cf_cleanup(depth, arguments, cond_rc);
return;
}
Applied.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: make rpm-dist and deb-dist both fail with the same error
On Sun, Jan 15, 2006 at 09:44:49PM +, Mikhael Goikhman wrote: Just tested. Mere make is broken on the released fvwm-2.5.15 tarballs. Hrmpf, why didn't make distcheck catch this? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: bell on failed grab
On Sun, Jan 15, 2006 at 10:24:01PM +, Tavis Ormandy wrote: Hello, I would really like to appeal for the removal of the XBell() at line 1029 in fvwm/functions.c, part of execute_complex_function(). It doesnt serve any purpose as it is impossible to determine even if it was fvwm that rang the bell, and as no message is printed to stderr to indicate what the bell means there is no way for a user to find out what failed or what function was trying to execute when it failed. Additionally, it really drives me crazy as it makes a lot of the events supported by FvwmEvent totally unusable for me, as some of them may be triggered while the server is grabbed. Replacing the XBell() with a message to stderr stating failed to grab server in function FooBar or similar would be much more helpful to users who want to find out why their configuration isnt working, and much less annoying to users who realise that some commands may fail during a grab but want it anyway :) That's fine with me, so if someone makes a patch I'd apply it. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: MenuStyle ActiveColorset and the need of HilightBack/ActiveFore
On Wed, Jan 18, 2006 at 10:45:08AM +0100, Viktor Griph wrote: On Wed, 18 Jan 2006, Viktor Griph wrote: Hi When using the ActiveColorset menustyle, you also have to specify HiglightBack and/or ActiveFore (without arguments) in order to make the style use the colorset. Just using ActiveAcolorset has no effect what-so-ever. I think it would be good to make ActivColorset imply ST_DO_HILIGHT_FORE and ST_DO_HILIGHT_BACK. I don't think many users use a colorset, of which they only want to use one (or no) color. By leaving the ability to turn off the use of the colors the current behaviour could be restored with a minor addition to a config file. Alternatively one could make ActiveCColorset imply ST_DO_HILIGHT_FORE and ST_DO_HILIGHT_BACK as long as none of those stiles have been used, which would only change behaviour for the few users that have an active colorset not used at the cost of one extra bit per menustyle. Ok, I just realized why HilightBack can't be on by default, so I guess I'll have to withdraw my opinion. Yeah, if I had the chance to write all the menu styles from scratch, I'd do it in a different way. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
fvwm-2.5.15 has been released and uploaded
Tarballs and ANNOUNCE are in the usual place. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS migo: it works well with automake/aclocal-1.4 and 1.5, 1.6, so do not require 1.8
On Sun, Jan 08, 2006 at 12:59:48PM -0600, fvwm-workers wrote: Log message: it works well with automake/aclocal-1.4 and 1.5, 1.6, so do not require 1.8 Actually, requiring 1.8 was an accident. I wanted to upgrade to 1.6. Of course the current code works with 1.4 becuase I did not change anything essential, but in the future I'd like to have the new macros. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
upgraded autotools
I have just upgraded the autotools setup to autoconf-2.53 and automake-1.8. This means you can no longer build the CVS sources with older versions. I hope this does not cause a lot of problems with the feature and library checks, but I'd be grateful if everybody tries the new system and reports the problems. For the developers the most important change is that the acconfig.h file is gone and configure.in was renamed to configure.ac. If there was something like this before: acconfig.h: /* some comment */ #define HAVE_FOOBAR configure.in: if test x$have_foobar = xyes; then AC_DEFINE(HAVE_FOOBAR) fi it becomes configure.ac: AH_TEMPLATE([HAVE_FOOBAR],[some comment]) if test x$have_foobar = xyes; then AC_DEFINE(HAVE_FOOBAR) fi Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: The Style command
On Sun, Jan 01, 2006 at 08:37:28PM +0100, Viktor Griph wrote: While looking at the possible options for implementing a Style setting functionality for window types based on EWMH. I got as deeply into the style code that I decided to give the syntax specification in the 3.0-todo a try. I've got the 'Style (conditions)' syntax working quite well, with the old Style syntax supported by a compability mode. Styles are applied in the order: Golbal (*), (Not completely implemented: ewmh window type), compability layer (not Style * ..., nor WindowStyle), Resource, Class, Icon, Name and WindowID. The style lists are not split on wildchar/non-wildchar, but are split on the priority fields. This splitting idea really needs some discussion anyway. The current style housekeeping is difficult to manage because of the cleanup operations of old styles. Separate style lists are a method to simplify that work, but then the order to apply styles becomes unclear. I'm not going to commit this, but will keep it for future reference, for the folowing reasons: In any case, you can commit it in an experimental development branch: $ cvs tag experimental_style_rewrite_base $ cvs tag -b experimental_style_rewrite_branch then commit your changes to the branch. (The first tag command sets a label on the version the branch is based on; without that it's almost impossible to find out the base of the branch). * I don't know how far away 2.6 is (I don't really know if there is anything I can do to help out get 2.6 out the door) and I don't want to add new big features at this time. * The current implementation isn't 100% behaviour backward compatible (Style * is given lowest priority, and WindowStyle highest), meaning that some configs using styles in strnage manners might change how they work. It wouldn't be hard to put Styl * into the compability layer, but putting the WindowStyle command into it would make WindowStyle different from Style (WindowID $[w.id]), which is a bad thing. * I'm not sure that the syntax is the best. It might be good to have an alias for a style, since the DeleteStyle gets rather nasty withou a name to delete. * Finally I don't know what that plan is to replace UseStyle with, and it might be good to have that in mind when impementing the syntax. I do however attach the diff if anyone want's to test it out. Phew, you've taken on a big task that still needs a lot of discussion. Note that the list in the todo-3.0 file is a collection of ideas, not something we've already decided on. There is one big item missing on the list that plays a major role in how the style rewrite is implemented. I'd like to strictly separate window state (= the current state of a window) and style (= the initial state of a window). This is listed as (22) in the file. What's not on the list is that in the end I want the same style name in styles, states and conditions, e.g. InitialStyle Iconic on WindowState Iconic off Next (WindowState Iconic on) ... All (InitialStyle Iconic on) ... Echo $[InitialStyle.Iconic] (Replaced by 1 or 0) Echo $[WindowState.Iconic] (dito) Echo $[is.InitialStyle.Iconic on] (Replaced by 1/0 if the window has the queried style) Echo $[is.WindowState.Iconic off] (dito) And all that without duplicating the code four times. To implement this it is necessary to redesigning the window structure in addition to the style code/structures. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: errors in man page
On Tue, Dec 06, 2005 at 03:56:33PM -0700, Jonathan Kotta wrote: In the Styles:Icons, shading, maximizing, movement, resizing section of the man page, there are some errors. Wrong: AllowMaximizeFixedSize enables the function Maximize to be performed on windows that are not resizable, unless maximisation has been disabled either using the style Unmaximizable or throuth WM hints, This on by default. The opposite, !AllowMaximizeFixedSize, inibits all windows that are not resizable from being maximized. Right: AllowMaximizeFixedSize enables the function Maximize to be performed on windows that are not resizable, unless maximization has been disabled either using the style !Maximizable or through WM hints. This on by default. The opposite, !AllowMaximizeFixedSize, inhibits all windows that are not resizable from being maximized. If you reply to this message, CC me, because I'm not subscribed to the workers' list. Thanks for your help, I have applied your corrections. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: matlab steals focus
On Sat, Dec 03, 2005 at 11:28:47PM +0100, Viktor Griph wrote: I've encounted a strange, and undesired, behaviour with matlab 7.x (maybe eralier versions too), and I've tried all fvwm options available and I still can't get it to work right. My conclution is that matlab must break some rule. I write this in hope that someone knows of a way to go around that behaviour. Now to a description of the problem: I always run matlab in a terminal (-nodesktop), and I want that terminal to stay focused, even If you issue a command like figure(1). The problem is that, despite that I have FocusStyle * !GrabFocus, OverrideGrabFocus, !FocusByProgram in my config, matlap gives the focus to figure 1 if I isseu the command. If a figure already is active it will focus and raise. Otherwise it will start up focused. Even if I do 'Style Figure * NeverFocus' the figure will be focused on the command figure(1) (or when clicking on the window (but I use EnterToFocus, !LeaveToUnfocus, and not ClickToFocus, so it's matlab doing that focusing too). I tried to look at the focus code myself to see if there was anything I could do to force matlab not to focus it's figures on itself, but wasn't able to make out how the code worked. I did however find that when starting matlab with -nojvm it does not steal the focus at all. However I sometimes need the jvm, so it's not a good solution. I need some help by someone who know the specification, and more of the X-protocol than I do. I have two major questions: 1. Is it possible to make fvwm not allow the said focus change to happen? No. Every application can set the focus to any window or subwindow at any time. The window manager is not involved in this process at all. All the fvwm styles affect only applications that try to cooperate with the window manager by honouring the ICCCM2 rules. 2. Is matlab breaking any standard (and in that case what), and do you think it's worth submitting a bug report to MathWorks about it? That depends on what type of focus policy matlab requests. Use FvwmIdent on the matlab window. If the focus policy says locally active or globally active, matlab is allowed to do that. If it says passive or no input matlab is breaking the ICCCM2 rules. I've never seen a company fixing a bug reported by someone from the open source community, so I doubt filing a report would be useful. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: PATCH: menu drawing fixes
On Fri, Nov 25, 2005 at 04:05:31PM -0500, Dan Espen wrote: Dan Espen [EMAIL PROTECTED] writes: Dominik Vogt [EMAIL PROTECTED] writes: The attached patch fixes various menu drawing problems. Would someone be so kind and commit it to CVS, please? Did you post the whole patch? menu_expose in menu.h still returns void. I got: ../../fvwm2_5_15/fvwm/menus.c:6814: error: conflicting types for 'menu_expose ' ../../fvwm2_5_15/fvwm/menus.h:355: error: previous declaration of 'menu_expos e' was here More errors after fixing that: ../../fvwm2_5_15/fvwm/menus.c: In function 'make_menu': ../../fvwm2_5_15/fvwm/menus.c:2675: warning: implicit declaration of function 'MR_USED_MINI_ICONS' ../../fvwm2_5_15/fvwm/menus.c:2675: error: invalid lvalue in assignment ../../fvwm2_5_15/fvwm/menus.c: In function 'get_menu_paint_item_parameters': ../../fvwm2_5_15/fvwm/menus.c:3355: error: 'struct anonymous' has no member named 'used_mini_icons' Sorry, I forgot to include the header files menus.h and menuitem.h in the patch. I've committed them now. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: resizing windows with root-transparent titles
On Sat, Nov 26, 2005 at 09:35:16PM +0100, Viktor Griph wrote: It seems as if resizing of windows with root transparent titles doesn't update the title. It will consist of the old pixmap, with the title text on the same position as before, posible tiled, if the window grew. Anyone that can give me a hint on where to start looking for the error? I've no idea where to look (Olivier wrote that code), but it works for me. Do you have a minimal config to show your problem? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
PATCH: menu drawing fixes
The attached patch fixes various menu drawing problems. Would someone be so kind and commit it to CVS, please? -- Ciao Dominik ^_^ ^_^ Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie menudrawing.patch Description: Binary data
Re: patch for modules/FvwmProxy/FvwmProxy.c to improve Solaris cc compatibility
On Mon, Nov 21, 2005 at 11:41:13AM -0500, Harry Felder wrote:
Hi all:
Attached is a simple patch to avoid an error generated by the Solaris
WorkShop 6.2 cc compiler.
Thanks for the patch, I've committed it to CVS (modified
slightly).
for (other=proxy-next; other; other=other-next)
{
+int dx, dy;
if(other-desk != deskNumber)
continue;
- int dx=abs(proxy-proxyx-other-proxyx);
- int dy=abs(proxy-proxyy-other-proxyy);
+ dx=abs(proxy-proxyx-other-proxyx);
+ dy=abs(proxy-proxyy-other-proxyy);
if (dx(proxyWidth+proxySeparation)
dyproxyHeight+proxySeparation )
{
In-block declarations must not be used in fvwm as they are not
covered by the C() standard.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: Bug in FvwmButtons (title align code)
On Thu, Oct 27, 2005 at 03:30:11PM +0200, Rafal Bisingier wrote: On Thu, Oct 27, 2005 at 02:25:44PM +0200, Dominik Vogt wrote: On Thu, Oct 27, 2005 at 10:24:42AM +0200, Rafal Bisingier wrote: On Thu, Oct 27, 2005 at 10:12:58AM +0200, Rafal Bisingier wrote: Hi, I think I found a bug in FvwmButtons. It affects title align code. cut I think I send this message too fast. It seems, that the problem is not in title arrange, but icon arrange code. So if I set Center option for a button, then it is right aligned... I wont try to patch it this time. ;-) Now you've got me totally confused. I'm sorry for this. :-) Can you give me a faulty sample config? Sure. This should produce a wrong aligned buton: *FvwmButtons: (1x1, Size 48 48, Center, Icon Tools.png , Title (Center) Tools) I've tested it. It should produce a button with Icon and title centered, but instead it gives a button with centerd title, but icon aligned to the right (of course if you use icon narrower than 48 pixels) If the Center option (the one right after the Size) is removed, then you get properly centered button. Fixed. Note that this still worked in 2.4 :-P Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: fvwm2-2.5.12-3 bug report
On Sun, Oct 23, 2005 at 06:59:28PM +, d binderman wrote: I just tried to compile package fvwm2-2.5.12-3 with the Intel C compiler It said frame.c(1199): warning #592: variable b_new is used before its value is set The source code is dw = b_new.total_size.width - b_old.total_size.width; Suggest initialise local variable b_new before first use. You're right. Fortunately it's no real bug because the result of the faulty calculation is never used. I'll fix it in 2.5.15. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: MenuStyle
On Thu, Oct 20, 2005 at 07:42:36AM +0200, Viktor Griph wrote:
Hi
I am looking into the MenuStyle code trying to understand how some things
are done. I plan to enable negation of all on/off menu styles by prefixing
! to them. However looking at the code raise some questions:
First of all what exactly does FreeColors free up?
In certain modes, X colours are managed in so called colour cells.
There may be a limited number of available cells. They are
reserved with XAllocColor and freed with XFreeColor. Because
colours are used in many places inside fvwm (colour sets!), fvwm
keeps a reference counter for the allocated colours. The
corresponding code may be a bit difficult to understand
(libs/PictureUtils.c).
FreeColors eventually decreases the reference counters and frees
the cells if the reference count drops to 0. Actually the process
is more complicated. I think Olivier has written most of the
code.
Answering this might
answe some of my other questions; at least if it has some special
functionality.
Second: The styles HilightBack and ActiveFore do free the colors if the
style have them. Howver the corresponding off-styles does not free them.
Is there any reason for this?
No, it's a bug. Both must free these colours also. Note that
nobody ever actually tested the code to free colours. I'm sure
fvwm still has many colour leaks.
Last: This can't be right can it?:
-- from menustyle.c: menustyle_copy
/* HilightBack */
if (ST_HAS_ACTIVE_BACK(destms))
{
FreeColors(ST_MENU_ACTIVE_COLORS(destms).back, 1, True);
}
ST_HAS_ACTIVE_BACK(destms) = ST_HAS_ACTIVE_BACK(origms);
memcpy(ST_MENU_ACTIVE_COLORS(destms),
ST_MENU_ACTIVE_COLORS(origms), sizeof(ColorPair));
ST_DO_HILIGHT_BACK(destms) = ST_DO_HILIGHT_BACK(origms);
/* ActiveFore */
if (ST_HAS_ACTIVE_FORE(destms))
{
FreeColors(ST_MENU_ACTIVE_COLORS(destms).fore, 1, True);
}
--
It looks to me as it frees the active fore color after having it copied
over, thus freeing the source's color instead of the overwritten.
Yes, without checking what the ST_MENU_ACTIVE_COLORS actually are,
I think you're right.
Furthermore I think the colour reference counts have to be
increased when a menustyle is copied. Consider this:
* Menustyle A has a colour x with reference count 1.
* Copy menustyle A to some other menustyle B. x still has a
reference count of 1.
* Copy A over b again. The reference count of x is decreased to
0 and never increased again. Ouch.
We should have a CopyColor function somewhere in PictureUtils.c
that takes care of this situation, e.g.
CopyColor(
sometype* dest_color, sometype* src_color,
int do_free_dest_color);
(where do_free_dest_color indicates whether the destination
colour should be freed).
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: CVS griph: reimplemented previous fix without breaking escape
On Sun, Oct 16, 2005 at 04:45:39PM -0500, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: griph 05/10/16 16:45:39 Modified files: . : ChangeLog fvwm : move_resize.c Log message: reimplemented previous fix without breaking escape Yes, that fix is fine. Note that you can not just overwrite members of an XEvent structure that do not match the event type - you will inadvertedly overwrite members of the real event. What you thought to be a random mouse button was really the keycode of the KeyPress event. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS griph: fixes for resizing shaded windows, and windows changed
On Fri, Sep 30, 2005 at 06:55:16AM +0200, Viktor Griph wrote:
On Thu, 29 Sep 2005, Dominik Vogt wrote:
On Thu, Sep 29, 2005 at 02:09:49AM -0500, fvwm-workers wrote:
CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: griph 05/09/29 02:09:48
Modified files:
. : ChangeLog NEWS
fvwm : frame.c move_resize.c
Log message:
fixes for resizing shaded windows, and windows changed by complex
functions
as
AddToFunc ResizeShadedOpaque
+ I WindowShade off
+ I Resize
+ I WindowShade on
Can you please post the diffs on frame.c and explain what you
did? I've been working on some resize-when-shaded issues a
while ago but had to stop because the patch became too
difficult to manage and I wanted to think more about it first.
The diffs is attached. The first two hunks are for the complex function
fix. There I simply unset the pressed window part if it has moved, to
avoid it being used as a starting point for resizes.
But that breaks
Style * DepressableBorder
for resize. And if the complex function looks like this:
addtofunc foo
+ i resize
+ i menu somemenu
the menu will not stick to the border because the context window
is gone. (Actually that currently works only with the title and
the title buttons, not with the window border, but I think that is
a bug).
I think this part of the patch should be removed. Can you please
demonstrate the problem you tried to solve?
The last hunk is for the resizing of the client area of shaded windows.
The only change is that, for shaded windows, the get_client_geometry
function (that calculates the client geometry based on the frame and
border) is used instead of querying the geometry of the client window.
That makes the unshading to resize the client window to the correct size
during the unshade, and not to the size it had when the window was first
shaded.
Very good patch! I tried to fix it myself but ended up with a far
more complex solution that did not work either. I never thought
of such a simple approach :-)
Also, latest CVS does not compile without warnings:
[snip]
Ooops. Sorry about that. What was the compiler flags that should be used
to disable all ignorable warnings?
gcc-2.95.x:
make CFLAGS=-g -O2 -Wall -Werror
gcc-3.x and gcc-4.x:
make CFLAGS=-g -O2 -Wall -Wpointer-arith -fno-stric-aliasing -Werror
--- frame.c.~1.60.~ 2005-09-20 23:15:34.0 +0200
+++ frame.c 2005-09-29 08:39:46.0 +0200
@@ -45,6 +45,8 @@
/* imports
*/
+extern Window PressedW;
+
/* included code files
*/
/* local types
*/
@@ -290,15 +292,53 @@
}
if (diff_g != NULL)
{
+ /* Reset PressedW to NULL if the part has moved.
+ * This prevents strange ref points from being used
+ * in resize if the window is unshaded or moved via a
+ * complex function before a resize.
+ * If this isn't desired a flag will be needed to
+ * indicate that a part has moved. */
if (part == PART_BORDER_NE || part == PART_BORDER_E ||
part == PART_BORDER_SE)
{
xwc.x -= diff_g-width;
+ if (PressedW == FW_W_SIDE(fw,1) ||
+ PressedW == FW_W_CORNER(fw, 1) ||
+ PressedW == FW_W_CORNER(fw, 3))
+ {
+ PressedW = NULL;
+ }
}
if (part == PART_BORDER_SW || part == PART_BORDER_S ||
part == PART_BORDER_SE)
{
xwc.y -= diff_g-height;
+ if (PressedW == FW_W_SIDE(fw,2)||
+ PressedW == FW_W_CORNER(fw, 2) ||
+ PressedW == FW_W_CORNER(fw, 3))
+ {
+ PressedW = NULL;
+ }
+ }
+ if (part == PART_BORDER_SW || part == PART_BORDER_W ||
+ part == PART_BORDER_NW)
+ {
+ if (PressedW == FW_W_SIDE(fw,3)||
+ PressedW == FW_W_CORNER(fw, 0) ||
+ PressedW == FW_W_CORNER(fw, 2))
+ {
+ PressedW = NULL;
+ }
+ }
+ if (part == PART_BORDER_NW || part
Re: CVS griph: fixes for resizing shaded windows, and windows changed by complex functions
On Thu, Sep 29, 2005 at 02:09:49AM -0500, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: griph 05/09/29 02:09:48 Modified files: . : ChangeLog NEWS fvwm : frame.c move_resize.c Log message: fixes for resizing shaded windows, and windows changed by complex functions as AddToFunc ResizeShadedOpaque + I WindowShade off + I Resize + I WindowShade on Can you please post the diffs on frame.c and explain what you did? I've been working on some resize-when-shaded issues a while ago but had to stop because the patch became too difficult to manage and I wanted to think more about it first. Also, latest CVS does not compile without warnings: frame.c: In function `frame_setup_border': frame.c:309: warning: assignment makes integer from pointer without a cast frame.c:320: warning: assignment makes integer from pointer without a cast frame.c:330: warning: assignment makes integer from pointer without a cast frame.c:340: warning: assignment makes integer from pointer without a cast The corresponding code is PressedW = NULL; Which should be PressedW = None; (I'll fix that). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: MouseWheel scrolling of menus
On Sun, Aug 07, 2005 at 12:44:26PM +0200, Viktor Griph wrote: On Sun, 7 Aug 2005, Dominik Vogt wrote: [snip] Could someone with cvs wrilte-access apply this patch? I'd first like to understand what the patch does exactly. Please elaborate on how the new feature works. This is a menufeel patch. It allows for selecting a menu item with a mouse wheel as follows: When the Menustyle Scroll is not Off the use of button 4 and 5 (Mousewheel up and down) no longer acts as clicks on the menu, but triggers menu scrolling. Menu scrolling is done i three possible ways: On - Positive order, menu moving; Inverted - Negative order, menu moving; Pointer Positive order, Pointer moving. When the menu is about to scroll it will find the next selectable item in the direction of the scroll, and if is On or Inverted (moving menu) the Menu window will be moved vertically so that the the new item is vertically centered under the pointer. If the scroll argument is Pointer the Pointer will wrap vertically to the center of the next item. The special case where the menu would have been placed partly outside of the screen is treated differently depending on the value of ScrollOffPage. If ScrollOffPage is true the menu will be allowed to leave the screen. If not the menu will stop at the edge and Pointer scroll will be used. Sounds interesting. I fear there may be many nasty side effects with the existing menu code - not because the patch is bad but because the menu code is very touchy. I need something to play with (I don't have a mouse wheel). It still leaves a gap in how to allow for the menu scrolling with keyboard. I'm open to suggestions. For the moment, you could just translate some key combimation like ctrl-alt-Up/Down to a button 4/5 event. At the moment I need something to play with - we can look for the final solution later. Please stick to 79 characters per line. Will do. How are tabs counted? We're using the Linux kernel coding conventions, i.e. one tab is 8 characters wide. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: MouseWheel scrolling of menus
On Sun, Aug 07, 2005 at 08:19:33PM +0200, Viktor Griph wrote: On Sun, 7 Aug 2005, Dominik Vogt wrote: On Sun, Aug 07, 2005 at 02:21:24PM +0200, Dominik Vogt wrote: On Sun, Aug 07, 2005 at 12:44:26PM +0200, Viktor Griph wrote: On Sun, 7 Aug 2005, Dominik Vogt wrote: [snip] Could someone with cvs wrilte-access apply this patch? I'd first like to understand what the patch does exactly. Please elaborate on how the new feature works. This is a menufeel patch. It allows for selecting a menu item with a mouse wheel as follows: When the Menustyle Scroll is not Off the use of button 4 and 5 (Mousewheel up and down) no longer acts as clicks on the menu, but triggers menu scrolling. Menu scrolling is done i three possible ways: On - Positive order, menu moving; Inverted - Negative order, menu moving; Pointer Positive order, Pointer moving. When the menu is about to scroll it will find the next selectable item in the direction of the scroll, and if is On or Inverted (moving menu) the Menu window will be moved vertically so that the the new item is vertically centered under the pointer. If the scroll argument is Pointer the Pointer will wrap vertically to the center of the next item. The special case where the menu would have been placed partly outside of the screen is treated differently depending on the value of ScrollOffPage. If ScrollOffPage is true the menu will be allowed to leave the screen. If not the menu will stop at the edge and Pointer scroll will be used. Sounds interesting. I fear there may be many nasty side effects with the existing menu code - not because the patch is bad but because the menu code is very touchy. I need something to play with (I don't have a mouse wheel). I've mapped the scroll action to button 3 and shift + button 3 to test the code. Some comments: 1) Scrolling the menu off page looks like a useable feature, but: * Scroll the menu off the screen. * Switch to using the cursor keys. -- You can't get the menu back on screen Using the keys should bring it back. I've taken care of that in the current candidate 2) I'm not particularly fond of the Scroll On behaviour because it is a mix of scrolling and warping the pointer. I'd remove this part. Are you sure that is Scroll On bahhaviour, and not ScrollOffPage Off behaviour? I've changed ScrollOffPage to default to On as that probably is the most useful way, and not combines pointer wrapping with menu scrolling. (Unless trigged from the keyboard, where the pointer always will wrap to the horizontal center of the menu) Erm, whatever. You understood what I meant. :-) 3) I see this whole feature as an extension of the meneShortcuts() function. Although it is triggered by the mouse, the behaviour is very similar to the keyboard shortcuts. Merging the code into menuShortcuts() should not be difficult. I suggest to translate the button event to a keycode/modifier at the start of the menuShortcuts() function. Sounds logical. I created my functiion mainly based on menuShortcuts since it seemed to do similar things, that I wanted to do. I've now merged the code into menuShortcurs by adding the action SA_SCROLL. I've also in the same time bound the scrolling to NumPad -/+ as Up/Down. 4) The Scroll Pointer behaviour should be the hard-coded default for all menus. done 5) I'm not happy about the naming of the Scroll argument. on and off should also allow all aliases that the parse_toggle_argument() function allows. But that can wait until the patch is finalized because the syntax will probably change a bit. I was quite unsure on how to handle the styles when I started. Maybe it would be better to follow the more common (for menu styles) way of having more styles that override each others. The reason why I decided not to do so was the fact that I ended up with two groups, and thought that would be more confusing. I've left these as they are in this candidate. I don't know yet either. Let's finish the feature first, then worry about the interface. New updated candidate-patch attached. Yo're fast :-) I won't get around testing the new patch until Thursday, though. [snip] Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: a simple 'FvwmConsole' patch
On Wed, Jun 15, 2005 at 01:22:25AM -0700, Piratero wrote: i don't know if it has been done already, but here is a lame patch to add a title option to the 'FvwmConsole' module. if the title option is not called, the default message will be displayed The FvwmConsole starts an xterm and passes its options to it. To set the title issue FvwmConsole -T foobar http://mrkotfw.port5.com/FvwmConsole.c.title.patch That site seems to be dead. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: fvwm 2.5.14 (cvs) segfaults on startup
On Sun, Jul 31, 2005 at 06:23:34PM +0200, T. Baumann wrote:
Hi there,
System is SUSE 9.3
Problem: fvwm (cvs) from 2005-07-28 segfaults on startup -- 2.5.10 is
fine
(gdb) run
Starting program: /usr/bin/fvwm -d 0:0
Program received signal SIGSEGV, Segmentation fault.
0x402f8348 in strcmp () from /lib/tls/libc.so.6
(gdb) bt
#0 0x402f8348 in strcmp () from /lib/tls/libc.so.6
#1 0x0805a6c5 in style_ids_are_equals (a={name = 0x1 Address 0x1 out
of bounds, window_id = 0, flags = {has_name = 1, has_window_id = 0}},
b= {name = 0x810bde0 *, window_id = 0, flags = {has_name = 1,
has_window_id = 0}}) at style.c:141
#2 0x08061660 in __style_command
(cond_rc=value optimized out, exc=0x811f670, action=value optimized
out, prefix=0x0, is_window_style=0) at style.c:4126
#3 0x08061843 in CMD_Style (cond_rc=0x810bde0, exc=0x810bde0, action=0x1
Address 0x1 out of bounds) at style.c:5032
#4 0x080a89d3 in __execute_function (cond_rc=0x0, exc=0x811d230,
action=value optimized out, exec_flags=0 '\0', args=0x0) at functions.c:630
#5 0x080a92c2 in execute_function (cond_rc=0x810bde0, exc=0x810bde0,
action=0x1 Address 0x1 out of bounds, exec_flags=0 '\0') at functions.c:1247
I don't know what's happening. The action variable is screwed,
but I don't see in the code how this can happen.
If you know how to use gdb, could you debug this problem? It's a
bit tricky to debug a window manager. One way is this:
* Modify your ~/.xinitrc and replace the call to fvwm with
sleep 1.
* Start the X server. It should hang in the sleep with an empty
desktop.
* Switch back to the text console.
* Run gdb with
$ gdb fvwm
* Put a breakpoint in the function SetRCDefaults (the one from #5
above).
* Run fvwm with the command from your .xinitrc or just fvwm:
(gdb) run fvwm options
* Single step through the code from gdb and watch the action
variable. When/why does it get the bogus value?
(If you prefer a graphical debugger, you can start a second X
server and start fvwm on that on with fvwm -d display).
#6 0x0808e082 in main (argc=3, argv=0xbfffefc4) at fvwm.c:1405
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
PATCH: fix for FvwmIconMan button drawing
Please commit the attached patch. modules/ChangeLog entry: 2005-08-01 Dominik Vogt [EMAIL PROTECTED] * FvwmIconMan/xmanager.c (set_win_iconified): fixed select/focus button state lost when deiconifying a window -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ patch Description: Binary data
Re: fvwm broken properties on 64-bit hosts (bug #2617)
On Sun, Jul 17, 2005 at 06:12:38PM +0200, Johannes Kneer wrote: [snip] Marc also has done a quick and dirty patch, that simply replaces all occurences of CARD32 by long. This might not have fixed eveything but works for me, as firefox, mozilla, etc open again their main windows. (http://data.plan9.de/fvwm.64bit-fixes.diff) Please CC us on reply as we're not subscribed to the list. I've committed a patch to CVS to deal with the problems with XChangeProperty and XGetWindowProperty, but currently I have no way to test it. Can you please try the latest CVS-snapshot and tell me if that helps? I'm specifically interested in the gnome properties _WIN_WORKSPACE _WIN_LAYER _WIN_STATE _WIN_HINTS (if one of them works, they all do. No need to check all four) and in the ewmh properties _NET_WM_WINDOW_TYPE _NET_WM_PID ... (again, checking one of them is sufficient) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Dominik, please ping
On Sun, May 15, 2005 at 07:22:39PM +, Mikhael Goikhman wrote: One user wrote me that the Dominik Vogt domivogt#fvwm.org address (that is listed in fvwm-menu-directory man page) has delivery errors. That address is correct, but I almost never get any mail through my fvwm.org address, so I don't know whether it's broken. What is a preferable email address? I suppose it is dominik.vogt#gmx.de. For fvwm-related issues, fvwm-workers#fvwm.org. For messages with non-fvwm or private contents I prefer mail on the gmx.de address. Still a good excuse to hear a word from Dominik. :) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgpd61Qof16Eu.pgp Description: PGP signature
Re: Another FAQ suggestion
On Sat, Dec 11, 2004 at 08:30:35PM +, Tavis Ormandy wrote: Hello, I have another FAQ suggestion based on a question I've seen quite frequently on irc and email, etc. feel free to modify/correct/rewrite :) Yes, you're right. I'll add it as 5.16. Q. When I Maximize an application, sometimes I get gaps around the edges, and other times I don't. What's going on? A. The ICCCM specification allows applications to specify certain properties the window manager should honour, such as aspect ratio (PAspect) or increments to be resized in (PResizeInc). Of course, sometimes these properties won't perfectly match the size of your desktop (or ewmh struts), if that should happen, you will get gaps. In general, the application will have a good reason for doing this (for example, a terminal window may not want to have only part of a column visible), but you can make fvwm ignore the hints with ResizeHintOverride. (The docs suggest only Max/Min size is ignored with ResizeHintOverride, but that doesnt seem to be true...not that I'm complaining, I like this feature! (well, i'd prefer it didnt clobber P/USPosition, but I can live with that!)) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgp9xRd8sGobL.pgp Description: PGP signature
Re: SnapAttraction does not work properly since 2.5.11
On Wed, Oct 27, 2004 at 09:07:55PM +, Mikhael Goikhman wrote: On 27 Oct 2004 11:59:57 -0700, [EMAIL PROTECTED] wrote: The intended logic is simple, as long as Alt is pressed, there is no snap-attraction; as long as it is not pressed, there is one. It is possible to press and release Alt as many times as needed to switch snap-attraction on and off while moving windows using keyboard or mouse. Not when alt being continuously pressed is part of your only way of moving a window...which is the workflow I put SnapAttraction into fvwm in the first place for. Therefore, I hope that this new intended logic is not really intended anymore. Really, this toggable snap feature thing should be via some bindable event, not a specific modifier (like an alt key), and it should be unbound (off) by default. It was on in 2.5.10, and it seems you liked it. The toggle-able snap feature worked starting with the first fresh Alt press. There are many hardcoded bindings, like Ctrl-arrows moves a window by 1 pixel in interactive Move. Middle mouse button cancels Move, third button activates a certain window flag. This is good. Noone complained yet. In short, I agree that the logic from 2.5.10 should be restored. but I think your suggestions are redundant. I see where the problem is. Traditionally, we never bothered to set the modifier states on faked motion and keyboard events. This erases the initial Alt state since one of my recent patches. Fixed with my next commit. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgpKWVGOo9pF2.pgp Description: PGP signature
Re: SnapAttraction does not work properly since 2.5.11
On Tue, Oct 26, 2004 at 12:32:38AM -0700, [EMAIL PROTECTED] wrote: Starting with version 2.5.11 SnapAttraction no longer works for me. I have narrowed it down to the transition from 2.5.10 to 2.5.11 in fvwm/move_resize.c. In particular the __move_loop function has changed some event management stuff in the proximity of lines 2100-2200. I switched it back to the 2.5.10 code in a test and SnapAttraction went back to working. 2.5.12 should work fine. However, I do not have time to look into why the code changed in the first place, so I have no proper patch to fix this. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgpTtnmYIpYcl.pgp Description: PGP signature
Re: Notification: incoming/1474
On Mon, Oct 18, 2004 at 11:12:06AM -0500, fvwm-bug wrote: FVWM Bug Tracking notification new message incoming/1474 Message summary for PR#1474 From: [EMAIL PROTECTED] Subject: Crash in Wait-Function Date: Mon, 18 Oct 2004 11:11:55 -0500 0 replies 0 followups Full_Name: Peter Daum Version: 2.5.11 / 2.5.12 CVS_Date: OS: Linux 2.6.8 X_Server: X.org 6.8.1 Submission from: (NULL) (217.231.94.145) starting with fvwm 2.5.11 when fvwm is executing something like Wait NoSuchWindowName it shows a busy cursor and waits forever. Well, not really forever: as soon as I hit any key, it crashes. Can you please fetch me a stack trace? Look for the core file, then run $ gdb fvwm core (gdb) where and post the output to fvwm-workers@fvwm.org Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgpuTyVeWufsb.pgp Description: PGP signature
Re: fvwm 2.5.1[02] stucks sometimes, always wrt Mozilla windows
On Tue, Oct 19, 2004 at 04:47:59PM -0400, Parv wrote:
in message [EMAIL PROTECTED],
wrote fvwm-w thusly...
On Sat, Oct 16, 2004 at 01:27:56AM -0400, Parv wrote:
Fvwm 2.5.1[02] gets stuck sometimes, always while raising or deiconifying
a
Mozilla window via WindowList command.
When fvwm gets stuck...
- CPU usage reaches near 100%
- Mouse pointer remains in the set CursorStyle MENU
If a transient window is iconified by its parent window and then
loses the special relationship, for example because the parent is
closed, a loop in the DeIconify() function never exits.
I have committed a patch to CVS for 2.5.13
I have generated the patch (from 2.5.12 CVS via ftp) below for
icons.c. Is this sufficient?
Yes. Does it work?
(Mind the embedded tabs in the patch)
--- fvwm/icons.c.orig Wed Mar 17 09:42:54 2004
+++ fvwm/icons.c Tue Oct 19 16:13:55 2004
@@ -2251,7 +2251,7 @@
*/
void DeIconify(FvwmWindow *fw)
{
- FvwmWindow *t,*tmp;
+ FvwmWindow *t, *tmp, *ofw;
FvwmWindow *sf = get_focus_window();
rectangle icon_rect;
XWindowAttributes winattrs = {0};
@@ -2276,15 +2276,18 @@
SET_ICONIFY_AFTER_MAP(fw, 0);
return;
}
- while (IS_ICONIFIED_BY_PARENT(fw))
+ for (ofw = NULL; fw != ofw IS_ICONIFIED_BY_PARENT(fw); )
{
- for (t = Scr.FvwmRoot.next; t != NULL; t = t-next)
+ t = get_transientfor_fvwmwindow(fw);
+ if (t != NULL)
{
- if (t != fw FW_W_TRANSIENTFOR(fw) == FW_W(t))
- {
- fw = t;
- }
+ ofw = fw;
+ fw = t;
}
+ }
+ if (IS_ICONIFIED_BY_PARENT(fw))
+ {
+ SET_ICONIFIED_BY_PARENT(fw, 0);
}
/* AS dje RaiseWindow(fw); */
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
pgpEaeOi9vsJX.pgp
Description: PGP signature
Re: System tray in FvwmTaskBar ?
On Sat, Oct 16, 2004 at 04:50:09AM +0200, fvwm-workers wrote: On Thu, Oct 14, 2004 at 05:08:50PM -0400, Gilles Foucault wrote: Dear Fvwm hackers, I'd like to ask you if there is ongoing work about the implementation of the freedesktop.org's System tray (notification area) inside FvwmTaskBar: http://freedesktop.org/Standards/systemtray-spec Currently, nobody is doing much with the taskbar. A patch would be welcome, though. I'd enjoy writing this hack using the code of peksystray (http://sourceforge.net/projects/peksystray). I should maybe get some knowledge about FVWM module writing and X programming. I already did some code with X/OpenMotif but I'm not an expert at X programming. Do you have any reference documentation to FVWM module programming (communication protocol, events) ? and X programming ? For X programming, try the man pages and these books: Adrian Nye, Xlib Programming Manual, O'Reilly, ISBN 1-56592-002-3 Adrian Nye, Xlib Reference Manual, O'Reilly, ISBN 1-56592-006-6 (about 35 USD each). Both are invaluable to the Xlib programmer (fvwm is written in plain Xlib). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgpVAVQge1fGF.pgp Description: PGP signature
Re: fvwm 2.5.1[02] stucks sometimes, always wrt Mozilla windows
On Sat, Oct 16, 2004 at 01:27:56AM -0400, Parv wrote: Fvwm 2.5.1[02] gets stuck sometimes, always while raising or deiconifying a Mozilla window via WindowList command. When fvwm gets stuck... - CPU usage reaches near 100% - Mouse pointer remains in the set CursorStyle MENU - Mouse moves but clicks do not respond - Keyboard is also lost - No windows is raised/lowered or a page is changed WindowListFunc related functions and focus placement related styles are... [snip] I can not reproduce the problem, but I can see a bug in the code: If a transient window is iconified by its parent window and then loses the special relationship, for example because the parent is closed, a loop in the DeIconify() function never exits. I have committed a patch to CVS for 2.5.13 and 2.4.19. 5.6 kB core stack follows, which is also available from... [snip] #0 0x807dfe4 in DeIconify (fw=0x8144c00) at icons.c:2283 2283 if (t != fw FW_W_TRANSIENTFOR(fw) == FW_W(t)) (gdb) bt #0 0x807dfe4 in DeIconify (fw=0x8144c00) at icons.c:2283 #1 0x807e8b9 in CMD_Iconify (cond_rc=0xbfbfe6f8, exc=0x8148200, action=0x8113e28 false) at icons.c:2674 You said it also happens when the window is just raised, not (de)iconifed. Does it hang in the same place in this case? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgpR0y1lAWr5F.pgp Description: PGP signature
Re: taskbar - new features
On Fri, Oct 15, 2004 at 12:28:10PM +0700, Andrei M. Soukharev wrote: I've made a couple of changes for FvwmTaskBar: 1) *FvwmTaskBar: ClockFont allows to set font for clock and tips independently. 2) *FvwmTaskBar: SystrayWidth allows to extend mailclock area. Then user is able to put some mini-windows above empty space on taskbar using conventional fvwm tools thus emulating systray. Is the community interested in patch? Yes, we are intereted. Can you post it to the list? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgp3LWt9iCq4Y.pgp Description: PGP signature
Re: System tray in FvwmTaskBar ?
On Thu, Oct 14, 2004 at 05:08:50PM -0400, Gilles Foucault wrote: Dear Fvwm hackers, I'd like to ask you if there is ongoing work about the implementation of the freedesktop.org's System tray (notification area) inside FvwmTaskBar: http://freedesktop.org/Standards/systemtray-spec Currently, nobody is doing much with the taskbar. A patch would be welcome, though. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgp7WxayglxiZ.pgp Description: PGP signature
Re: CopyToken()
On Tue, Oct 12, 2004 at 01:29:15PM +1000, Scott Smedley wrote:
Hi Dominik, :)
After revision 1.61 of libs/Parse.c, DoPeekToken() is behaving very
oddly. Best illustrated with an example:
If I pass a string, say, 2.5.13 to DoPeekToken() with delimiters .,
I get back the token 2 (correct) but the pointer to the rest of the
string (the actual return value) is .13 which is incorrect. (The '5'
character got truncated in CopyToken().)
+ t = SkipSpaces(src, spaces, snum);
+ if (*t != 0 dnum strchr(delims, *t) != NULL)
+ {
+ src = t + 1;
+ }
I think the strchr() needs to be replaced with a function that
checks for delims at the _start_ of t (not just anywhere in t).
strchr(delims, *t) looks for the character *t in the string
delims, not vice versa.
But I'm not really sure what your intention was, hence why I'll
leave it to you to fix.
The intention was to skip the delimiter that ended the token, even
if it is preceded by spaces. I missed the case that there is no
whitespace *after* the delimiter, though. Fixed.
I noticed this problem because the following syntax no longer works:
Test (Version = 2.5.11) Echo yup
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
pgpgghaeNzF8z.pgp
Description: PGP signature
Re: Request for FPAllowFocusClickFunction-like option applying to decor functions
On Tue, Oct 12, 2004 at 07:59:14AM -0400, Dave Ahlswede wrote: On Tue, 2004-10-12 at 12:07 +0200, Dominik Vogt wrote: ecor-context functions, if at all possible. Is that what you want? Style * !FPAllowFocusClickFunction, !FPAllowRaiseClickFunction Style * !FPPassFocusClick Note that currently if you click on the decorations to raise/focus a window, the part you clicked on is drawn pressed in and does not return to normal state. I will fix this. Ahh, thank you. Apparently, the raiseclick was what was getting me. I did actually come up with another way (amazing how a little sleep can inspire one sometimes), by executing WindowStyle NoButton and Button in a focus_change FvwmEvent. Having it in the focus model is a little more elegant though. :) I knew that feature would come in handy some day :-) It's one of those that I added just because it was easy to do and I did not see a reason against it. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgpdpNErc1QGR.pgp Description: PGP signature
Re: Removing FvwmCommand - Any opinions?
On Mon, Oct 11, 2004 at 09:07:54AM +1000, Scott Smedley wrote: Hi Dominik, I'd like to remove the current implementation of FvwmCommand because its signal and pipe handling is fundamentally flawed. Too often, a lock file of the FvwmCommand executable is left in /var/tmp although it's already dead. Can we use atexit(close_fifos)? (Lemme guess, not portable?) Whether it's portable or not - the main problem that FvwmCommand has is that it's prone to many race conditions that may cause it to segfault. It it shuts down normally, it removes the lock file itself. Rewriting it in a safe fashion should not be too difficult. But FvwmCommand has a couple of features that I find completely useless: It pleases me greatly that I can find a use for such esoteric features. :) (Perhaps this merely suggests my choice of implementation is suboptimal though.) I use '-i2' '-m' options in a simple shell script which allows me to send windows to an FvwmTabs tabber. ie. tab rxvt -bg blue will create an rxvt window put it in the last focussed tabber. Script is here: http://users.tpg.com.au/users/scottie7/tab.zsh Overall I think FvwmCommand is causing more trouble than it's worth. What do you think? I don't mind if it gets rewritten. I do use a couple of the features you're contemplating removing, but there may be other ways to accomplish the functionality in tab.zsh. Well, I'd rather write it from scratch, but keeping just the code handling i/o formatting wouldn't be too bad. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgpWC6Sub56hM.pgp Description: PGP signature
Re: 2.5.11 - Switching to last focused not working....
On Sat, Oct 09, 2004 at 02:19:36AM -0400, Parv wrote: in message [EMAIL PROTECTED], wrote fvwm-w thusly... On Sun, Oct 03, 2004 at 12:04:27AM -0400, Parv wrote: I used to be able to switch to thee last focused predictably consistently in 2.5.10 w/ the following functions key binding... key f A 4 Function switch-to-last DestroyFunc WindowListFunc AddToFuncWindowListFunc + I Iconify false + I WindowShade false + I Raise + I FlipFocus + I WarpToWindow 50 50 DestroyFunc window-list AddToFuncwindow-list + I WindowList Root c c Sticky, OnTop \ Note: options should be separated by commas. Whitespace separators may stop working some day in the future. (Fvwm 2.5.12 2.5.10 are being compared below.) In both 2.5.10 2.5.12, use of commas to separate the options causes the WindowList to appear with full geometry information and SelectOnRelease has not effect. There is a bug in some of the parsing functions. In the WindowList (and possibly some other commands) there must not be any whitespace before the comma (it works with the Style command, though). [snip] In 2.5.12, following syntax brings up WindowList w/ Desk: 0 title, current window at the end, and rest of windows in focus-LIFO order... Is that the order you want or is it not? -- I completely rewrote the focus code in 2.5.3, introducing all the FP... styles. Not using CTF myself, I believed to remember that CFT sorted windows in order of creation, not in the order of last focus. I noticed this some time ago, and CTF behaves properly since 2.5.9. Said behaviour can be activated with Style * !FPSortWindowlistByFocus In any case, I consider the focus handling code stable since 2.5.9 and very quirky from 2.5.3 and 2.5.8. [snip] There definitely is(are) some change(s), related to Style/focus, which affects the order of WindowList which was missing from 2.5.10 but is(was) present in 2.5.12(2.5.11). Can you say that again? What was missing in 2.5.10? Below is the the combined configuration snippet w/ working functions (as i desire) but apparently in incorrect syntax, and problem causing style definition(s). Style * FPLenient \ , FPClickRaisesFocused , FPClickRaisesUnfocused \ , FPClickDecorRaisesFocused , FPClickDecorRaisesUnfocused \ , FPClickIconRaisesFocused , FPClickIconRaisesUnfocused \ , FPGrabFocus , FPReleaseFocus \ , FPAllowRaiseClickFunction \ , ClickToFocusPassesClickoff \ , ClickToFocusRaises , MouseFocusClickRaises \ , FPFocusByFunctionWarpPointer \ , MouseFocus You should be aware that the maximum command length in fvwm is 1024 bytes. If you keep adding styles to this list you might hit that limit at around 30 lines in the style definition. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgpkYj1RiaOA6.pgp Description: PGP signature
Re: Problem with TearOff and ManualPlacement
On Wed, Oct 06, 2004 at 03:45:59PM +0200, Markus Rost wrote: Here is a problem when tearing off menus with the mouse with ManualPlacement activated. Run Fvwm as fvwm -f ~/.fvwm/fvwm-test with the config-file appended below. Click and release mouse 2 on the root window to open menu Menu-1. Move the mouse over item Menu-2 so that menu Menu-2 pops up. Move the mouse over Menu-2-Title and click mouse-2 (to tear off menu Menu-2). Do that mouse-2 click carefully without moving the mouse. A ribbon-band window shows up, indicating the place for the teared-off menu. Move the mouse slowly -- the ribbon-band window jumps to another place. Or click the mouse to place the window: The window is not placed at the location indicated by the initial ribbon bands. I guess that jump is not intended. If you use bigger menus, the jump can become bigger. This happens with 2.5.11 and with the cvs version after 2004-07-01. It does not happen with 2.5.10 and with the cvs version before 2004-07-01. Fixed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgp70EUPVMvlK.pgp Description: PGP signature
Re: Notification: incoming/1453
On Mon, Oct 04, 2004 at 09:20:58PM -0700, Tommy C. Li wrote: Regarding the title-bar at the side, is it possible to have rotated text? So the title would look like: M o z i l l a ? No. When we wrote the rotated titles feature, we first implemented it with upright letters. But it looks absolutely awful, so we replaced it with the rotated strings. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgp2SRZfR97BA.pgp Description: PGP signature
Re: Notification: incoming/1449
I seem to have the same effect when doing like this:
I have an application panel'ed in FvwmButtons (namely psi)
I open the panel
Then, minimize the application with titlebar minimize button
Then, press the button on FvwmButtons to close panel
fvwm crashes, dumps core, and the stack trace looks the same:
== start ==
#0 0x0806a208 in HandleUnmapNotify (ea=0xbfbfe7b4) at events.c:3374
#1 0x0806a850 in dispatch_event (e=0xbfbfe7e0) at events.c:3616
#2 0x0806a91a in HandleEvents () at events.c:3661
#3 0x080951f2 in main (argc=2, argv=0xbfbfec30) at fvwm.c:2524
[snip]
(gdb) p te
$1 = (const XEvent *) 0x14
[snip]
So I suppose this is a bug in fvwm code for handling unmapping
windows in general rather than exclusive firefox issue
It can be reduced to a simple formula:
Core dump = bug
:-)
I think I've found the reason. The FCheckIfEvent() call writes
over the te variable because the wrong pointer is passed to it
(win instead of args). Can you please try the attached patch
and tell me if it fixes the problem?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
--- events.c.orig Tue Oct 5 11:27:53 2004
+++ events.cTue Oct 5 11:39:47 2004
@@ -3350,17 +3350,16 @@
if (weMustUnmap)
{
- unsigned long win = (unsigned long)te-xunmap.window;
Bool is_map_request_pending;
check_if_event_args args;
- args.w = win;
+ args.w = te-xunmap.window;
args.do_return_true = False;
args.do_return_true_cr = False;
/* Using FCheckTypedWindowEvent() does not work here. I don't
* have the slightest idea why, but using FCheckIfEvent() with
* the appropriate predicate procedure works fine. */
- FCheckIfEvent(dpy, dummy, test_map_request, (char *)win);
+ FCheckIfEvent(dpy, dummy, test_map_request, (char *)args);
/* Unfortunately, there is no procedure in X that simply tests
* if an event of a certain type in on the queue without
* waiting and without removing it from the queue.
pgpviBrUzhrRH.pgp
Description: PGP signature
fvwm-2.5.12 has been released
Tarballs and ANNOUNCE are in the usual places. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgpypjzKnoqfk.pgp Description: PGP signature
Re: Notification: incoming/1453
On Sat, Oct 02, 2004 at 02:48:49PM -0500, fvwm-bug wrote: FVWM Bug Tracking notification new message incoming/1453 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Enhance FakeKeyPress please Full_Name: Tommy C. Li Version: 2.5.11 CVS_Date: OS: Gentoo Linux X_Server: Xorg Submission from: (NULL) (69.172.241.119) It would be great if FakeKeyPress was enhanced a bit. It does not need to be enhanced, it already supports what you are looking for. Specifically, I'd find very useful the following enhancements: -Send keys not just to specific windows, but the currently active window Try Current FakeKeyPress ... -Allow sending of keys modified with Ctrl, Meta, etc. FakeKeyPress modifiers 8 press xyz release xyz modifiers -8 Perhaps this could be put into an executable or script. XMacro had a good concept, but is unfortunately way too old, and doesn't work for me at all. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgpVkKazSlN39.pgp Description: PGP signature
Re: 2.5.11 - Switching to last focused not working....
On Sun, Oct 03, 2004 at 12:04:27AM -0400, Parv wrote: I used to be able to switch to thee last focused predictably consistently in 2.5.10 w/ the following functions key binding... key f A 4 Function switch-to-last DestroyFunc WindowListFunc AddToFuncWindowListFunc + I Iconify false + I WindowShade false + I Raise + I FlipFocus + I WarpToWindow 50 50 DestroyFunc window-list AddToFuncwindow-list + I WindowList Root c c Sticky, OnTop \ Note: options should be separated by commas. Whitespace separators may stop working some day in the future. NoGeometryWithInfo NoDeskNum NoNumInDeskTitle \ MaxLabelWidth 30 IconifiedAtEnd \ $* DestroyFunc switch-to-last AddToFuncswitch-to-last + I Function window-list SelectOnRelease Super_L In 2.5.11 i am at loss to know in advance if i would get the last focused window. Above generates only the window list; no window is selected on release of Super_L. Because the currently focused window is the first entry in the list. This config should never have worked (and it does not work here with 2.5.10). If it did, I don't understand why. You need to have the window that had the focus last at the top of the list. The CurrentAtEnd option provides this feature. Adding CurrentAtEnd right before $* makes above config work for me. If that does not help, post a minimal config that shows the problem. I see a line is mentioned in the News section on fvwm.org about changes to WindowList, but nothing helpful for me. There have been no WindowList changes since 2.5.10. The NEWS line refers to the perl library. [snip] Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgpk7pbFPLrFs.pgp Description: PGP signature
Re: Notification: incoming/1451
On Sat, Oct 02, 2004 at 09:39:15AM -0400, Rouben Rostamian wrote: I encountered what seems to be a bug that was introduced in 2.5.11. The bug was not present in 2.5.10 and 2.5.8. Unfortunately it is somewhat complicated to describe the situation. I have tried to localize the problem to a minimal script. Couldn't get the script any smaller. Sorry. The script is extracted from a much larger script which is my fvwm configuration. I have shown the script below with line numbers added so that I can refer to them. In line 26, I bind a mouse click to titlebar's button 4 to execute the function MaximizeHeight. The function MaximizeHeight, defined in lines 21-24 is a toggle; if the window's State is 4, it calls the function MaximizeHeightOff (which returns the window to its normal size and sets State 4 to False). Otherwise, it calls the function MaximizeHeightOn (which stretches the window in the vertical direction and sets State 4 to True). 1 DestroyDecor StateNormal 2 AddToDecor StateNormal 3 + AddButtonStyle 4 Pixmap button-vert-off.xpm 4 5 DestroyDecor StateMaxHeight 6 AddToDecor StateMaxHeight 7 + AddButtonStyle 4 Pixmap button-vert-on.xpm 8 9 DestroyFunc MaximizeHeightOn 10 AddToFunc MaximizeHeightOn 11 + I State 4 True 12 + I ResizeMoveMaximize frame keep 85 keep 5 13 + I ChangeDecor StateMaxHeight 14 15 DestroyFunc MaximizeHeightOff 16 AddToFunc MaximizeHeightOff 17 + I State 4 False 18 + I Maximize False 19 + I ChangeDecor StateNormal 20 21 DestroyFunc MaximizeHeight 22 AddToFunc MaximizeHeight 23 + I Current (State 4) MaximizeHeightOff 24 + I TestRc (NoMatch) MaximizeHeightOn 25 26 Mouse 0 4 A MaximizeHeight The script, as shown, works in fvwm 2.5.8 and 2.5.10, but fails in 2.5.11. In 2.5.8 and 2.5.10, mouse clicks on titilebar button 4 toggle the window's maximized state. In 2.5.11 the window gets maximized, but subsequent clicks do not return it to its normal state. The problem in 2.5.11 can be narrowed to lines 11-13: the State which is set in line 11 gets clobbered when line 13 is executed. You can verify this by inserting a few Echo commands in the code. I can work around the problem by putting line 11 after line 13, as in: 9 DestroyFunc MaximizeHeightOn 10 AddToFunc MaximizeHeightOn 12 + I ResizeMoveMaximize frame keep 85 keep 5 13 + I ChangeDecor StateMaxHeight 11 + I State 4 True Although this solves my problem, I don't see why the original arrangement doesn't work in 2.5.11. If it is a bug, then it may have other consequences which I haven't yet seen. Fixed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgplzcn6ph88z.pgp Description: PGP signature
Re: Bugs in SetEnv and UnsetEnv
On Fri, Oct 01, 2004 at 04:27:02PM +0100, Tavis Ormandy wrote: On Thu, Sep 30, 2004 at 08:40:04PM +0200, Dominik Vogt wrote: On Thu, May 29, 2003 at 10:23:48PM +, Mikhael Goikhman wrote: I would like to get some feedback before I try to resolve these bugs. These are in both 2.4.x and 2.5.x. 1) 'UnsetEnv VARNAME' does not work, the variable is not unset, instead it gets an empty value . The fix is obvious, putenv should be called with VARNAME not VARNAME=. I've written a function flib_unsetenv() that uses unsetenv if the system has it. If not, it calls putenv(name). If that throws an error or does not remove the variable, it is zeroed with putenv(name=). This new code is giving me some trouble #0 0x40290223 in free () from /lib/libc.so.6 #1 0x080f7989 in add_to_envlist (var=0x820aad0 Icon-0x243, env=0x82139f8 Icon-0x243=$[w.iconfile]) at envvar.c:394 #2 0x080f7acb in flib_putenv (var=0x820aad0 Icon-0x243, env=0x82139f8 Icon-0x243=$[w.iconfile]) at envvar.c:447 #3 0x08082cd5 in CMD_SetEnv (cond_rc=0xbfffeb60, exc=0x82153c8, action=0x8216c3b ) at builtins.c:3337 #4 0x080bab2b in __execute_function (cond_rc=0xbfffeb60, exc=0x8217360, action=0x8215bcd SetEnv Icon-0x243 $[w.iconfile], exec_flags=0 '\0', args=0x0) at functions.c:630 Fixed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgp1wr12IZYfK.pgp Description: PGP signature
Re: Notification: incoming/1451
On Fri, Oct 01, 2004 at 10:34:32AM -0500, fvwm-bug wrote: FVWM Bug Tracking notification new message incoming/1451 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: PRIVATE: The State flags gets over-written Full_Name: Rouben Rostamian Version: 2.5.11 CVS_Date: OS: SuSE Linux 9.0 X_Server: XFree86-4.3.0.1 Submission from: (NULL) (68.55.20.208) I have encountered what seems to be a bug in fvwm 2.5.11. I have verified that the bug is not present in 2.5.10 and 2.5.8. I have a short script to demo the bug. The script calls for two pixmaps. I don't know how to submit the script along with pixmaps through this web interface. If you give me an email address where I can send the three files and the description of the problem, I will be glad to do so. Send the report to fvwm-workers@fvwm.org Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgp3YHKXBe9ir.pgp Description: PGP signature
Re: Notification: incoming/1449
On Fri, Oct 01, 2004 at 02:49:45PM +0400, George Nephrite Potapov wrote: On Thu, 30 Sep 2004 18:12:57 +0200 Dominik Vogt wrote about Re: Notification: incoming/1449: [skip] Can you please fetch a stack trace and post it to the fvwm-workers list? $ gdb fvwm core (gdb) where I managed to get the stack trace for recent fvwm crash, here it is: == start == Core was generated by `fvwm'. Program terminated with signal 11, Segmentation fault. #0 0x0806a208 in HandleUnmapNotify (ea=0xbfbfe384) at events.c:3374 3374 XUnmapWindow(dpy, te-xunmap.window); ??? It can't have crashed in that line! The only possible case would be if te is invalid, but then it should have crashed earlier, in line 3353: unsigned long win = (unsigned long)te-xunmap.window; Besides, te is *never* invalid as it points to stack memory. Can you please post the output of the following gdb commands (while debugging the core file): (gdb) p te (gdb) p te-xunmap.window (gdb) p dpy (gdb) p ea (gdb) p ea-exc (gdb) p ea-exc-x #0 0x0806a208 in HandleUnmapNotify (ea=0xbfbfe384) at events.c:3374 #1 0x0806a850 in dispatch_event (e=0xbfbfe3b0) at events.c:3616 #2 0x0806a91a in HandleEvents () at events.c:3661 #3 0x080951f2 in main (argc=2, argv=0xbfbfe80c) at fvwm.c:2524 == end == Everything else the same: it was caused by firefox file/quit menu Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgpJQ6Iry5GsH.pgp Description: PGP signature
Re: Notification: incoming/1449
On Thu, Sep 30, 2004 at 08:41:53AM -0500, fvwm-bug wrote: FVWM Bug Tracking notification new message incoming/1449 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: fvwm crashes when QUIT'ing firefox Full_Name: George 'Nephrite' Potapov Version: 2.5.10 CVS_Date: OS: FreeBSD-5.3BETA5 X_Server: Xorg-6.7.0 Submission from: (NULL) (217.171.1.2) I'm using firefox 0.9.3 When I select file/quit from firefox menu, fvwm crashes and dumps core. When closing firefox windows using 'Close' fvwm function, everithing's OK. Happens every time, just start firefox and try to quit using firefox menu. I'd think it's firefox issue unless fvwm dumped core :-) Can you please fetch a stack trace and post it to the fvwm-workers list? $ gdb fvwm core (gdb) where Also, you may try a recent CVS snapshot. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgp4RcURcfowH.pgp Description: PGP signature
fvwm-2.4.9 has been released
The tarballs and the ANNOUNCE file are in the usual places (in a couple of minutes). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] pgp62ho1kWGxy.pgp Description: PGP signature
