Re: Modules and receiving MX_* packets
Thomas Adam writes: > Hi Dan, > > Hope everyone's well. Here in the UK, we're officially allowed out to a pub > and other places. But I'm staying clear of all of those for now -- we're > likely days away from either a local lockdown or a second national wave of > Covid-19. I don't want to be undoing the hardwork I've put in to remaining > healthy! Hi, As well as can be. I'm living by myself so it's maybe tougher than for some others. It helps to be an introvert. At least one pool hall is opening here in NJ next week. I'd really like to get in some practice but even though our numbers in NJ are pretty good, I don't think so, at least for a few more weeks. So, since I'm retired pool, gym, and swimming are my big activities. None of them a good idea right now. I'm spending most of my time fixing things in the house. As you must know, the virus is out of control here. NJ is okay but I don't know how long that is going to last. -- Dan Espen
Re: Modules and receiving MX_* packets
Hi Dan, On Sat, Jul 04, 2020 at 03:19:18PM -0400, Dan Espen wrote: > Thomas Adam writes: > > I've looked at other examples in fvwm such as FvwmAnimate, FvwmAuto, and > > none > > of them are doing anything different to MX_* packet handling, to what I'm > > trying to do. > > > > If anyone has any thoughts, I'd appreciate it. Well, aren't I silly?! :) Turns out, things were working fine, it's just that my matching was off -- I wasn't taking in to account the ordering of the checks I was performing was putting MX_* checks last, so it was matching the non MX_* counterparts. Oops. Fixed now. > I'm the culprit that added module message masks. > My intent that modules could select the messages they want. Which was definitely the right thing to do, Dan. Even now, MX_* messages are sent to all modules, for instance. I know that BroadcastPacket() without a module mask makes sense for some packets, but I'd argue that pretty much every module in Fvwm will only care about those packets set by SetMessageMask() and friends. > I didn't add the MX part, that must have been someone else. > Since the MX flags are in a different word, perhaps modules should be > clearing both words before they set anything. I think you're right here. It probably makes sense to set one large bitmask, as you say, and then deprecate broadcast mode to all modules, except for the signal to kill them. This makes SetMessageMask() much more useful, and reduced the traffic sent down the pipes in the first place. > I'm not sure why this wasn't done with one large bit mask like the style > flags were done. Presumably it was easier to augment what was there, rather than break other modules? That said, I'm not aware of anyone ever having written a Fvwm module which actually links against libfvwm, so I might be wrong. Hope everyone's well. Here in the UK, we're officially allowed out to a pub and other places. But I'm staying clear of all of those for now -- we're likely days away from either a local lockdown or a second national wave of Covid-19. I don't want to be undoing the hardwork I've put in to remaining healthy! Cheers again! Thomas
Re: Modules and receiving MX_* packets
Thomas Adam writes:
> Hi all,
>
> I thought I understood the nature of registering and receiving MX_* module
> packets, but I don't, so I'm hoping someone here will have the answer I'm
> looking for.
>
> I'm writing a C module for fvwm, and am amalgamating the different packet
> types in a table such as the following:
>
> struct fvwm_event {
> const char *event;
> unsigned longflag;
> } fe[] = {
> {"new_window", M_ADD_WINDOW},
> {"configure_window", M_CONFIGURE_WINDOW},
> {"new_page", M_NEW_PAGE},
> {"new_desk", M_NEW_DESK},
> {"enter_window", MX_ENTER_WINDOW|M_EXTENDED_MSG},
> {"leave_window", MX_LEAVE_WINDOW|M_EXTENDED_MSG},
> };
>
> In matching the events against the table above, I've deliberately added in
> M_EXTENDED_MSG for the MX_* events because this allows me to separate out the
> two distinct calls to SetMessageMask(). Hence:
>
> unsigned long non_mx_events;
> unsigned long mx_events;
>
> non_mx_events |= M_ADD_WINDOW|M_NEW_DESK;
> mx_events |= flag & ~M_EXTENDED_MSG;
>
> SetMessageMask(fvwm_fd, non_mx_events);
> SetMessageMask(fvwm_fd, mx_events);
>
>
> I believe I'm right in saying that fvwm expects to receive two distinct calls
> as above.
>
> This is working except that when receiving the packet from fvwm, I'm finding
> that the MX_* events are also matching non-MX events.
>
> For example, just requesting MX_ENTER_WINDOW means I end up receiving an event
> for M_NEW_DESK as well. This makes some sense, since M_NEW_DESK is defined as
> 1<<1, and MX_ENTER_WINDOW is also defined as 1<<1 | M_EXTENDED_MSG. It's
> almost as if I've made a mistake with M_EXTENDED_MSG somewhere. But it's
> implied when using MX_*.
>
> I've looked at other examples in fvwm such as FvwmAnimate, FvwmAuto, and none
> of them are doing anything different to MX_* packet handling, to what I'm
> trying to do.
>
> If anyone has any thoughts, I'd appreciate it.
I'm the culprit that added module message masks.
My intent that modules could select the messages they want.
I didn't add the MX part, that must have been someone else.
Since the MX flags are in a different word, perhaps modules should be
clearing both words before they set anything.
I'm not sure why this wasn't done with one large bit mask like the style
flags were done.
--
Dan Espen
Modules and receiving MX_* packets
Hi all,
I thought I understood the nature of registering and receiving MX_* module
packets, but I don't, so I'm hoping someone here will have the answer I'm
looking for.
I'm writing a C module for fvwm, and am amalgamating the different packet
types in a table such as the following:
struct fvwm_event {
const char *event;
unsigned longflag;
} fe[] = {
{"new_window", M_ADD_WINDOW},
{"configure_window", M_CONFIGURE_WINDOW},
{"new_page", M_NEW_PAGE},
{"new_desk", M_NEW_DESK},
{"enter_window", MX_ENTER_WINDOW|M_EXTENDED_MSG},
{"leave_window", MX_LEAVE_WINDOW|M_EXTENDED_MSG},
};
In matching the events against the table above, I've deliberately added in
M_EXTENDED_MSG for the MX_* events because this allows me to separate out the
two distinct calls to SetMessageMask(). Hence:
unsigned long non_mx_events;
unsigned long mx_events;
non_mx_events |= M_ADD_WINDOW|M_NEW_DESK;
mx_events |= flag & ~M_EXTENDED_MSG;
SetMessageMask(fvwm_fd, non_mx_events);
SetMessageMask(fvwm_fd, mx_events);
I believe I'm right in saying that fvwm expects to receive two distinct calls
as above.
This is working except that when receiving the packet from fvwm, I'm finding
that the MX_* events are also matching non-MX events.
For example, just requesting MX_ENTER_WINDOW means I end up receiving an event
for M_NEW_DESK as well. This makes some sense, since M_NEW_DESK is defined as
1<<1, and MX_ENTER_WINDOW is also defined as 1<<1 | M_EXTENDED_MSG. It's
almost as if I've made a mistake with M_EXTENDED_MSG somewhere. But it's
implied when using MX_*.
I've looked at other examples in fvwm such as FvwmAnimate, FvwmAuto, and none
of them are doing anything different to MX_* packet handling, to what I'm
trying to do.
If anyone has any thoughts, I'd appreciate it.
Kindly,
Thomas
