Subject: to do for 2.4 (update 31)

From: Dominik Vogt <[email-masked]>
Date: Wed, 3 May 2000 04:30:55 +0200

Items with highest priority / most severe problems:

New since last update:

112, 131, 132, 133, 134, 135, 136, 137

Closed since last update:

108, 109, 111,
112 (was a duplicate of 107),
112 (a new bug taking the slot),
113, 114, 115, 131, 135, 136

---------- Summary: ----------------------------------------------

 1 to be verified
20 to do
 5 distribution issues
 9 testing
----------------------
35 open items
102 items done
139 items in total

---------- To be verified: ---------------------------------------

137) Bug #550 (FvwmAuto raises after 'lower')
     [Paul (PDS)]

---------- To do: ------------------------------------------------

 14) Figure out what the problem with Amaya is.
     [reported on 3-Jun-1999 by Rob Urban <[email-masked]>]
     [still unreproducible; remove from the list?]
 16) Try to fix the 'netscape stuck on page' problem.
     [reported on 17-May-1999 by <[email-masked]>]
 17) Fix the bug that causes icons to lose management (bug #352).
     [couldn't reproduce this yet; can anybody who has netcool
     event manager try it?]
 32) Several applications are reported to not resize well under fvwm
     (Datek's "Streamer", CodeWarrior).
     [optional]
107) "Recapture" while an icon is focused takes several seconds.
     [reported by Mikhael; confirmed by Dominik]
110) Running two FvwmAuto modules at one freezes fvwm.
     [reported by Olivier on 15-Apr-2000]
     [confirmed by Dominik]
     [problem identified but not solved]
116) Fix problem that can cause long icon titles to be expanded
     although the pointer is not over it.
     [reported by Mikhael]
117) Investigate icons disappearing if icon changes while on a
     different desk.
     [reported by Julian Gilbey/David Cunningham on 16-Mar-2000]
118) Investigate "FvwmPager & StaysOnTop" bug (#543).
     [reported by Nadim Shaikli <[email-masked]>]
119) MaxSwallow does not work in FvwmWharf e.g. with
     'xload -g 50x50'.
     [reported by Dominik]
120) Icons are not always sorted properly; there may be
     gaps after page switching (with IconBox).
     [reported by Joerg Klemenz on 26-Feb-2000]
     [confirmed by Dominik (hard to reproduce)]
121) Investigate FvwmPager core dump.
     [reported by Wing Tung Leung <[email-masked]> on 20-Feb-2000]
122) Investigate FvwmButtons panel problem.
     [reported by Robert H. Ford II <[email-masked]> on 18-Feb-2000]
123) Bug #378
124) Bug #477
125) Bug #479
126) Bug #489
127) Bug #511
128) Bug #564
129) Bug #560
130) Fix bounds error with 'DestroyStyle *' in
     update_window_color_hi_style().
     [reported by Ben Winslow <[email-masked]>]
     [not reproduced yet]

132) Tru64 sizeof(unsigned long) problem
133) Bug #602 (window placement w/ 2.3.15): investigate and
     fix or close.
134) Investigate DecWindows ConfigureRequest/Notify race
     condition.
     [reported by Fabien Viallard on 19-Apr-2000]
138) Bug #593? (key bindings w/ Motif)
139) Fix TaskBar tips drawing.
     [reported by [email-masked] (Gregory A. Shimansky) on
     14-Apr-2000]

More to come soon

140)
141)
142)
143)
144)
145)
146)
147)
148)
149)
150)

---------- Distribution issues: ----------------------------------

 9)  Set up RPM packages.
     [???; Jason?]
 12) Set up bzip2 tarballs.
     [optional]
 48) Finish Windoze 95 like config file.
     [Olivier]
 62) Write a new announcement.
     [in progress]
 90) Icon distribution.

---------- Testing: ----------------------------------------------

 33) Test the GNOME patches.
 34) Update and run the purify script again (and update it).
 35) Test the strokes patch.
 36) Test the new menu styles (ItemFormat!)
 92) Test new session management code.
 94) Test colour set support in modules and fvwm.
 95) Test new panel implementation in FvwmButtons.
105) Test binding code.
106) Test window position code.
 
