Subject: some leftover questions

From: Omar S Juma <[email-masked]>
Date: Fri, 27 Sep 1996 21:03:39 -0400

in 2.0.43 sources...

does anyone know the origin of these questions, and/or whether they
should be of concern vis-a-vis the current code?  none of them appears
to be of major import.

policing windows is hard work.

menus.c:497
======================================================================
      /* Unfortunately, this is needed (why?) for multi-screen 
	 operation */
      /* flush_expose(ActiveMenu->w);*/
======================================================================

fvwm.c:1083
[btw, can anyone explain exactly what SaveDesktopState() does?]
======================================================================
  if(restart)
  {
    SaveDesktopState();		/* I wonder why ... */
======================================================================

events.c:1017
[a rather confusing patch seems to have been applied here...]
======================================================================
	  /* Why is this here? Seems to cause breakage with
	   * non-focusing windows! */
	  if(!(Tmp_win->flags & ICONIFIED))
	    {
	      XSync(dpy,0);
#if 1 /* pass click event to just clicked to focus window */
	      XAllowEvents(dpy,ReplayPointer,CurrentTime);
#else /* don't pass click to just focused window */
	      XAllowEvents(dpy,AsyncPointer,CurrentTime);
#endif /* 0 */
	      XSync(dpy,0);
	      return;
	    }
======================================================================

bindings.c:299
======================================================================
  /*
  ** why wasn't XKeysymToKeycode used instead of this for loop?
  */
  XDisplayKeycodes(dpy, &min, &max);
======================================================================

...anon...
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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] (Albrecht Kadlec)
Date: Sat, 28 Sep 96 04:23:14 +0200

>>>>> Omar S Juma writes:

O> in 2.0.43 sources...

O> does anyone know the origin of these questions, and/or whether they
O> should be of concern vis-a-vis the current code?  none of them appears
O> to be of major import.

good question. I found some more.
I try to not touch the code around them unless I'm 120% sure I don't break
anything (e.g: multi-screen code). 
I guess that's why Chuck (or Rob?) put them in there.

Think of it as "sticky" code. It's been attached there and now sticks
forever, since nobody dares to remove it, even if all of the code around
has changed. 

O> policing windows is hard work.
yes.
You may have noticed: I grabbed all sort of parsing code from fvwm & some
modules and built them into the lib, while using only the best of each
implementation and optimizing the whole for stability & speed.
 It's not smooth now, and there are some ugly #defines
(e.g. to redirect GetNectToken() calls to seekright() calls.

fvwm is in dear need of a person sponsoring a weekend, renaming some
variables or functions and prettyfying the code.
(GetNextToken -> seekright would be an example. I this replace is finished,
we could rename it back to GetNextToken, since that's the better name)

There's an awkard convention mix 
(see style #defines: there's a set of definitions in fvwm.h:
	WINDOWLISTSKIP CirculateSkipIcon NOICON_TITL
	ALLCAPS		CapitalFirst	 UNDERSCORE_SPACED
it's a holy mess.
And I found a second set of style flags in misc.h which is somewhat more
consistent in nameing conventions (UNDERSCORE_SEPARATED_FLAG)
Best thing: It has to stay in sync with fvwm.h and vice versa, 
but both sets define numerical constants of their own !!!

The lesson learned from this:
Never dare to change anything unless you've grepped the whole source tree !!!
(I found 3 implementations of GetNextToken() !!! )

But this weekend-beautifying would need a _total_ (NOBODY TOUCH) codefreeze
over this one weekend and an immediate release afterwards.
And I'm not sure what to do with the modules, which are maintained by their
authors, mostly.

Maybe some more lib rewriting/moving to lib should be done first, then 
waiting for the module authors to catch up, then do it.

albrecht
-- 
You learned your lesson far too late  from the links in a chemist chain.
								-- Marillion