Subject: Re: Extending FvwmEvent

From: Albrecht Kadlec <[email-masked]>
Date: 14 Dec 1998 16:16:24 +0100

"Fred Maciel" writes:

> Dear Albrecht,
> 
> Hi again (I wrote to you recently about my FvwmStyleCmd.pl module shortly
> after it was posted to the fvwm-workers mailing list).

sorry, I read it but didn't have time to look into that.
Then I became ill.
Back again.

> There was a suggestion in the mailing list about merging the functionality
> of FvwmStyleCmd.pl into FvwmEvent. That seems to be an interesting idea,
> because some of the features you are planning for FvwmEvent are implemented
> in FvwmStyleCmd.pl (and vice-versa). If I had known about FvwmEvent I might
> not have developed FvwmStyleCmd.pl (in fact, one of my first ideas was to
> create the module using FvwmAudio's code...).

That's where I started from (simplifying & extending FvwmAudio & FvwmAuto,
FvwmAudio generalized into FvwmEvent in a simple manner.)
There were just some "don't make too big steps, right now that the
maintainer changed" comments, so that FvwmAudio was still included in
Brady's first release.

Don't know the state of the development tree, now.
I was just lurking until things had settled and there was a tested, easy to
adopt way to contribute.
 
> 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)
hmm.

I thought of an internal table, which lists functions for each events.
These functions should be entered separately.
It's a royal PITA to have to fetch together all the funcctions to one
commandline.

I had in mind to keep the simple 
	FvwmEvent event function 
binding, where you could have several bindings for the same event, not
knowing of each other.

Each of these functions would be called separately, supplied with the
event-params. 

But then I thought: What if one function kills the window based on it's ID
and name "If Name='Error' destroy $1" while the the other is the simple
autoraise command: "raise $1"

So the second one would have to guard against non-existing windows:
"delay 300; next [windowId=$1] raise"

You see a delay function here, an "if" would be nice. ...
Here I took part in the language discussion, which hasn't led anywhere
AFAIK. :-)

I'd like to boil down FvwmEvent until it's just hooks (if you know elisp)
for functions.
This should be small enough to find it's way into fvwm core.

A general Event binding mechanism would surely help an event based
windowmanager :-)

Then, you can do anything you want with it.

FvwmAuto, FvwmAudio, ... many other things would be one-liners then,
as most emacs lisp hook-functions are.

But this requires the language issue to be finally decided.
If the current language is kept - i.e: we can't decide on any decent
existing language to use -, it's no use adding all that for's, while's
if's that we need.

FvwmEvent could still start an external language interpreter, but that's
pretty slow.

Anyway.

I'd say: let's first settle the language (hopefully multi threaded), 
then things like FvwmEvent come next, if, by then, it's still necessary to
extend it much more, though. 

> Are you already implementing these features?

nope.
No time right now.

I've some years of backlog in my life, right now. :-(

feel free to extend FvwmEvent.
A Parameter passing mechanism for each event would be nice, in any case.

For functions to do something with the parameters, I'd wait for the final
language, though.

My new FvwmAuto distribution would be sth like
	delay 300
	Next WindowID=$1 raise

bound to the focus-change event.
That's already (or was it almost ?) possible with FvwmEvent & the current
language.

But another function would be bound to the raise and focus-change event,
which should cancel all pending auto-raises.

But that's hard with the old language ;-). That's why FvwmAuto still is an
own process (with memory footprint ...) on my machine:

USER       PID %CPU %MEM  SIZE   RSS TTY STAT START   TIME COMMAND
albrecht 10668  0.0  0.3  1464   108  ?  S   15:24   0:00 /homes/albrecht/bin/FvwmAuto

-- 
Albrecht Kadlec
Vienna University of Technology / Department of Automation
----------------------------------------------------------
If a trainstation is where a train stopps,
what happens at a workstation ???
--
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].