========== Done: =================================================

 1)  Document the GNOME stuff (man page still missing).
 2)  Add screen shots to web page.
 3)  Add link to fvwm cats page to web page.
 4)  Add link to Mikhael' wm-icons page.
 5)  Update the links on our home page.
 6)  Remove several configure options.
 7)  Create an I18N fvwm package (from 2.2 or so).
     [see #100]
 8)  Add an explanation about the various packages and where to
     discuss them to the web page.
     (stable, unstable (alpha), snapshots, ftp source tree, CVS).
 10) Remove 'PopupAsRootMenu' menu style (?).
     [rejected]
 11) Add FvwmKb module?
     [delayed until after 2.4]
 13) Use a 'busy' pointer during startup.
 15) Get restart straight (sometimes an application vanishes over restarts)
     [fixed]
 18) Check if there are still growing windows as reported for 2.13.
     [bug #184 reported by Michael Hughes <[email-masked]>]
     [no bug; doesn't happen for 2.2 and up]
 19) Fix: KFM windows stay on top of normal fvwm windows.
     [done]
 20) Check why no icon can be set for Eterm.
     [reported on 8-May-1999 by Amir Chossrow Akhavan <[email-masked]>]
     [no fix? or should we rather break 'xterm +ai'?]
 21) Fix the bug with eterm and transparent background (I think rxvt has
     the same problem.
     [Eterm bug fixed, rxvt doesn't work very well with transparent
     background. I've reported to the rxvt mailing list]
 22) Investigate bug #290. (windows cannot be raised over others sometimes).
     [mail thread from April; confirmed by me (Dominik)]
     [fixed; there is a new style and the behaviour is a bit more intuitive]
 23) Check if bug #312 is still there.
 24) Investigate bug #314.
 25) Investigate dying pager on desk-to-desk transfers (bug #358 et al.)
     [fixed; only in 2.2.2, caused by missing X error handler]
 26) Investigate bug #315. (Recapture doesn't work perfectly for changing the
     default decor).
     [mainly a documentation problem; man page was updated]
 27) Check if bug #334 is still a problem.
 28) Investigate FvemEvent core dumps.
     [fixed in 2.2.3, no bug in 2.3.4]
 29) Fix the pager bugs I reported recently.
 30) Fix the broken size hints of FvwmWinList (in fvwm itself).
 31) 'Maximize grow grow' works only on the current page.
 37) Fix interaction of moving with autoraising icon titles.
 38) Investigate bug #389. (StartsOnDesk does not work)
     [configuration problem, added a warning to the code]
 39) Investigate bug #390
 40) Investigate bug #394. (Overlapping pages)
     [no bug; doesn't happen after a recompile]
 41) Fix hanging fvwm when moving GNOME menu bars (bug #395).
 42) Get bitmap icons working again.
 43) Several pager bugs (bug #379).
 44) Fix TaskBar crash caused by latest patch in RemoveButton().
 45) Remove the web pages from the distribution.
 46) Titlebars should not inherit the pixmap from the border style.
 47) Verify the TaskBar clock update problem.
     [given up; I think I could reproduce the problem - it was a
     configuration mistake, but the reporter didn't care to answer
     if my suggestion helped; Dominik]
 49) Implement a 'H'old trigger for complex functions.
 50) Implement a 'ButtonGeometry' option for FvwmButtons.
 51) Fix constraining the window size when a window is maximized or
     larger than MaxWindowSize when mapped.
 52) Allow to resize in client resize increment steps.
 53) Decide what to do with overlapping moved icons.
     [will be ignored]
 54) Find a better solution for raising/lowering of transients.
 55) FvwmGtk can't be killed with 'KillModule'.
 56) Mini icons may overlap menu titles.
 57) Fix autohiding and TaskBar tips.
 58) DeskTopSize is not honoured upon a restart (the old one is reused).
     [use Restart --dont-preserve-state]
 59) Get Raise/Lower of transients straight.
     [duplicate of item 54]
 60) Make MaxWindowSize a style (don't release a command that will
     change anyway).
 61) Get SidecPics working again.
 63) Fix stacking order in pager.
 64) Install the new web pages.
 65) Fix "maximize true ..." when a window is already maximized.
 66) Fix ddd problems.
     [fixed as far as possible; bug reported to ddd list]
 67) Add a Windoze95 like screenshot to the web page.
 68) Investigate 'Xlib: sequence lost' message.
     [went away with a newer snapshot]
 69) Fix window moving. Several people have reported that moving windows
     is slow or the windows don't follow the pointer well. This is really
     a big problem.
 70) Fix resize. On one hand it's not nice that you can drag the window
     border off screen, on the other hand it doesn't hurt if the shadow
     of the border is not on screen.
 71) Fix drawing of window titles.
 72) Finish implementing colour sets for modules.
     [item split up]
 73) Remove 'panel' feature from FvwmButtons and re-implement it in a
     less disruptive way.
 74) To fix: icons are not preserved over a Quit - Start for fvwm
 75) Implement colour sets in FvwmWharf.
 76) Implement colour sets in FvwmTaskBar.
 77) Implement colour sets in menu styles.
 78) Implement colour sets in window styles.
     [only colours used yet]
 79) Implement colour sets in FvwmConsole?
     [rejected]
 80) Implement colour sets in FvwmScript
 81) Change the way in which fvwm 'posts' menus with a click.
 82) Introduce a 'transient' option for FvwmButtons. This is needed
     to replicate the old panel behaviour.
 83) Fix FvwmIconMan crashes introduced by colour set support(?)
     [doesn't happen anymore]
 84) Implement colour sets in FvwmBacker.
 85) Add 'geometry' panel option in FvwmButtons.
     I think it's not worth the effort because it's similarly
     complicated as the menu position hints if I want to do it right.
     I can't see an easy solution that does something useful fast.
     [future enhancement]
 86) Finish code for setting backgrounds of other applications with
     colour sets.
 87) Describe what to do for colour set support in the module docs.
 88) Investigate 'pager out of sync' problem
     [fixed]
 89) Make FvwmScript use the same visual as fvwm (prerequisite for 80)
 91) Fix Xpm version problem (bug #463).
 93) Finish 'CREATING PANELS' section in FvwmButtons man page.
 96) Make flat titlestyle work again.
 97) Rewrite FvwmTheme 'Colorset' syntax ala MenuStyle.
 98) Allow using colours from colour sets in fvwm commands.
 99) Make HilightColors command colour set aware.
100) Remove I18N patches since author seems to have lost interest
     in finishing the patch.
     [leave it in, started to rewrite patch in a better way]
101) Finish current work on style changes w/o recapture in a
     consistent way. This doesn't necessarily mean that the
     feature has to be complete before 2.4.
102) Patch 'UseDecor' and 'UseStyle' styles and various ...Style
     commands to apply without a recapture.
     [finished except UseStyle]
103) Add recent bug reports to to-do list.
104) Fix FvwmCommandS core dumps on X server shutdown.
108) FvwmPager desk separators are not updated if their colour set
     is changed (*FvwmPagerColorset).
109) FvwmIconMan titles don't seem to work.
111) Fix position hints not working with menus invoked
     from a menu like this: 'addtomenu foo foo menu foo root c c'
