SnapAttraction does not work properly since 2.5.11
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. 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. -- AJ Weber [EMAIL PROTECTED] [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Fixed crashes and bugs in handling of the root window / other unmanaged
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt04/10/26 04:06:53 Modified files: . : ChangeLog fvwm : bindings.c builtins.c events.c module_interface.c libs : Bindings.c Bindings.h Log message: * Fixed crashes and bugs in handling of the root window / other unmanaged windows in the window specific binding code. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: 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: SnapAttraction does not work properly since 2.5.11
2.5.12 does not work either. I first notcied the problem when I last updated my debian box, which jumped me to 2.5.12. I then tried versions of fvwm in backwards progression, compiled myself (starting with 2.5.12, to ensure it was not the debian packager's fault), until I hit one that worked...namely 2.5.10. I then isolated the problem to the mentioned area of code. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: SnapAttraction does not work properly since 2.5.11
Hi, [Please retain the CC to [EMAIL PROTECTED], so that the debian BTS may have a record of your input] On Tue, 26 Oct 2004 09:47:10 +0200, Dominik Vogt fvwm-workers@fvwm.org said: 2.5.12 should work fine. SnapAttraction 20 SameType SnapGrid 10 10 It actually works, but only if no modifier is pressed. So, if one has a binding like Mouse 1 T A move-or-raise one has to release alt before getting attraction. manoj -- Home on the Range was originally written in beef-flat. Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
fvwm: Fullscreen should not require EWMHUseStackingOrderHints style
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. Fvwm2 seems to have some trouble with the EWMH fullscreen mode. My configuration includes a stay-on-top FvwmPager. When putting EWMH compliant applications, such as tvtime, the pager is not obscured by the fullscreen window, so I get a TV window with a pager floating on top, which is less than desirable. The bug can also be reproduced with the fullscreen modes in Mozilla Firefox and OpenOffice.org, but I have not tested using this extensively as I have with tvtime. The bug can be worked around by setting: Style * EWMHUseStackingOrderHints in the .fvwm2rc file. After investigating the problem, my analysis of the problem is that it seems (according to the excellent fvwm manual page) that the EWMHUseStackingOrderHints was intended to disable/enable some KDE-specific extentions. Unfortunately, the slightly misleading option name lead a programmer to misinterpret the meaning of the flag when programming the fullscreen code, and made that disable the stacking code in that when it was enabled. The fact that the option is not intended to disable *all* stacking hints is further supported by the fact that tvtime also has an (AFAIK) EWMH-compliant Always-on-top mode, which does manage to obscure the pager properly, even when EWMHUseStackingOrderHints unset. From http://www.freedesktop.org/standards/wm-spec/1.3/ar01s07.html#STACKINGORDER # Stacking order # # To obtain good interoperability between different Desktop Environments, # the following layered stacking order is recommended, from the bottom: # # * windows of type _NET_WM_TYPE_DESKTOP # * windows having state _NET_WM_STATE_BELOW # * windows not belonging in any other layer # * windows of type _NET_WM_TYPE_DOCK (unless they have state # _NET_WM_TYPE_BELOW) and windows having state _NET_WM_STATE_ABOVE # * focused windows having state _NET_WM_STATE_FULLSCREEN # # Windows that are transient for another window should be kept above this # window. # # The window manager may choose to put some windows in different stacking # positions, for example to allow the user to bring currently a active # window to the top and return it back when the window looses focus. Let me summarize: If the EWMHUseStackingOrderHints style is on, fullscreen works. Pager is hidden as it should be. If the EWMHUseStackingOrderHints style is off, fullscren works, but pager is not hidden. But, EWMH always-on-top modes such as the one found in tvtime still works. According to the documentation, EWMHUseStackingOrderHints affects KDE-specific extentions. The extentions mentioned aren't KDE extentions, they are a part of the EWMH standard 1.3 from freedesktop.org. So either the documentation is wrong or the code is wrong. And still, you shouldn't have to activate a special option in order for FVWM to fully comply with the recommendation in the standard. So, I see two possibilities: - The option is intended to tell EWMH never to dictate stacking. In that case it's broken since tvtime's EWMH always-on-top stacking still works when that option is disabled, and the documentation is wrong. - And what I think is more likely: The option was intended to activate special KDE-specific extentions (as per the documentation) but somehow breaks fullscreen mode to be out of compliance with recommendations if disabled. This has nothing to do with KDE extentions AFAIK. The bug has been tested mainly on fvwm debian versions 2.5.10-12 and 2.5.10-13 (latest testing versions), and has also been tested against 2.5.12 from the tarball from upstream. manoj -- An economist is a man who would marry Farrah Fawcett for her money. Edgar R. Fiedler Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: fvwm: Fullscreen should not require EWMHUseStackingOrderHints style
On Tue, Oct 26, 2004 at 01:26:38PM -0500, 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. Fvwm2 seems to have some trouble with the EWMH fullscreen mode. My configuration includes a stay-on-top FvwmPager. When putting EWMH compliant applications, such as tvtime, the pager is not obscured by the fullscreen window, so I get a TV window with a pager floating on top, which is less than desirable. The bug can also be reproduced with the fullscreen modes in Mozilla Firefox and OpenOffice.org, but I have not tested using this extensively as I have with tvtime. The bug can be worked around by setting: Style * EWMHUseStackingOrderHints in the .fvwm2rc file. So, everything is fine. No? You use a stay on top pager (i.e., you use stacking), so you should use this style. I've no time to explain why, but I do like stay on top windows at all. Maybe, this EWMHUseStackingOrderHints should be on by default. I do not know (and I do not care). After investigating the problem, my analysis of the problem is that it seems (according to the excellent fvwm manual page) that the EWMHUseStackingOrderHints was intended to disable/enable some KDE-specific extentions. For me the bug is in the man page. Unfortunately, the slightly misleading option name lead a programmer to misinterpret the meaning of the flag when programming the fullscreen code, and made that disable the stacking code in that when it was enabled. The fact that the option is not intended to disable *all* stacking hints is further supported by the fact that tvtime also has an (AFAIK) EWMH-compliant Always-on-top mode, which does manage to obscure the pager properly, even when EWMHUseStackingOrderHints unset. From http://www.freedesktop.org/standards/wm-spec/1.3/ar01s07.html#STACKINGORDER # Stacking order # # To obtain good interoperability between different Desktop Environments, # the following layered stacking order is recommended, from the bottom: # # * windows of type _NET_WM_TYPE_DESKTOP # * windows having state _NET_WM_STATE_BELOW # * windows not belonging in any other layer # * windows of type _NET_WM_TYPE_DOCK (unless they have state # _NET_WM_TYPE_BELOW) and windows having state _NET_WM_STATE_ABOVE # * focused windows having state _NET_WM_STATE_FULLSCREEN # # Windows that are transient for another window should be kept above this # window. # # The window manager may choose to put some windows in different stacking # positions, for example to allow the user to bring currently a active # window to the top and return it back when the window looses focus. FVWM try to follow the spec but surely do not follow this *recommendation* without an user intervention (or if EWMHUseStackingOrderHints was a default, without the possibility to break such a recommendation). For me, the only acceptable stacking rule is the one concerning _NET_WM_TYPE_DESKTOP. Let me summarize: If the EWMHUseStackingOrderHints style is on, fullscreen works. Pager is hidden as it should be. Fine. If the EWMHUseStackingOrderHints style is off, fullscren works, but pager is not hidden. But, EWMH always-on-top modes such as the one found in tvtime still works. Maybe tvtime use the old GNOME hints? What happen if you use Style * IgnoreGnomeHints ? According to the documentation, EWMHUseStackingOrderHints affects KDE-specific extentions. The extentions mentioned aren't KDE extentions, they are a part of the EWMH standard 1.3 from freedesktop.org. So either the documentation is wrong or the code is wrong. The documentation is wrong. The EWMHUseStackingOrderHints code and doc was written before _NET_WM_STATE_BELOW, _NET_WM_STATE_ABOVE and _NET_WM_STATE_FULLSCREEN was introduced in the ewmh spec. Even, I think that at some point in the spec elaboration it was decided that no stacking rules should appear in the spec (Dominik?), but one day someone decided that all wm should work like kwin and metacity ... The code follows the EWMHUseStackingOrderHints style but not the doc :o/ This happen even with FVWM! And still, you shouldn't have to activate a special option in order for FVWM to fully comply with the recommendation in the standard. Not agree (but I do not care if we can disable these stacking dictatorial rules via a style). So, I see two possibilities: - The option is intended to tell EWMH never to dictate stacking. Yes! In that case it's broken since tvtime's EWMH always-on-top stacking still works when that option is disabled, and the documentation is wrong. Maybe there is a bug somewhere. I've not tvtime here; but as I said maybe the old GNOME hints are used. Try to disable the GNOME hints and see if tvtime is still stay on top. - And what I think is more
Notification: incoming/1480
FVWM Bug Tracking notification
new message incoming/1480
Message summary for PR#1480
From: Manoj Srivastava [EMAIL PROTECTED]
Subject: fvwm: Fullscreen should not require EWMHUseStackingOrderHints
style
Date: Tue, 26 Oct 2004 13:26:38 -0500
0 replies 0 followups
ORIGINAL MESSAGE FOLLOWS
From [EMAIL PROTECTED] Tue Oct 26 13:38:04 2004
Received: from host-12-107-230-171.dtccom.net ([12.107.230.171]
helo=glaurung.internal.golden-gryphon.com)
by util2.math.uh.edu with esmtp (Exim 4.30)
id 1CMWCo-0005x2-MW; Tue, 26 Oct 2004 13:38:03 -0500
Received: from glaurung.internal.golden-gryphon.com ([EMAIL PROTECTED]
[127.0.0.1])
by glaurung.internal.golden-gryphon.com (8.13.1/8.13.1/Debian-15) with
ESMTP id i9QIR6lT021572
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Tue, 26 Oct 2004 13:27:06 -0500
Received: (from [EMAIL PROTECTED])
by glaurung.internal.golden-gryphon.com (8.13.1/8.13.1/Submit) id
i9QIQdBa021562;
Tue, 26 Oct 2004 13:26:39 -0500
X-Authentication-Warning: glaurung.internal.golden-gryphon.com: srivasta set
sender to [EMAIL PROTECTED] using -f
To: [EMAIL PROTECTED]
Cc: fvwm-workers@fvwm.org, Per von Zweigbergk [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: fvwm: Fullscreen should not require EWMHUseStackingOrderHints style
From: Manoj Srivastava [EMAIL PROTECTED]
Organization: The Golden Gryphon
X-URL: http://www.golden-gryphon.com/
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
(i686-pc-linux-gnu)
Mail-Copies-To: nobody
X-Face: [EMAIL PROTECTED]/;Y^gTjR\T^B'fbeuVGiyKrvbfKJl!^e|e:iu(kJ6c|QYB57LP*|t
YlP~HF/=h:[EMAIL PROTECTED]:6Cj0kd#4]*D,|0djf'CVlXkI,aV4\}?d_KEqsN{Nnt7
78OsbQ[56/!nisvyB/uA5Q.{)gm6?q.j71ww.b9b]-sG8zNt%KkIaxWg1VcjZk[hBQ]j~`Wq
Xl,y1a!(6`UM{~'X[Y_,Bv+}=L\SS*mA8=s;!=O`ja|@PEzbi0}Qp,`Z\:6:OmRi*
Date: Tue, 26 Oct 2004 13:26:38 -0500
Message-ID: [EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: -4.9 ()
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.
Fvwm2 seems to have some trouble with the EWMH fullscreen mode.
My configuration includes a stay-on-top FvwmPager. When putting EWMH
compliant applications, such as tvtime, the pager is not obscured by
the fullscreen window, so I get a TV window with a pager floating on
top, which is less than desirable.
The bug can also be reproduced with the fullscreen modes in Mozilla
Firefox and OpenOffice.org, but I have not tested using this
extensively as I have with tvtime.
The bug can be worked around by setting:
Style * EWMHUseStackingOrderHints
in the .fvwm2rc file.
After investigating the problem, my analysis of the problem is that
it seems (according to the excellent fvwm manual page) that the
EWMHUseStackingOrderHints was intended to disable/enable some
KDE-specific extentions.
Unfortunately, the slightly misleading option name lead a programmer to
misinterpret the meaning of the flag when programming the fullscreen
code, and made that disable the stacking code in that when it was
enabled.
The fact that the option is not intended to disable *all* stacking
hints is further supported by the fact that tvtime also has an (AFAIK)
EWMH-compliant Always-on-top mode, which does manage to obscure the
pager properly, even when EWMHUseStackingOrderHints unset.
From
http://www.freedesktop.org/standards/wm-spec/1.3/ar01s07.html#STACKINGORDER
# Stacking order
#
# To obtain good interoperability between different Desktop Environments,
# the following layered stacking order is recommended, from the bottom:
#
# * windows of type _NET_WM_TYPE_DESKTOP
# * windows having state _NET_WM_STATE_BELOW
# * windows not belonging in any other layer
# * windows of type _NET_WM_TYPE_DOCK (unless they have state
# _NET_WM_TYPE_BELOW) and windows having state _NET_WM_STATE_ABOVE
# * focused windows having state _NET_WM_STATE_FULLSCREEN
#
# Windows that are transient for another window should be kept above this
# window.
#
# The window manager may choose to put some windows in different stacking
# positions, for example to allow the user to bring currently a active
# window to the top and return it back when the window looses focus.
Let me summarize:
If the EWMHUseStackingOrderHints style is on, fullscreen works. Pager
is hidden as it should be.
If the EWMHUseStackingOrderHints style is off, fullscren works, but
pager is not hidden. But, EWMH always-on-top modes such as the one
found in tvtime still works.
According to the documentation, EWMHUseStackingOrderHints affects
KDE-specific extentions. The extentions mentioned aren't KDE
extentions, they are a part of the EWMH standard 1.3 from
freedesktop.org. So either the documentation is wrong or the code is
wrong.
And
Re: fvwm 2.5.1[02] stucks sometimes, always wrt Mozilla windows
in message [EMAIL PROTECTED], wrote fvwm-w thusly... On Tue, Oct 19, 2004 at 04:47:59PM -0400, Parv wrote: I have generated the patch (from 2.5.12 CVS via ftp) below for icons.c. Is this sufficient? Yes. Does it work? Well, so far there has not been a lock up. Now, only if i could reproduce the problem on demand. - Parv -- -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
