Subject: FVWM CVS: fvwm hippo

From: CVS <[email-masked]>
Date: Fri, 16 Apr 1999 08:23:34 -0500 (CDT)

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	hippo	99/04/16 08:23:34

Modified files:
	.              : ChangeLog 
	fvwm           : module.c module.h 

Log message:
Added backward compatibility for old modules by moving M_ADD_WINDOW and
M_CONFIGURE_WINDOW to new numbers and creating M_OLD_ADD_WINDOW and
M_OLD_CONFIGURE_WINDOW in their place.  Deleted M_NEW_LOOK to make room
as we have now run out of bits for new message types.  If you don't like
this #define DISABLE_MBC (someone else can make this a configure option).

--
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: Matthias Clasen <[email-masked]>
Date: Fri, 16 Apr 1999 15:36:04 +0200

> this #define DISABLE_MBC (someone else can make this a configure option).

Is there any need to use bits for packet types ? Wouldn't different numbers
be good enough ? If so, we shouldn't run out of new packet types soon...

Matthias
 
-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
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: Tim Phipps <[email-masked]>
Date: Fri, 16 Apr 1999 14:43:33 +0100

> be good enough ? If so, we shouldn't run out of new packet types soon...
They all get OR'd together to form a mask the determines which messages
a module wants so they have to be bits. It doesn't have to be part of an
int though.  If we really want a new type we will have to do a GSFR on
the type bits.

Cheers,
Tim.

---

From: Matthias Clasen <[email-masked]>
Date: Fri, 16 Apr 1999 15:58:27 +0200

> int though.  If we really want a new type we will have to do a GSFR on

Ah, that was the piece I was missing: they're ORed together in a mask.
But doing a GSFR there and adding more packets will enlarge all packets,
and what is worse, will make the header variable-sized over time (ie if
enough new packets are added, the header grows)...
Before doing so, it may be worthwhile to check if there isn't some 
cruft among the existing packets. Eg why do we need to separate packets
for WINDOWSHADE and DEWINDOWSHADE. Is any module using them at all ?
And related to this: if there are ICONIFY/DEICONIFY and 
WINDOWSHADE/DEWINDOWSHADE packets, why don't we have the same information
for maximization ?

Matthias

---

From: Tim Phipps <[email-masked]>
Date: Fri, 16 Apr 1999 15:09:32 +0100

> But doing a GSFR there and adding more packets will enlarge all packets,
Not necessarily.  They only need to be bits for fvwm. In packets they
could be just the number log2(x).  The modules tell fvwm what bits they
want with the Set_Mask command so there is no restriction om the number
of bits there.

Cheers,
Tim.