112) Fix desk flipping with
       shade-iconify-move_to_other_page-deiconify-unshade
     (and equivalent bug with maximize instead of shade).
113) FvwmForm sets no class/resource.
114) FvwmIdent sets no class/resource.
115) FvwmWharf sets no class/resource.
131) Sticky windows move to the top in the pager view if the desk is
     changed.
135) FvwmWinList doesn't handle negative geometries properly
     with TitleAtBottom.
136) Implement a FlushUpdates command to apply style changes
     within a function?
     [nope; enhanced Refresh/RefreshWindow instead]

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Michael Han <[email-masked]>
Date: Tue, 02 May 2000 23:07:03 -0700

Previously from Dominik Vogt
>     [reported by Nadim Shaikli <[email-masked]>]

I finally realized that my FvwmButtons is supposed to be
StaysOnTop/Layer 6 and positioned above everything else on my desktop.
This isn't always the case. I've since figured out that it's probably
the same thing as this bug. Here's how I can reproduce it.

Use an app to create a transient (it's probably easier if you use
DecorateTransient). The transient is mapped *above* windows in a
higher layer. I've seen this with transients created by Netscape and
editres (to verify this isn't toolkit specific). Now, if you raise
some other StaysPut/Layer 4 window it will raise above the transient,
and hence above Layer 6 window. Raise enough windows and the stack
will leave the Layer 6 window *on bottom*. Then you can only correct
the problem by clicking in the Layer 6 window or explicitly raising
it, at which point it reassumes its proper position in the stacking
order.

I reproduced these results using ClickToFocus,
ClickToFocusPassesClick, ClickToFocusRaisesOff. GrabFocus and
GrabFocusTransient are on. I raise windows by clicking the title which
raises.
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
"I was thinking of the immortal words of Socrates, who said, "I drank what?"
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Bob Woodside <[email-masked]>
Date: Wed, 03 May 2000 02:06:07 -0400

> 132) Tru64 sizeof(unsigned long) problem

	Fix committed on Monday, waiting for someone with one of those machines
to try it out to verify that the fix is clean....

Cheers,
Bob

---

From: Chris Rankin <[email-masked]>
Date: Wed, 3 May 2000 20:07:18 +1000 (EST)

>      [problem identified but not solved]

Have we reached a decision on this one yet? When last I saw anything
about this there were three proposals on the table:

a) rerun fvwmSelect() in My_XNextEvent() whenever we know that the
   descriptor states have changed.
b) replace pipes with AF_UNIX sockets so that we can send "UNLOCK"
   messages as "out of band" data.
c) implement our own "out of band" mechanism on the existing pipes
   (somehow).

All of these are non-trivial, although some are more non-trivial than
others. What do people think? Personally, I think that (b) is
potentially the easiest to code by replacing pipe() with
socketpair(). Sockets are as much descriptors as are pipes, so the
code should not break. However, I believe that sockets are slower than
pipes. (a) strikes me as more work to code, but keeps the existing
pipe system almost completely intact. The extra call to fvwmSelect()
can be positioned so that we only do when we need it. I can't really
comment on (c); I am worried about effort and portability in this
case.

Cheers,
Chris.

---

From: Tim Phipps <[email-masked]>
Date: Wed, 03 May 2000 11:49:36 +0100

> I can't really

I think (c) is the least risky. It's not unexpected out of band
communication, it just getting the UNLOCK message without processing the
command the module has buffered up in it's output.  It needs a queue
(only one, not one per module) of messages that is emptied in
My_XNextEvent before the select (so that buffered messages are processed
in order).  In the bit of code that waits for the UNLOCK message if a
different message is read it is added to the end of the queue and the
UNLOCK message is waited for again (with a big timeout please). I'm not
sure what the structure of queue items would have to be, probably a
string for the message plus the module id and context (and a pointer to
the next queue item).

Cheers,
Tim.

---

From: [email-masked] (Paul D. Smith)
Date: 03 May 2000 10:00:32 -0400

%% Chris Rankin <[email-masked]> writes:

  cr> a) rerun fvwmSelect() in My_XNextEvent() whenever we know that the
  cr>    descriptor states have changed.

Hmm.  I'd have to think about this more.

  cr> b) replace pipes with AF_UNIX sockets so that we can send "UNLOCK"
  cr>    messages as "out of band" data.

I don't like this one, at least for this release.  Performance is
absolutely crucial when speaking of WM modules, not to mention that
every UNIX under the sun has reasonable pipes, but we might have to do
some funky stuff, configure-wise, to support sockets.  They're pretty
standard so maybe not, but...

  cr> c) implement our own "out of band" mechanism on the existing pipes
  cr>    (somehow).

I like this one _but_ I recall someone mentioned using signals for this;
I think we should avoid that approach if possible.  Trying to handle
signals _and_ deal with writing to pipes can lead to lots of annoying,
non-trivial code to make it portable.  There are issues as to which
system calls are interruptable, which ones are interrupted by default,
etc.  Yuck.

Adding another out-of-band "unlock pipe" such as Tim mentions seems
viable, but I'm not sure how much work it is.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 3 May 2000 10:18:13 +0200

> GrabFocusTransient are on. I raise windows by clicking the title which

Sigh! Sometimes I think we're talking about different window
managers :-/  Of course I don't see anything of what you describe.
The bug is known for over a year though:  Somehow the stacking
ring gets out of order.  I had almost forgotten the problem
since nobody complained about it for a long time, but what you
say proves its still there.  I'd be very grateful if you can
strip down your config to the minimum necessary to demonstrate
the bug and provide detailed instruction how to get there from
the moment fvwm starts up.  You're probably right that layers
and transients are the crucial factors.  Perhaps the transients
have a different layer than their transientfor windows?  BTW,
which layers does FvwmIdent report for the three windows
(FvwmButtons, the transient and the transientfor)?

