Re: FVWM: Using an AZERTY keyboard with fvwm
On Sat, Jun 13, 2009 at 07:21:21PM +0200, Fr??d??ric Perrin wrote: Hello, I am using an AZERTY keyboard, and the keys above the lettres don't work the first time I start fvwm: the action bound to them isn't executed, and the windows that has the focus receives the keypress. If I simply restart fvwm (just fvwm, not X), they do work, without me doing anything else. This is on Linux ; the same config on FreeBSD works. I'm not using xbindkeys, nor anything that could interfer (as far as I can see). Anything else I can look into to see where this comes from ? I've seen something similar, but after I found a work around I never looked into it further. When I start Xnest and then fvwm, the keytable is blank except the couple additions I made in the configuration file. Now here is the strange part, if I start Xnest, then am careful and press shift while fvwm is starting up, then the keytable is fine. An X reset also clears the good bit. It's worth noting that Fvwm complaints when the keytable is clear as I would expect it to. [fvwm][ParseBinding]: ERROR No such key: Escape The problem persists if I give fvwm an empty config file as well, but then as it happens when I run kde, it has to be something with the X server not the window manager. I'm not planning on looking into this myself, I just thought I would suggest pressing a key and looking at `xmodmap -pk |grep ..` output before you press a key and again after to see if it's related. -- David Fries da...@fries.net http://fries.net/~david/ (PGP encryption key available)
Re: FVWM: xterm*VT100.Translations only when mouse is over the window with focus
That sounds unusual, I tried both xterm and uxterm and they both behave like I expect with registering key presses including F1 as long as that xterm has focus no matter if the mouse is someplace else. It is the same behavior as other terminals and other programs. Style "*" SloppyFocus The left click xterm menu has a Secure Keyboard option. In this mode the xterm grabs the keyboard and doesn't give it up until it is minimized or you ask it to give it up. The idea is nothing else can grab your keyboard while you type in a password, for the paranoid I guess. You might want to read about it in the man page see securekbd, and see if once it grabs the keyboard if it still gets the keys no matter where the mouse is (what I see). The behavior you describe is something like what ssh-askpass-gnome does, only in that case it grabs the keyboard focus, then ignores all keys until the mouse is over it. I find this annoying because I have hotkeys to move the mouse around, which don't work because it has a keyboard grab. On Wed, Mar 09, 2022 at 09:07:07AM +0100, n952162 wrote: > xterm*VT100.Translations only when mouse is over the window with focus > > Is this a bug or a feature? > > For me, it's a serious problem. > > (click to focus) > > ONLY CYGWIN > > In particular, I'm talking about the function keys. These are NOT > mapped in fvwm, but in xterm. > > Pressing a function key, like F1, always writes to the window with focus, > but only performs the X11/xterm translations with the mouse is hovering > of the window with focus. > > So, I always have to move the mouse to the window to be able to write to > the window. > > Note that I can visit various windows with keyboard shortcuts, so > there's no natural > correspondence with mouse position and window focus. > > fvwm 2.6.6 compiled on Oct 10 2016 at 00:25:52 > with support for: ReadLine, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, > Xinerama, XRender, XCursor, XFT, NLS > > -- David Fries
FVWM: TransliterateUtf8 and missing window titles
I'm testing on fvwm3 1.0.4 and was finding that after an Android Studio upgrade it no longer displays a title, due to a _NET_WM_NAME containing "EN DASH" and that WM_NAME is blank. Looking around other programs also fail to display the best title mostly due to "EN DASH" or "EM DASH". FiconvUtf8ToCharset has "ISO-8859-15" for to_cs for me. After much digging I found `BugOpts TransliterateUtf8` which now displays the titles I would expect. I'll accept having a wrong length dash in exchange for having a title, or for Firefox displaying the page title, or for GIMP displaying the filename or a number of other programs displaying the program name. I'm wondering about source code changes to improve the out of box experience for fvwm? The specification says to use _NET_WM_NAME in preference to WM_NAME, and the trend seems to not keep WM_NAME up to date if they even bother to populate it. What are the options for dealing with these newer programs and their unicode titles? Set TransliterateUtf8 to be enabled by default? Another option is //IGNORE to skip characters that don't convert, but to me that's an even worse option. I was originally thinking as a solution for Android Studio is to try the _NET_WM_NAME without transliterate, if it fails, and it doesn't have a WM_NAME, to convert again with transliterate. But then Firefox and Gimp would not display the current page or filename. xprop |grep WM_NAME _NET_WM_NAME(UTF8_STRING) = "appactions-fitness-kotlin \342\200\223 FitSliceProvider.kt [appactions-fitness-kotlin.app]" WM_NAME(COMPOUND_TEXT) = WM_NAME(STRING) = "Mozilla Firefox" _NET_WM_NAME(UTF8_STRING) = "fvwm window manager title blank - Google Search \342\200\224 Mozilla Firefox" Firefox 91.4.0esr 64-bit Mozilla Firefox for Red Hat Enterprise Linux WM_NAME(STRING) = "GNU Image Manipulation Program" _NET_WM_NAME(UTF8_STRING) = "[better_title_please] (exported)-30.0 (RGB color 8-bit gamma integer, GIMP built-in sRGB, 1 layer) 938x750 \342\200\223 GIMP" xprop |grep WM_NAME WM_NAME(STRING) = "Calendar " _NET_WM_NAME(UTF8_STRING) = "Calendar \342\200\224 KOrganizer" xprop |grep WM_NAME WM_NAME(STRING) = _NET_WM_NAME(UTF8_STRING) = "System Settings" https://specifications.freedesktop.org/wm-spec/1.4/ar01s05.html _NET_WM_NAME "If set, the Window Manager should use this in preference to WM_NAME." -- David Fries
Re: FVWM: EdgeScroll for fvwm on vnc
> The mouse pointer is not warped to the left edge, either. Oh, but fvwm does warp the mouse pointer to the left edge. The problem is the VNC viewer doesn't then move the mouse pointer on your local computer, which means the next mouse movement will be sent as an absolute mouse event jumping it right back to the right edge, triggering the next page flip. You can test this with xeyes, it will point to where the mouse pointer should be, and knows nothing of where t is on your local computer. > Is there a way to fix this? Any known workarounds? VNC, VirtualBox, Xnest, Xephyr, qemu, anything that treats the local mouse as an absolute position and doesn't respond to mouse pointer warp events. They all have the problem. Some like VirtualBox, Qemu lets you disable sending absolute mouse events, and start reporting relative events, which lets the mouse pointer warp work normally. Generally to do so you no longer have a way to just move the mouse away from the emulated window. Sometimes I'll just disable the page flip behavior. On Wed, Jun 02, 2021 at 10:44:40AM +0200, Harald Dunkel wrote: > Hi folks, > > for home office I am running fvwm 2.6.8 in a VNC session, using > the native resolution of my monitor at home. Fullscreen. EdgeScroll > is set to > > EdgeResistance 0 > EdgeScroll 100 100 > EdgeThickness 2 > > Problem: If the mouse hits (lets say) the right edge, then the > shown screen hops several virtual screens to the right, instead > of just a single screen, as known from fvwm on Xorg. The mouse > pointer is not warped to the left edge, either. > > Is there a way to fix this? Any known workarounds? > > > Every helpful comment is highly appreciated. > > Harri -- David Fries
Re: FVWM: Button release does not stop window dragging
> I have a weird problem on my laptop I would also be asking on the hardware side. You mentioned releasing a mouse button after dragging a window. Is this a physical button on a USB mouse, or a physical button on touch pad, or a touch pad with a down, up, down, drag motion? Especially the last I've seen touch pad behavior where a drag to the edge will lock the drag down for you to reposition your finger to continue the drag. That sounds like the behavior you are describing, in which case has nothing to do with fvwm, look at the touchpad settings to see if you can change it if you want to, or just have an explanation. On Mon, May 30, 2022 at 09:15:50AM -0600, Jaimos Skriletz wrote: > On Mon, May 30, 2022 at 12:27 AM Dov Grobgeld wrote: > > > > Hello, > > > > The problem is that when I drag a window and then release the mouse > > button, the dragging does not stop. It only stops after clicking the > > mouse button one more time. > > > > Thanks in advance for any ideas. > > Two thoughts. First check (share) the mouse binding you use for > clicking on the title bar and moving your windows. If the mouse > binding calls Move directly, such as, 'Mouse 1 T A Move', that is the > behavior you get, first click moves, second click releases. In this > case you'll need to use a custom function (check the > default-configuration for what it does), and that custom function > needs to use '+ M Move' so the move is triggered by a mouse hold/move > and then released by a mouse release. (You could also just check the > default-configuration to see if this same behavior is there to inform > you it is due to your configuration). > > My second thought is this could be hardware related. If the > default-configuration has this same behavior then check xev and make > sure you see both the ButtonPress followed by the ButtonRelease event. > > jaimos -- David Fries
Re: FVWM: Intellij focus issue
Are you talking about your mouse pointer disappearing or the keyboard cursor? Android studio uses Intellij, it's Java, so it's write once, run no where natively and multiple focus problem. For me doing the operation you mention, I still have the keyboard cursor. The keyboard cursor will vanish if the window doesn't have focus (some other window does), but what you are mentioning works fine. I don't use a compositor. On Sun, Oct 30, 2022 at 08:10:26PM +0100, Parragh, Szabolcs wrote: > Hi Everyone, > I'm having an annoying issue. I'm using FVWM3 (used FVWM2 up to a week ago > and experienced the same) and when I'm coding in Intellij: > > - if there is a suggestion pop-up and my mouse cursor is there where it > pops up > - The main window doesn't lose focus (but up-down keys select among the > suggestions) > - and if I continue typing, finish the word, or select a suggestion: my > cursor *disappears* > - interestingly I can still use delete and can step up-down (the row > highlight changes), but there is no cursor, and I cannot type new characters > - the same doesn't happen if the cursor is at any other location, not > over the pop-up -- e.g. if I select a suggestion with up-down+enter, the > cursor still blinks in the main text area > > > As you can imagine, this is a very annoying. I tried a few things, like: > > Style "jetbrains-idea" SloppyFocus, GrabFocus > or > Style "jetbrains-idea" ClickToFocus > > > But none of these helped and I'm not sure where to continue. I was wondering > if anyone has a suggestion to fix it. > > Oh, and a +1: another interesting thing, is that menus in like Firefox or > Thunderbird menus show up with around 50% transparency, and any non-focused > window has the same. Focus takes it to 0%. I'm using: > > compton -b --backend glx --glx-no-stencil --shadow-exclude "g:a:Fvwm" > > If I kill it, all transparency is gone, even in my urxvt where I > intentionally set it up. Not sure if this is an FVWM issue (probably not) > but I didn't remember having this problem only since a few months ago. > > Thanks for any suggestions! > Szabolcs -- David Fries
[PATCH] fix edge bump and window jump bug
history and bug report:
I just upgraded fvwm and saw an edge bump behavior at the outside
paging border when moving a window. When a window was moved into the
panning window the poiner and window would be bumped so the pointer
was moved outside the panning window. This jumping was annoying and
was causing me to drop windows a pixel or two from the border, which I
would have to pickup and move again.
This edge bump was introduced in 2.5.24 in virtual.c
revision 1.187
date: 2007/09/11 18:48:57; author: domivogt; state: Exp; lines: +7 -7
* Fixed jumping windows under some circumstances when releasing the button in
interactive motion while hitting the desktop's edge.
That change moved the check for if the window was paged to be too
early, in my debugging it is never hit. I moved it to right before xl
and yt are adjusted to be inside the panning windows. Otherwise xl
and yt are updated, but the pointer isn't moved. The real problem for
the jumping windows is in __move_loop. In HandlePaging xl and yt are
pointer locations and __move_loop treats them as window locations.
__move_loop would only transform the result if HandlePaging would
return 1 meaning that the desktop was paged (which in the above commit
disable the non-paging return).
At least in my tests the 'Fake and event to force window reposition.'
in __move_loop isn't required, maybe it was just masking the
pointer to window location problem. I left it inside #if 0 for
someone else to look at.
Something shorter for the CVS log or stick the above in them.
fvwm/virtual.c
Moved the no paging check after delta is calculated but before xl and
yt are updated so they will be at the current pointer location.
fvwm/move_resize.c
Transform from window to pointer location before calling HandlePaging
and back after the call. Previously it was only transforming when the
desktop was paged causing the window to jump when it wasn't paged.
--
David Fries da...@fries.net
http://fries.net/~david/ (PGP encryption key available)
diff --git a/ChangeLog b/ChangeLog
index c44dbbb..4c1efbf 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2009-03-01 David Fries da...@fries.net
+ * fvwm/virtual.c (HandlePaging):
+ move no page detect check, it wasn't being hit
+ * fvwm/move_resize.c (__move_loop):
+ transform window position to pointer position and back when calling
+ HandlePaging
+
2009-02-23 Dominik Vogt dominik(dot)vogt(at)gmx(dot)de
* NEWS:
diff --git a/NEWS b/NEWS
index d46bb5f..b718a3a 100644
--- a/NEWS
+++ b/NEWS
@@ -5,6 +5,11 @@ Note, the changes for the last STABLE release start with
release
Changes in beta release 2.5.28 (not released yet)
+* Bug fixes:
+
+ - There was a bump behavior when moving the window with the mouse
+and the border of the desktop was hit, fixed.
+
---
Changes in beta release 2.5.27 (23-Feb-2009)
diff --git a/fvwm/move_resize.c b/fvwm/move_resize.c
index 06e180e..8a56118 100644
--- a/fvwm/move_resize.c
+++ b/fvwm/move_resize.c
@@ -2404,28 +2404,33 @@ Bool __move_loop(
XEvent le;
fev_get_last_event(le);
+ /* from window location to pointer position */
+ xl -= XOffset;
+ yt -= YOffset;
rc = HandlePaging(
le, dx, dy, xl, yt, delta_x, delta_y,
False, False, True, fw-edge_delay_ms_move);
+ /* from pointer position to window location */
+ if (delta_x)
+ {
+ x_virtual_offset = 0;
+ }
+ xl += XOffset;
+ if (delta_y)
+ {
+ y_virtual_offset = 0;
+ }
+ yt += YOffset;
+ if (do_snap)
+ {
+ DoSnapAttract(
+ fw, Width, Height, xl, yt);
+ was_snapped = True;
+ }
+ #if 0
if (rc == 1)
{
/* Fake an event to force window reposition */
- if (delta_x)
- {
- x_virtual_offset = 0;
- }
- xl += XOffset;
- if (delta_y)
- {
- y_virtual_offset = 0;
- }
- yt += YOffset;
- if (do_snap)
- {
- DoSnapAttract
Re: [PATCH] fix edge bump and window jump bug
On Tue, Mar 03, 2009 at 09:41:58AM +0100, Dominik Vogt wrote: On Sun, Mar 01, 2009 at 04:08:57PM -0600, David Fries wrote: history and bug report: I just upgraded fvwm and saw an edge bump behavior at the outside paging border when moving a window. When a window was moved into the panning window the poiner and window would be bumped so the pointer was moved outside the panning window. This jumping was annoying and was causing me to drop windows a pixel or two from the border, which I would have to pickup and move again. I don't understand the problem exactly. Can you give me precise instructions with a minimal config file? Just ConfigFvwmDefaults, touch /tmp/empty ./fvwm -c /tmp/empty left click background for menu, click Issue fvwm commands, `OpaqueMoveSize 200`(optional) `Move` Click and drag from the lower part of the window, and drag it to the top of the screen. Keep pushing up and you'll see the pointer and window jitter as it jumps between the top pixel of the screen and two pixels down. This edge bump was introduced in 2.5.24 in virtual.c revision 1.187 date: 2007/09/11 18:48:57; author: domivogt; state: Exp; lines: +7 -7 * Fixed jumping windows under some circumstances when releasing the button in interactive motion while hitting the desktop's edge. I don't remember that exactly, but I still see a problem when I start moving windows with the keyboard. Windows sometimes move a pixel away from the right or bottom border of the page. My xemacs window is affected, but not my shells. I was only using the mouse to move the window, but now that I play around with the keyboad, it looks like it will do what you are describing for the xemacs when the pointer hits the outside border. That's because even though it didn't page to a different screen the XWarpPointer caused the pointer to move which moved the window back. I can't say why the shells (or any other window) would do anything differently. Wild, with the patch XWarpPointer isn't called, and the window keeps going beyond the screen, and going, and going, and around 65535 it will wrap around, and then there is some interesting behavior with focus follows mouse failing to give focus to the window. I find this amusing, I don't think this wrap around is worth fixing. That change moved the check for if the window was paged to be too early, in my debugging it is never hit. I moved it to right before xl and yt are adjusted to be inside the panning windows. Otherwise xl and yt are updated, but the pointer isn't moved. The real problem for the jumping windows is in __move_loop. In HandlePaging xl and yt are pointer locations and __move_loop treats them as window locations. __move_loop would only transform the result if HandlePaging would return 1 meaning that the desktop was paged (which in the above commit disable the non-paging return). At least in my tests the 'Fake and event to force window reposition.' in __move_loop isn't required, maybe it was just masking the pointer to window location problem. I left it inside #if 0 for someone else to look at. -- David Fries da...@fries.net http://fries.net/~david/ (PGP encryption key available)
[PATCH] property notify performance
This version includes a ChangeLog entry. I found this performance
problem from GnuCash updating the title and icon for each window for
each transaction when doing a check and repair.
The original flush_property_notify would bog down horribly when there
were lots of events in the queue, I've seen 230,000. Each time it was
called it would call FCheckPeekIfEvent which would go through all the
events in the queue and get any new events from the server. That's
because there isn't a way to abort the search midway through without
removing that event when using XCheckIfEvent, which FCheckPeekIfEvent
uses. Then if the first event returned by XCheckPeekIfEvent has a
different atom all that work looking through all the events was wasted
effort. If for some chance the application is only setting one atom
repeatedly every time FCheckIfEvent is called it starts back at the
first event until it finds it, removes it, then goes through all the
events for the FCheckPeekIfEvent to see if there is another one out
there, it really adds up.
While the replacement will start at the first event for each event
removed, it at least eliminates going through all the events between
removals.
The performance difference was about 7 hours, vs in one run keeping
up, othertimes it was minutes not hours.
--
David Fries da...@fries.net
http://fries.net/~david/ (PGP encryption key available)
diff --git a/ChangeLog b/ChangeLog
index c44dbbb..9be1355 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2009-03-21 David Fries da...@fries.net
+
+ * fvwm/events.h (test_xproperty_event_args)
+ (test_xproperty_event):
+ Added Atom to structure and renamed.
+ * fvwm/events.c (test_xproperty_event)
+ (flush_property_notify):
+ More efficiently remove property notify events.
+
2009-02-23 Dominik Vogt dominik(dot)vogt(at)gmx(dot)de
* NEWS:
diff --git a/fvwm/events.c b/fvwm/events.c
index 88ec40b..5ff37dc 100644
--- a/fvwm/events.c
+++ b/fvwm/events.c
@@ -265,13 +265,15 @@ Bool test_button_event(
return False;
}
-Bool test_typed_window_event(
+/* test window, type, atom */
+Bool test_xproperty_event(
Display *display, XEvent *event, XPointer arg)
{
- test_typed_window_event_args *ta = (test_typed_window_event_args *)arg;
+ test_xproperty_event_args *ta = (test_xproperty_event_args *)arg;
if (event-xany.window == ta-w
- event-xany.type == ta-event_type)
+ event-xany.type == ta-event_type
+ event-xproperty.atom == ta-atom)
{
return True;
}
@@ -4570,27 +4572,16 @@ int discard_window_events(Window w, long event_mask)
int flush_property_notify(Atom atom, Window w)
{
XEvent e;
- int count;
- test_typed_window_event_args args;
+ int count = 0;
+ test_xproperty_event_args args;
XSync(dpy, 0);
args.w = w;
args.event_type = PropertyNotify;
- for (count = 0;
-FCheckPeekIfEvent(
-dpy, e, test_typed_window_event, (XPointer)args);
-count++)
- {
- Bool rc;
-
- if (e.xproperty.atom != atom)
- {
- break;
- }
- /* remove the event from the queue */
- rc = FCheckIfEvent(
- dpy, e, test_typed_window_event, (XPointer)args);
- }
+ args.atom = atom;
+ /* remove all events that match window, type, and atom from the queue */
+ while (FCheckIfEvent(dpy, e, test_xproperty_event, (XPointer)args))
+ count++;
return count;
}
diff --git a/fvwm/events.h b/fvwm/events.h
index 80d043b..5c7bfd5 100644
--- a/fvwm/events.h
+++ b/fvwm/events.h
@@ -15,7 +15,8 @@ typedef struct
{
Window w;
int event_type;
-} test_typed_window_event_args;
+ Atom atom;
+} test_xproperty_event_args;
/* forward declarations --- */
@@ -45,6 +46,6 @@ void events_handle_configure_request(
XConfigureRequestEvent cre, FvwmWindow *fw, Bool force_use_grav,
int force_gravity);
Bool test_button_event(Display *display, XEvent *event, char *arg);
-Bool test_typed_window_event(Display *display, XEvent *event, char *arg);
+Bool test_xproperty_event(Display *display, XEvent *event, char *arg);
#endif /* EVENTS_H */
Re: [PATCH] property notify performance
This is really what the routine needs, FForEachEvent, but it digs into
the X internals to get the work done. I'm not expecting this to be
applied, I'm just throwing it out for food for thought. As long as
fvwm is doing an exponential traversal of the events in the queue such
as flush_property_notify, it is going to be very inefficient when
there are lots of entries in the event queue. I guess one solution
would be to pull all the events from the X event system into an fvwm
data structure which could be process efficiently by FForEachEvent.
FForEachEvent allows for going through all the events in one pass
optionally removing any number of events the predicate indicates. The
current XCheckIfEvent is limited to removing one event per pass
through the events, which is very inefficient when you get 200,000
events and you're removing just some of them one pass at a time.
/* Allows each entry to be processed in the event list in one pass removing
* or leaving each entry. Note, this only looks through events already
* in the queue.
*/
void FForEachEvent(
Display *display,
Bool (*predicate) (Display *display, XEvent *event, XPointer arg),
XPointer arg)
--
David Fries da...@fries.net
http://fries.net/~david/ (PGP encryption key available)
diff --git a/fvwm/events.c b/fvwm/events.c
index 88ec40b..9f44e4d 100644
--- a/fvwm/events.c
+++ b/fvwm/events.c
@@ -265,15 +265,22 @@ Bool test_button_event(
return False;
}
-Bool test_typed_window_event(
+/* test window, type, atom */
+Bool test_xproperty_event(
Display *display, XEvent *event, XPointer arg)
{
- test_typed_window_event_args *ta = (test_typed_window_event_args *)arg;
+ test_xproperty_event_args *ta = (test_xproperty_event_args *)arg;
if (event-xany.window == ta-w
- event-xany.type == ta-event_type)
+ event-xany.type == ta-event_type
+ event-xproperty.atom == ta-atom)
{
+ ta-count++;
+#if USE_FOR_EACH
+ return EventRemove;
+#else
return True;
+#endif
}
return False;
@@ -4137,6 +4144,8 @@ int My_XNextEvent(Display *dpy, XEvent *event)
DBUG(
My_XNextEvent, taking care of queued up events
returning (1));
+ printf(%u events queued\n,
+ FEventsQueued(dpy, QueuedAlready));
FNextEvent(dpy, event);
return 1;
}
@@ -4570,28 +4579,25 @@ int discard_window_events(Window w, long event_mask)
int flush_property_notify(Atom atom, Window w)
{
XEvent e;
- int count;
- test_typed_window_event_args args;
+ int count = 0;
+ test_xproperty_event_args args;
XSync(dpy, 0);
args.w = w;
args.event_type = PropertyNotify;
- for (count = 0;
-FCheckPeekIfEvent(
-dpy, e, test_typed_window_event, (XPointer)args);
-count++)
- {
- Bool rc;
-
- if (e.xproperty.atom != atom)
- {
- break;
- }
- /* remove the event from the queue */
- rc = FCheckIfEvent(
- dpy, e, test_typed_window_event, (XPointer)args);
- }
-
+ args.atom = atom;
+ args.count = 0;
+ /* remove all events that match window, type, and atom from the queue */
+ #if USE_FOR_EACH
+ FForEachEvent(dpy, test_xproperty_event, (XPointer)args);
+ count=args.count;
+ #else
+ while (FCheckIfEvent(dpy, e, test_xproperty_event, (XPointer)args))
+ count++;
+ #endif
+
+ printf(%s flushed %d for window 0x%x atom %d\n, __FUNCTION__,
+ count, (int)w, (int)atom);
return count;
}
diff --git a/fvwm/events.h b/fvwm/events.h
index 80d043b..35ed6e2 100644
--- a/fvwm/events.h
+++ b/fvwm/events.h
@@ -15,7 +15,10 @@ typedef struct
{
Window w;
int event_type;
-} test_typed_window_event_args;
+ Atom atom;
+/* Just for debugging */
+ int count;
+} test_xproperty_event_args;
/* forward declarations --- */
@@ -45,6 +48,6 @@ void events_handle_configure_request(
XConfigureRequestEvent cre, FvwmWindow *fw, Bool force_use_grav,
int force_gravity);
Bool test_button_event(Display *display, XEvent *event, char *arg);
-Bool test_typed_window_event(Display *display, XEvent *event, char *arg);
+Bool test_xproperty_event(Display *display, XEvent *event, char *arg);
#endif /* EVENTS_H */
diff --git a/libs/FEvent.c b/libs/FEvent.c
index b0eda1d..75cc5a4 100644
--- a/libs/FEvent.c
+++ b/libs/FEvent.c
@@ -21,6 +21,7 @@
#include config.h
#include libs/fvwmlib.h
#include X11/Xlib.h
+#include X11/Xlibint.h
#include FEvent.h
#undef FEVENT_C
#undef FEVENT_PRIVILEGED_ACCESS
@@ -317,6 +318,46 @@ Bool FCheckIfEvent
Re: Any outstanding issues/bug-fixes? (FVWM 2.6.0)
The two patches I sent in are still missing, I'll repost them if you like. The patches apply cleanly though with line offsets, the ChangeLog files obviously don't. I retested the edge bump and top of CVS fails, apply the patch and it fixes the problem. I have more details in the original e-mails. Date: Sun, 1 Mar 2009 16:08:57 -0600 From: David Fries da...@fries.net To: fvwm-workers@fvwm.org Subject: [PATCH] fix edge bump and window jump bug Date: Sat, 21 Mar 2009 18:27:39 -0500 From: David Fries da...@fries.net To: FVWM Workers fvwm-workers@fvwm.org Subject: [PATCH] property notify performance Here's a patch to help people bootstrap from CVS, autoheader trips me up everytime. It doesn't have to go in INSTALL.fvwm, it could be INSTALL (or as I've seen others a `bootstrap.sh' ) but if it's available someplace it would be really helpful. -- David Fries da...@fries.net http://fries.net/~david/ (PGP encryption key available) Index: INSTALL.fvwm === RCS file: /home/cvs/fvwm/fvwm/INSTALL.fvwm,v retrieving revision 1.62 diff -u -p -r1.62 INSTALL.fvwm --- INSTALL.fvwm7 Aug 2007 20:17:42 - 1.62 +++ INSTALL.fvwm4 Jan 2010 04:07:25 - @@ -9,6 +9,17 @@ This file details only configuration opt read the generic instructions in INSTALL first. +Compiling from CVS +== + +If the `configure' script isn't available run the following to rebuild it. +aclocal +autoheader +automake -a +autoconf +./configure + + Important Note! ===
Re: Deprecating certain Fvwm* modules
On Sat, Oct 22, 2011 at 11:23:49AM +0100, Thomas Adam wrote: Hello all, So, here's a list of modules I wish to see deprecated, with reasons why: * FvwmCommand * FvwmConsole * FvwmConsoleC.pl These three are on a list to be removed, but the functionality to replace them (notably getting FVWM to listen on a $DISPLAY socket, for instance) just isn't there yet. So whilst I don't plan on deprecating them just yet, I'm aware I'll need to at some point. FvwmConsole is the one of the list that I use from time to time. I like that it uses my terminal of choice and unlike FvwmTalk (which I suppose I can fall back on) I can cut and paste from the history with multiple lines. I'm curious from a user perspective if the interaction for the planned replacement will be the same? That is run the terminal of my choice and execute Fvwm commands. Because that's what I use it for. -- David Fries da...@fries.netPGP pub CB1EE8F0 http://fries.net/~david/
[PATCH] FvwmButtons transient avoid destroy
Sending a SIGTERM to FvwmButtons works to gracefully unswallow a
program called stalonetray which is a system tray. Setting -transient
on the FvwmButtons panel is calling XDestroyWindow and in term causes
the programs with items in the system tray to crash with a bad window
error. I'm removing the XDestroyWindow call and letting all transient
exit paths exit through the main loop.
---
What I'm really after is a way to access icons in a system tray
without it taking up screen space except when I'm wanting to use it.
A recent change in behavior leaves me with only blueman-applet able to
disable or enable bluetooth (that I know of right now), but it only
shows up in a toolbar. So I set myself up FvwmButtons
*SystemTrayButtons: (5x1+1+0 Size 0 0 Swallow \
(NoClose Hints UseOld NoTitle) stalonetray \
'Exec stalonetray -geometry 4x1-3-3')
and a menu button to start it,
+ SystemTray Module FvwmButtons -g +0-0 -transient SystemTrayButtons
Which works great with the following patch. I only see it when I want
to use it, and I can close it again when I'm done. I would have
preferred to have swallowed stalonetray up in a submenu, but this
patch was much smaller I'm sure. I would have also liked to have used
the -transientpanel option to FvwmButtons, but that seems to only work
from another FvwmButton panel, Running 'Module FvwmButtons
SystemTrayButtons' in general outside of that would just create a new
FvwmButtons, but this will do.
Can anyone thing of a case that XDestroyWindow is needed here?
modules/FvwmButtons/FvwmButtons.c | 22 --
1 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/modules/FvwmButtons/FvwmButtons.c
b/modules/FvwmButtons/FvwmButtons.c
index 1938a7c..96ec634 100644
--- a/modules/FvwmButtons/FvwmButtons.c
+++ b/modules/FvwmButtons/FvwmButtons.c
@@ -943,7 +943,7 @@ void ButtonPressProcess (button_info *b, char **act)
{
/* terminate if transient and panel has been
* unmapped */
- exit(0);
+ isTerminated = 1;
}
else if (is_transient_panel)
{
@@ -996,18 +996,11 @@ void ButtonPressProcess (button_info *b, char **act)
i2++;
}
strcat(tmp.name ,(*act)[i2]);
- if (is_transient)
- {
- /* delete the window before continuing
-*/
- XDestroyWindow(Dpy, MyWindow);
- XSync(Dpy, 0);
- }
SendText(fd,tmp.name,0);
if (is_transient)
{
/* and exit */
- exit(0);
+ isTerminated = 1;
}
if (is_transient_panel)
{
@@ -1021,18 +1014,11 @@ void ButtonPressProcess (button_info *b, char **act)
SaveButtons(UberButton);
else
{
- if (is_transient)
- {
- /* delete the window before continuing
-*/
- XDestroyWindow(Dpy, MyWindow);
- XSync(Dpy, 0);
- }
SendText(fd,*act,0);
if (is_transient)
{
/* and exit */
- exit(0);
+ isTerminated = 1;
}
if (is_transient_panel)
{
@@ -1495,7 +1481,7 @@ void Loop(void)
if (b-newflags.is_panel is_transient)
{
/* terminate if transient and a panel has been killed */
- exit(0);
+ isTerminated = 1;
}
b-swallow |= 1;
if (!b-newflags.is_panel)
--
1.7.7.1
Re: [PATCH] FvwmButtons transient avoid destroy
On Fri, Nov 25, 2011 at 09:18:52AM +, Thomas Adam wrote: On Fri, Nov 25, 2011 at 12:47:06AM -0600, David Fries wrote: Sending a SIGTERM to FvwmButtons works to gracefully unswallow a program called stalonetray which is a system tray. Setting -transient on the FvwmButtons panel is calling XDestroyWindow and in term causes the programs with items in the system tray to crash with a bad window error. I'm removing the XDestroyWindow call and letting all transient Well, I suppose what's happening here is that if an application has registered with a systray which is then killed, then it's probably defined behaviour that those programs will die along with it, although that to me seems buggy behaviour. I'd be much more inclined to look at what can be done with Stalonetray. I've tried before, and so far, got no where. Nevertheless, the point of XDestroyWindow() here is so that we really do unmap the window forcefully as we cannot rely on those programs we need to get rid of coming out of a transient FvwmButton state to have the necessary gumption to unmap their windows; I've seen a few applications like this before -- and doing so just leaves them running in the background. Don't forget that we're responsible as the parent of these windows. I took another look and did some tests. DeadPipeCleanup is called atexit(). With my patch and -transient, the Swallow flag Kill is causing the X-server to close to the connection to that client, the flag Close is doing something less forcefully, but in both cases stalonetray and xclock have terminated when the button panel closes. Compared to the previous XDestroyWindow behavior where the programs in the tray are killed, the stalonetray window is destroyed (but it keeps on running because it's too stupid to exit). From what I can tell exiting the loop normally is doing the right thing with Close and Kill, and unswallowing NoClose windows correctly. What about about adding a XDestroyWindow call at the end of DeadPipeCleanup? Would that be sufficient for forcefully destroying anything left after the other cleanup ran? So I think I'll look in to this in more detail. I don't mind the intent of your patch, but I do not like your approach to it -- and continual use of isTerminated is icky and nasty in the case where we should behandling transient FvwmButtons here much more gracefully than having many exit points as we've now got in the code. So I'll rework this, and commit something over the weekend. How's that sound? That would be great, thanks. If I knew what you were thinking I could code up the changes myself and submit another patch. -- David Fries da...@fries.netPGP pub CB1EE8F0 http://fries.net/~david/
