Subject: FvwmEvent question (& AUTHORS update)

From: Albrecht Kadlec <[email-masked]>
Date: 07 May 1999 17:36:13 +0200

the easy part first:

In the AUTHORS file I found this paragraphs:

> To find out what should go in this file, see "Information For
> Maintainers of GNU Software" (maintain.texi), the section called
> "Recording Changes".

I couldn't find maintain.texi in the dev. tree.

> Along with a cast of thousands (well, dozens) mentioned in old
> ChangeLog entries.  If you find your name below, please send an entry
> in the style of the above entries, to the mailing list [email-masked].

and somewhat below:

> Albrecht Kadlec

so here it goes:

Albrecht Kadlec: 
Code & manual cleanups, enhancements, Fixes and module-library which
partially made it into fvwm2.0.42-47d.
Rewrite & cleanup of FvwmAuto & FvwmAudio.
Created FvwmEvent to supersede FvwmAudio (& FvwmAuto).

Hope that's along the directions in maintain.texi.

 And now for FvwmEvent.
 -----------------------

I grabbed the dev. tree & ediff'ed FvwmEvent.c. 
63 differences, with big blocks due to reindentation.
83 differences after indent-region in both files, but much more exact
ones. (around 20 whitespace diffs)

the top of my changelog of FvwmEvent:
_______________________________________________________________________

 * made new SetupModule() library function & use it.
        -> aliasing support.
	-> additional commandline arg is used for FvwmEventCmd

 * SetMask used to mask un-configured events.

 * renamed & cleaned up so that FvwmEvent (TaDa !!) is a general event 
   handler module. 
               -- 21.04.98 Albrecht Kadlec ([email-masked])

 ________________________________________________________________________

so the upper two modifications didn't make it to the current version.

Sorry, but I was busy, and nobody ever contacted me on FvwmEvent,
except for Dan Espen in July and Oct. 98 with some minor things
- documentation & moved my parsing fns to the lib - and Fred Marciel in Nov
98, suggesting to merge FvwmStylCmd.pl into FvwmEvent, below the relevant
part of his message:

> For short, I have stopped the development of FvwmStyleCmd.pl, and I'd like
> to make a few contributions to FvwmEvent instead:
> - include access to the event parameters (at least for the window name,
>   class and resource)
> - include the possibility of executing multiple fvwm commands per event
>   (separating them by commas)

We agreed, that some basic issues had to be sorted out first in fvwm, and
that we'd have to wait until the waves settled.

maybe we waited too long :-)

now, what do _YOU_ want to do with FvwmEvent.

there are several options:

	leave it as it is (maybe include the "setmask" message filtering)

	merge the 2 versions 
		this pretty much means going through both versions and try
		to imagine the common ancestor and the reason for each
		change. 

	go on and incorporate _true_ _generic_ event handling support into
	Fvwm core as well as a _generic_ play command.
		only Lines 274-385 (231-317 for my version) do something.
		The rest is parsing table definitions, signal handling,
		include files. (all unnecessary for core implementation)
		(this means: _ditch_ FvwmEvent)

If it's for a useable release, I'd opt for 1.
If it's for a new alpha version, I vote for 3.

what do _you_ think

-- 
Albrecht Kadlec
Vienna University of Technology / Department of Automation
----------------------------------------------------------
God used a radial arm saw when he built the world and got it done in six
days. If he'd used a table saw, he'd have gotten it done in four days and
the coastlines would have been straighter.	-- Old woodworking joke.
--
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: Dan Espen <[email-masked]>
Date: Fri, 07 May 1999 14:00:28 -0400

> I couldn't find maintain.texi in the dev. tree.

I forget where this is, but its not supposed to be in the dev tree.
Your entry looked OK to me.

> > in the style of the above entries, to the mailing list [email-masked]
> and somewhat below:
> 
> > Albrecht Kadlec
> 
> so here it goes:
> 
> Albrecht Kadlec: 

I've put this in the current CVS.
>  And now for FvwmEvent.

I have no idea where those diffs came from.

> the top of my changelog of FvwmEvent:

I remember discussions  of a SetupModule  function.  Thats what led me
to  make FvwmAnimate and FvwmForm    have  similar long stretches   of
initialization code.  Sadly,  I have yet to turn  this into a callable
function.  If you submitted a SetupModule function, the maintainer at
the time must have done something to it.

>                -- 21.04.98 Albrecht Kadlec ([email-masked])

Sounds like a good thing to do.

> 		(this means: _ditch_ FvwmEvent)

I'm not sure I understand what you have in mind.  Is it something like:

AddHook Iconify Exec exec play ouch.au

> If it's for a new alpha version, I vote for 3.

No opinion yet.  Maybe someone else...

--
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]