Bye

Dominik ^_^

---

From: Michael Han <[email-masked]>
Date: Wed, 03 May 2000 17:54:00 -0700

>(FvwmButtons, the transient and the transientfor)?

I verified that the layers are correct via FvwmIdent. Here goes with
the process I follow:

1) Start fvwm2 from the following rcfile <<EOF
Style xterm Layer 5
Module FvwmConsole
Key F1 A N Module FvwmIdent
EOF
2) Start an xterm from the root menu
3) Start editres from xterm
4) Get Tree from somewhere in editres and pick any part of the widget
tree, so you can the "Show Resource Box"
5) The box is a transient in Layer 4 (hit F1 to confirm this)
6) Move FvwmConsole (which currently should be Layer 4) to overlap the
editres transient (I think you want to make sure it doesn't overlap
the xterm)
7) Raise FvwmConsole by clicking the title
8) Move FvwmConsole to overlap the xterm (should be Layer 5)
9) FvwmConsole should be placed above the xterm

I'm pretty much positive that this is caused by the transient. It's
strange to me that both editres (a core X11 app) and Netscape
transients demonstrate the same behavior.

The only strange thing about my X environment is that it's XFree86-4.0
as built from the FreeBSD ports tree. But I think this problem
predates my XFree upgrade (I upgraded this past weekend). Please tell
me that you can reproduce this...
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
To understand recursion you must first understand recursion.
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 5 May 2000 07:46:05 +0200

> me that you can reproduce this...

No luck.  I'm still thining about how to best debug this.
The best solution would be if you could do it without any
further help :-)  Can you attach a debugger to your fvwm
and single step through the code?  I guess there must be
something wrong in stack.c, but I don't know where.  It's
probably a good idea to write a function that prints the
stack ring and use it often throughout the code, then
every so often verify if the stack ring is still okay.
Something like

  fprintf(stderr,"current stack ring:\n");
  for (t=Scr.FvwmRoot.stack_next;t!=&Scr.FvwmRoot;t=t->stack_next)
  {
    fprintf(stderr,"  window: '%s', layer %d\n", t->name, t->layer);
  }

And put a

  fprintf(stderr,"ef: '%s'\n", Action);

at the start of ExecuteFunction() to see what function is going
to be executed.  To get a debugger attached to fvwm, start a second
X server and run fvwm on it, then fire up the debugger from your
first X server.  I run the second X server from a menu with

  exec xinit /bin/sleep 100000 -- :1

Then run fvwm with -d :1.

Bye

Dominik ^_^

---

From: Michael Han <[email-masked]>
Date: Fri, 05 May 2000 00:27:06 -0700

>Then run fvwm with -d :1.

I'll give this a try this weekend.

In the meantime, I've been thinking about this problem and I
remembered a something that maybe is related. Long ago in the distant
past there was a bug in fvwm that I remember whining about. The
problem was that transients for StaysOnTop windows would map and then
immediately fall beneath their parents as the parent was raised above
the transient. Ring any bells? I'm wondering if what I'm seeing is
fallout from the fix... Anyway, I'll try to dig deeper with this
problem and the other one I reported (focus goes nowhere on
menu-invoked destroy of motif windows until an EnterNotify is given
to the last window to have focus).
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
The life uncaffeinated is not worth living.
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Chris Rankin <[email-masked]>
Date: Sun, 7 May 2000 20:02:55 +1000 (EST)

> in order).

I'm with you so far ...

> In the bit of code that waits for the UNLOCK message if a
> UNLOCK message is waited for again (with a big timeout please).

This part worries me; were you considering using a pipe for this
queue, or an IPC message queue (ulp!), or an in-memory linked list
creation or something? I think that we need to be able to block and
consume no CPU while we're waiting for our UNLOCK message. Now we can
block OK on an empty pipe, but then if we receive a message and it
isn't the one we want then we can't write the message back because
that would make our pipe readable again. This would give us a very
CPU-intensive loop.

The portability / interruptibility considerations of using IPC message
queues make me shudder - you can't select() on an IPC message queue,
for instance. The queue also wouldn't necessarily get cleaned up
automatically if FVWM core-dumped (never happen, I'm sure ... ;-)),
meaning that the user would have to do that him/herself. Hoewever, on
the plus-side, at least with message queues you could ask to receive
*only* UNLOCK type messages, regardless of what else might be on the
queue. 

If we used an in-memory linked-list kind of queue then I can't see any
other way of blocking except calling sleep(). This would affect FVWM's
responsiveness because we wouldn't be able to "wake-up" when data
arrived unless we used signals.

Can you elaborate on any of this, please Tim / Paul (PDS) / anyone ?

Cheers,
Chris.

---

From: [email-masked] (Paul D. Smith)
Date: 07 May 2000 12:47:59 -0400

>> My_XNextEvent before the select (so that buffered messages are processed

  cr> I'm with you so far ...

  >> UNLOCK message is waited for again (with a big timeout please).

  cr> This part worries me; were you considering using a pipe for this
  cr> queue, or an IPC message queue (ulp!), or an in-memory linked list
  cr> creation or something?

I'm Tim meant an in-memory queue, maintained by FVWM.  When messages we
don't want are received from the pipe they're pushed onto this queue;
then My_XNextEvent() (I guess) would read from that queue first, before
going back to selecting on the FDs.

  cr> If we used an in-memory linked-list kind of queue then I can't see any
  cr> other way of blocking except calling sleep(). This would affect FVWM's
  cr> responsiveness because we wouldn't be able to "wake-up" when data
  cr> arrived unless we used signals.

I'm not quite sure what you mean here.  I agree that Tim's thoughts need
a little more fleshing out, but I see no reason offhand why what he
proposes wouldn't work.

I can see two possible ways to do this, either or both of which might be
silly (I'm really not as familiar with the intricacies of module
messaging as I should be).

 1) We introduce one new pipe, solely for UNLOCK messages.  That same
    pipe would be given to all modules.  The UNLOCK message would have to
    have some indication of what module sent it.  This change the module
    invocation interface, of course.

    Now fvwm can select on just that pipe when it wants to wait for
    UNLOCK, without reading any other messages.  We have a real
    out-of-band queue, and we don't have to create an in-memory queue
    since we won't be reading "normal" messages at all.

    Issues: if we want to wait for certain UNLOCKs we may still need a
    queue of "other" UNLOCKs we got while waiting for the one we
    wanted.  I don't know exactly what's needed here.

    Issue 2: the possibility of deadlock is very real here.  Anyone
    using sync would have to tread very carefully to ensure they will
    always process the LOCK and respond with an UNLOCK without needing
    to wait on the normal, inband messaging.

 2) We have an in-memory queue of messages; when we're waiting for an
    UNLOCK we read the normal message queues, but if we don't get an
    UNLOCK we stuff the message we did get onto the internal queue.
    Then the function that reads messages will read that queue, if it
    exists, first and process messages in it before it does any select()
    to get more messages.

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 09 May 2000 21:57:10 +0200

> to try it out to verify that the fix is clean....

I've make a test with an OSF1 V4.0 alpha machine. Now FvwmIdent report
the good value.
Olivier

---

From: Tim Phipps <[email-masked]>
Date: Wed, 10 May 2000 18:09:35 +0100

Apologies for any mis-quoting:

> Can you elaborate on any of this, please Tim / Paul (PDS) / anyone ?

We only need to block while waiting for the UNLOCK message which can be
done with select. Any messages that come in while waiting are put on the
queue.  The queue is emptied as soon as the current function finishes
and any X-events processed.

Here's a patch for the current CVS. It doesn't break anything for me but
then again I can't reproduce the problem we are on about (I've deleted
the email detailing it). Could someone who can reproduce the hang try
this please? There are some printf's in the queue filling/emptying part.

Cheers,
Tim.

? patch
? patch.txt
Index: events.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/events.c,v
retrieving revision 1.202
diff -u -b -B -r1.202 events.c
--- events.c	2000/05/06 07:08:28	1.202
+++ events.c	2000/05/10 16:59:50
@@ -137,9 +137,78 @@
 typedef void (*PFEH)(void);
 PFEH EventHandlerJumpTable[LASTEvent];
 
+/* module command queue */
+typedef struct CommandQueue
+{
+  struct CommandQueue *next;
+  Window window;
+  int module;
+  char *command;
+} CommandQueue;
+
+static CommandQueue *CQstart = NULL;
+static CommandQueue *CQlast = NULL;
+
+/***********************************************************************
+ *
+ *  Procedure:
+ *	AddToCommandQueue - add a module command to the command queue
+ *
+ ************************************************************************/
+
+void AddToCommandQueue(Window window, int module, char *command)
+{
+  CommandQueue *new;
+
+  if (!command)
+    return;
+
+  new = (CommandQueue *)safemalloc(sizeof(CommandQueue));
+
+  new->window = window;
+  new->module = module;
+  new->command = strdup(command);
+  new->next = NULL;
+
+  fprintf(stderr, "Adding '%s' to command queue\n", command);
+
+  if (CQlast)
+    CQlast->next = new;
+  CQlast = new;
+  if (!CQstart)
+    CQstart = CQlast;
+}
+
 /***********************************************************************
  *
  *  Procedure:
+ *	EmptyCommandQueue - runs command from the module command queue
+ *
+ ************************************************************************/
+static void EmptyCommandQueue(void)
+{
+  CommandQueue *temp;
+
+  while (CQstart)
+  {
+    if (CQstart->command)
+    {
+      fprintf(stderr, "Executing '%s' from command queue\n", CQstart->command);
+      ExecuteModuleCommand(CQstart->window, CQstart->module, CQstart->command);
+      free(CQstart->command);
+    }
+    temp = CQstart;
+    CQstart = CQstart->next;
+    free(temp);
+  }
+
+  /* the queue is now empty so the end pointer must be changed */
+  CQlast = NULL;
+}
+
+/***********************************************************************
+ *
+ *  Procedure:
  *	HandleFocusIn - handles focus in events
  *
  ************************************************************************/
@@ -2142,6 +2211,12 @@
     return 1;
   }
 
+  /* execute any commands queued due to the sync module message protocol */
+  if (CQstart) {
+    DBUG("My_XNextEvent", "emptying module comand queue");
+    EmptyCommandQueue();
+  }
+
   DBUG("My_XNextEvent","no X events waiting - about to reap children");
   /* Zap all those zombies! */
   /* If we get to here, then there are no X events waiting to be processed.
@@ -2183,7 +2258,7 @@
       if ((readPipes[i] >= 0) && FD_ISSET(readPipes[i], &in_fdset)) {
         if (read(readPipes[i], &targetWindow, sizeof(Window)) > 0) {
           DBUG("My_XNextEvent","calling HandleModuleInput");
-          HandleModuleInput(targetWindow, i, NULL);
+          HandleModuleInput(targetWindow, i, NULL, False);
 	} else {
           DBUG("My_XNextEvent","calling KillModule");
           KillModule(i);
Index: events.h
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/events.h,v
retrieving revision 1.8
diff -u -b -B -r1.8 events.h
--- events.h	2000/05/06 07:08:28	1.8
+++ events.h	2000/05/10 16:59:50
@@ -16,6 +16,7 @@
 #ifndef _EVENTS_
 #define _EVENTS_
 
+void AddToCommandQueue(Window w, int module, char * command);
 void DispatchEvent(Bool preserve_Tmp_win);
 int GetContext(FvwmWindow *, XEvent *, Window *dummy);
 int My_XNextEvent(Display *dpy, XEvent *event);
Index: module_interface.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/module_interface.c,v
retrieving revision 1.61
diff -u -b -B -r1.61 module_interface.c
--- module_interface.c	2000/05/09 08:06:51	1.61
+++ module_interface.c	2000/05/10 16:59:56
@@ -432,7 +432,7 @@
 	/* Check for module input. */
 	if (read(readPipes[pipe_slot], &targetWindow, sizeof(Window)) > 0)
 	{
-	  if (HandleModuleInput(targetWindow, pipe_slot, expect) == 77)
+	  if (HandleModuleInput(targetWindow, pipe_slot, expect, False))
 	  {
 	    /* we got the message we were waiting for */
 	    done = True;
@@ -476,96 +476,102 @@
     UngrabEm(GRAB_BUSY);
 }
 
-
-/* Changed message from module from 255 to 1000. dje */
-int HandleModuleInput(Window w, int channel, char *expect)
+/* read input from a module and either execute it or queue it
+ * returns True and does NOP if the module input matches the expect string */
+Bool HandleModuleInput(Window w, int module, char *expect, Bool queue)
 {
   char text[MAX_MODULE_INPUT_TEXT_LEN];
   unsigned long size;
   unsigned long cont;
   int n;
-  extern FvwmWindow *ButtonWindow;
+  int channel = readPipes[module];
+
+  /* if expect is NULL look for FINISHED_STARTUP */
+  if (!expect)
+    expect = "FINISHED_STARTUP";
 
   /* Already read a (possibly NULL) window id from the pipe,
    * Now read an fvwm bultin command line */
-  n = read(readPipes[channel], &size, sizeof(size));
+  n = read(channel, &size, sizeof(size));
   if(n < sizeof(size))
     {
       fvwm_msg(ERR, "HandleModuleInput",
                "Fail to read (Module: %i, read: %i, size: %i)",
-               channel, n, sizeof(size));
-      KillModule(channel);
-      return 0;
+               module, n, sizeof(size));
+      KillModule(module);
+      return False;
     }
 
   if(size > sizeof(text))
     {
       fvwm_msg(ERR, "HandleModuleInput",
                "Module(%i) command is too big (%ld), limit is %d",
-               channel, size, sizeof(text));
-      size=sizeof(text);
+               module, size, sizeof(text));
+      /* the rest of the output from this module is going to be scrambled
+       * so let's kill it rather than risk interpreting garbage */
+      KillModule(module);
+      return False;
     }
 
-  pipeOn[channel] = 1;
+  pipeOn[module] = 1;
 
-  n = read(readPipes[channel],text, size);
+  n = read(channel, text, size);
   if(n < size)
     {
       fvwm_msg(ERR, "HandleModuleInput",
                "Fail to read command (Module: %i, read: %i, size: %ld)",
-               channel, n, size);
-      KillModule(channel);
-      return 0;
+               module, n, size);
+      KillModule(module);
+      return False;
     }
   text[n] = '\0';
-  n = read(readPipes[channel],&cont, sizeof(cont));
+  n = read(channel, &cont, sizeof(cont));
   if(n < sizeof(cont))
     {
       fvwm_msg(ERR, "HandleModuleInput",
                "Module %i, Size Problems (read: %d, size: %d)",
-	       channel, n, sizeof(cont));
-      KillModule(channel);
-      return 0;
+	       module, n, sizeof(cont));
+      KillModule(module);
+      return False;
     }
   if(cont == 0)
     {
+      /* this is documented as a valid way for a module to quit
+       * so let's not complain
       fvwm_msg(ERR, "HandleModuleInput",
-               "Module %i, Size Problem: cont is zero", channel);
-      KillModule(channel);
+               "Module %i, Size Problem: cont is zero", module);
+       */
+      KillModule(module);
     }
   if(strlen(text)>0)
     {
-      extern int Context;
-      FvwmWindow *tmp_win;
-
-      if(strncasecmp(text,"UNLOCK",6)==0) { /* synchronous response */
-        return 66;
-      }
-
-      if (expect && strncasecmp(text, expect, strlen(expect)) == 0)
+      if (strncasecmp(text, expect, strlen(expect)) == 0)
       {
 	/* the module sent the expected string */
-	return 77;
-      }
-      else if (!expect && strncasecmp(text, "FINISHED_STARTUP", 16) == 0)
-      {
-	/* module has finished startup */
-	return 77;
+	return True;
       }
 
       /* perhaps the module would like us to kill it? */
       if(strncasecmp(text,"KillMe",6)==0)
       {
-        KillModule(channel);
-        return 0;
+        KillModule(module);
+        return False;
       }
 
-      /* If a module does XUngrabPointer(), it can now get proper Popups */
-      if(StrEquals(text, "popup"))
-	Event.xany.type = ButtonPress;
+      if (queue)
+        AddToCommandQueue(w, module, text);
       else
-	Event.xany.type = ButtonRelease;
-      Event.xany.window = w;
+        ExecuteModuleCommand(w, module, text);
+    }
+  return False;
+}
+
+/* run the command as if it cames from a button press or release */
+void ExecuteModuleCommand(Window w, int module, char *text)
+{
+  extern FvwmWindow *ButtonWindow;
+  extern int Context;
+  FvwmWindow *tmp_win;
 
       if (XFindContext (dpy, w, FvwmContext, (caddr_t *) &tmp_win) == XCNOENT)
 	{
@@ -573,45 +579,25 @@
 	  w = None;
 	}
 
-#if 0
-      /* With this you can't start a move from the WindowList module (or any
-       * other module. The move code expects the location from the event to
-       * be related to the real pointer position, otherwise the window will
-       * appear somewhere, but not where we want. */
-      if(tmp_win)
-	{
-	  if (!IS_ICONIFIED(tmp_win))
-	  {
-	    Event.xbutton.x_root = tmp_win->frame_g.x;
-	    Event.xbutton.y_root = tmp_win->frame_g.y;
-	  }
-	  else
-	  {
-	    Event.xbutton.x_root = tmp_win->icon_g.x;
-	    Event.xbutton.y_root = tmp_win->icon_g.y;
-	  }
-	}
-      else
-	{
+      /* Query the pointer, the pager-drag-out feature doesn't work properly.*/
+      /* This is OK now that the Pager uses "Move pointer" */
+      /* A real fix would be for the modules to pass the button press coords */
           XQueryPointer(dpy, Scr.Root, &JunkRoot, &JunkChild, &JunkX,&JunkY,
                         &Event.xbutton.x_root,&Event.xbutton.y_root,&JunkMask);
-	}
-#else
-      /* On the other hand, if we always query the pointer, the pager-drag-out
-       * feature doesn't work properly. */
-      XQueryPointer(dpy, Scr.Root, &JunkRoot, &JunkChild, &JunkX,&JunkY,
-		    &Event.xbutton.x_root,&Event.xbutton.y_root,&JunkMask);
-#endif
+      /* If a module does XUngrabPointer(), it can now get proper Popups */
+      if(StrEquals(text, "popup"))
+	Event.xbutton.type = ButtonPress;
+      else
+	Event.xbutton.type = ButtonRelease;
+      Event.xbutton.window = w;
       Event.xbutton.button = 1;
       Event.xbutton.x = 0;
       Event.xbutton.y = 0;
       Event.xbutton.subwindow = None;
       Context = GetContext(tmp_win,&Event,&w);
       ButtonWindow = tmp_win;
-      ExecuteFunction(text,tmp_win,&Event,Context,channel,EXPAND_COMMAND,NULL);
+      ExecuteFunction(text,tmp_win,&Event,Context,module,EXPAND_COMMAND,NULL);
       ButtonWindow = NULL;
-    }
-  return 0;
 }

@@ -1189,22 +1175,22 @@
    when I added the lockonsend logic.  The routine seems to big to
    want to inline.  dje 9/4/98 */
 extern int myxgrabcount;                /* defined in libs/Grab.c */
-int PositiveWrite(int module, unsigned long *ptr, int size)
+void PositiveWrite(int module, unsigned long *ptr, int size)
 {
   extern int moduleTimeout;
 
   if((pipeOn[module]<0)||(!((PipeMask[module]) & ptr[1])))
   {
-    return -1;
+    return;
   }
 
   /* a dirty hack to prevent FvwmAnimate triggering during Recapture */
   /* would be better to send RecaptureStart and RecaptureEnd messages. */
-  /* If module is lock on send for iconify message and its an
+  /* If module is lock on send for iconify message and it's an
    * iconify event and server grabbed, then return */
   if ((NoGrabMask[module] & SyncMask[module] & ptr[1]) && (myxgrabcount != 0))
   {
-    return -1;
+    return;
   }
 
   AddToQueue(module,ptr,size,0);
@@ -1219,6 +1205,7 @@
     Window targetWindow;
     fd_set readSet;
     struct timeval timeout;
+    int channel = readPipes[module];
 
     FlushQueue(module);
 
@@ -1234,7 +1221,7 @@
        */
       timeout.tv_sec = moduleTimeout;
       timeout.tv_usec = 0;
-      FD_SET(readPipes[module], &readSet);
+      FD_SET(channel, &readSet);
 
       /*
        * Wait for input to arrive on our descriptor, but not too long
@@ -1246,7 +1233,7 @@
            * any watched descriptors receive readable data then there
            * is only one candidate ...
            */
-          (fvwmSelect(readPipes[module] + 1,
+          (fvwmSelect(channel + 1,
                       &readSet,
                       NULL,
                       NULL,
@@ -1257,7 +1244,7 @@
            * that I can think of is that the remote end of our
            * descriptor was closed and we receive an end-of-file ...
            */
-          (read(readPipes[module],
+          (read(channel,
                 &targetWindow,
                 sizeof(targetWindow)) != sizeof(targetWindow))
          )
@@ -1269,21 +1256,18 @@
                  "Failed to read descriptor:\n"
                  "- data available=%c\n"
                  "- terminate signal=%c\n",
-                 (FD_ISSET(readPipes[module], &readSet) ? 'Y' : 'N'),
+                 (FD_ISSET(channel, &readSet) ? 'Y' : 'N'),
                  isTerminated ? 'Y' : 'N');
         KillModule(module);
         break;
       }
 
-      /*
-       * NOTE: this function can call PositiveWrite, so we could
-       *       get some really nasty recursion here!!!
+      /* NOTE: just queue up the message or funny recursion and
+       * deadlocks may happen, see the "Two FvwmAuto's hangs fvwm" thread
        */
     }
-    while (HandleModuleInput(targetWindow, module, NULL) != 66);
+    while (!HandleModuleInput(targetWindow, module, "UNLOCK", True));
   }
-
-  return size;
 }

Index: module_interface.h
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/module_interface.h,v
retrieving revision 1.10
diff -u -b -B -r1.10 module_interface.h
--- module_interface.h	2000/03/24 10:31:52	1.10
+++ module_interface.h	2000/05/10 16:59:57
@@ -73,7 +73,8 @@
 int executeModuleDesperate(F_CMD_ARGS);
 void executeModuleSync(F_CMD_ARGS);
 void initModules(void);
-int HandleModuleInput(Window w, int channel, char *expect);
+void ExecuteModuleCommand(Window w, int channel, char *command);
+Bool HandleModuleInput(Window w, int channel, char *expect, Bool queue);
 void KillModule(int channel);
 void ClosePipes(void);
 void BroadcastPacket(unsigned long event_type, unsigned long num_datum, ...);
@@ -96,7 +97,7 @@
 void send_list_func(F_CMD_ARGS);
 void FlushOutputQueues(void);
 void FlushQueue(int Module);
-int PositiveWrite(int module, unsigned long *ptr, int size);
+void PositiveWrite(int module, unsigned long *ptr, int size);
 RETSIGTYPE DeadPipe(int nonsense);
 void set_mask_function(F_CMD_ARGS);
 void setSyncMaskFunc(F_CMD_ARGS);

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 10 May 2000 23:46:10 +0200

> this please? There are some printf's in the queue filling/emptying part.

Hello,
Unfortunately, it seems that the patch does not fix the double FvwmAuto
hang (just start 2 FvwmAuto 200 Raise and play with auto raise between
two windows). I've got the following to my stderr (after starting the second
FvwmAuto and moving between two windows):

Adding 'Silent Raise' to command queue
Executing 'Silent Raise' from command queue
Adding 'Silent Raise' to command queue
Executing 'Silent Raise' from command queue
Adding 'Silent Raise' to command queue
Executing 'Silent Raise' from command queue
Adding 'Silent Raise' to command queue
Executing 'Silent Raise' from command queue
Adding 'Silent Raise' to command queue

Then fvwm hang and never execute the Silent Raise of the queue ...

Olivier

---

From: Tim Phipps <[email-masked]>
Date: Thu, 11 May 2000 15:24:40 +0100

> FvwmAuto and moving between two windows):

I remembered what it was that made me think of a queue. It's the fact
that fvwm rememebers what pipe have data ready for too long.  Here's a
patch on the patch that fixes it for me:

*** events.c.orig       Thu May 11 15:10:30 2000
--- events.c    Thu May 11 15:10:57 2000
***************
*** 2258,2264 ****
        if ((readPipes[i] >= 0) && FD_ISSET(readPipes[i], &in_fdset)) {
          if (read(readPipes[i], &targetWindow, sizeof(Window)) > 0) {
            DBUG("My_XNextEvent","calling HandleModuleInput");
!           HandleModuleInput(targetWindow, i, NULL, False);
        } else {
            DBUG("My_XNextEvent","calling KillModule");
            KillModule(i);
--- 2258,2264 ----
        if ((readPipes[i] >= 0) && FD_ISSET(readPipes[i], &in_fdset)) {
          if (read(readPipes[i], &targetWindow, sizeof(Window)) > 0) {
            DBUG("My_XNextEvent","calling HandleModuleInput");
!           HandleModuleInput(targetWindow, i, NULL, True);
        } else {
            DBUG("My_XNextEvent","calling KillModule");
            KillModule(i);

Sorry it's not an attachment but it only one line.  It makes fvwm read
all the module commands into the queue before processing them.  If this
fixes it for you should I commit this?

Cheers,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Fri, 12 May 2000 15:09:51 +0100

Tim Phipps wrote:
> that fvwm remembers what pipe have data ready for too long.  Here's a

A bit more testing reveals that MY_XNextEvent() is the only place that
queueing should happen. The original patch enabled queueing in the
sending of synchronous messages which is wrong, if you use FvwmIconMan
and use it to animate Iconification the queueing leads to the animation
being too late (IconMan sends a "SendToModule Animate..." command which
should be processed before proceeding). I've taken the queueing out here
and tested it for lock ups with four FvwmAuto's and it works OK.

I've also had a go at speeding up module input processing by removing
the checks for "FINISHED_STARTUP" and "UNLOCK" on each command sent by
each module.  I've changed these  comands to "NOP FINISHED STARTUP" and
"NOP UNLOCK" so that when modules send them and fvwm isn't looking for
them you don't get an error message.

And I've removed the checking for "KILLME" on every message by adding a
library function SendQuitNotification() that uses the continuation field
in the module-fvwm protocol, this only affects FvwmForm I think.

I've had it going for a day now (wow! serious testing eh!), should I
commit this?

Cheers,
Tim.

---

From: Dan Espen <[email-masked]>
Date: Fri, 12 May 2000 10:27:27 -0400

> in the module-fvwm protocol, this only affects FvwmForm I think.

I see a "killme" in FvwmCommandS.c

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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-masked].
To report problems, send mail to [email-masked]

---

From: [email-masked] (Paul D. Smith)
Date: 12 May 2000 11:16:46 -0400

I vote put it in.  We've needed something like this for a long time.
It's either that or leave the multi-FvwmAuto lock bug in for 2.4 and
wait until 2.5 for this fix, but I don't think we should do that.

BTW, is there any docs on the process for module messaging?  If so, it
would be A Good Thing if those docs were updated to describe this.  If
not, we probably really should write some someday :)

---

From: Michael Han <[email-masked]>
Date: Sun, 14 May 2000 13:59:58 -0700

Previously from Paul D. Smith
>not, we probably really should write some someday :)

Yeah, there's the documentation in the fvwm-web module. It looks like
someone ought to update these docs to reflect the way synchronous
operation is working.
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
"What was your username?" - BOFH
--
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-masked].
To report problems, send mail to [email-masked]