Subject: Re: FvwmIdent on Tru64 reports interesting X and Y coordinates...

From: Bob Woodside <[email-masked]>
Date: Mon, 01 May 2000 08:25:41 -0400

Jeremie Petit wrote:
> 
> Hello dear fvwm workers,
> 
>   is there anything new about this problem ? Shouldn't it belong to
> Dominik's TODO list before 2.4 ?

	I definitely think it should.

Dominik --

	Would you add this to the TODO? I'm working on the fix right
now...after getting over the shock of doing my first update since
February (gasp! - many fvwm2rc changes needed).

Mike --

	What I'm doing shouldn't clash with any module changes to make them use
the ConfigWinPacket struct. My change will be confined to
module_interface.c, where the data I stuffed into the packet is just
plain wrong.

Cheers,
Bob
--
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: Bob Woodside <[email-masked]>
Date: Mon, 01 May 2000 14:36:58 -0400

Bob Woodside wrote:
> module_interface.c...

	...or so I thought. It turns out that when the layer was added to the
info displayed by FvwmIdent (change to CONFIGARGSNEW in
module_interface.c), the change wasn't reflected in vpacket.h, so I'll
have to add that. The layer was stuck in the old dummy field where the
pre-GSFR flags used to go, which we had left just to preserve the
alignment of the other fields.

Cheers,
Bob

---

From: Michael Han <[email-masked]>
Date: Mon, 01 May 2000 11:53:44 -0700

Previously from Bob Woodside
>alignment of the other fields.

Yes, I've seen that. I started patching over the weekend and when I
got to FvwmIdent, I just pointed the layer to cfgpacket->dummy --
still, it's trivial to get this right by renaming the value layer, I
suppose... So far, no one even cares what it's called, AFAIK.
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
"I am not a number; I am a free man!" - Number Six
--
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: Bob Woodside <[email-masked]>
Date: Mon, 01 May 2000 15:54:52 -0400

> suppose... So far, no one even cares what it's called, AFAIK.

	Oh, as soon as we start using named fields instead of body[x], people
will care. (Well, I will, anyway.)

	I just committed the fix to Jeremie's problem (I hope), which
incidentally replaces the cfgpacket->dummy field with a field called
layer, so your patch will need to be adjusted.

Cheers,
Bob

---

From: Bob Woodside <[email-masked]>
Date: Mon, 01 May 2000 15:55:01 -0400

I just committed a fix that should correct the problem. Give it a try
when you have a chance.

	Larry -- I believe you also reported seeing this problem. Let us know
if this corrects it for you.

Cheers,
Bob

---

From: Michael Han <[email-masked]>
Date: Mon, 01 May 2000 13:27:56 -0700

>will care. (Well, I will, anyway.)

But not before...

>layer, so your patch will need to be adjusted.

Easy enough. I'll probably commit some stuff tonight then.
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
"It is better for people to think your [sic] a fool, than for you to open
your mouth and remove all doubts." - some fool
--
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: Michael Han <[email-masked]>
Date: Mon, 01 May 2000 23:25:21 -0700

>layer, so your patch will need to be adjusted.

So I've had a chance to look at your patch and I guess you've decided
to use a wrapper. But now I've got a question, since FvwmCommand[S].c
has proven a bit more complicated to convert. I see that you've dealt
with dumping an int into a long's space in the outbound packet, but
won't this break the alignment of ConfigWinPacket when orienting its
structure against a *body?

Anyway, FvwmCommandS.c spits packets back out onto its own pipe using
hard-coded values, measured in sizeof(long) units. I'm trying to
figure out how best to do this. I suppose I could always just hard
code the new size in long's (27? 25 struct members, but flags appears
to be 3 long?), but was hoping for something a little more "correct."
Would the rather ugly expression:

sizeof(struct ConfigWinPacket) * sizeof(size_t) / sizeof(long)

be correct? Would something like this be in any way preferable to just
hardcoding the correct number of longs?

Ugh. Has anyone ever noticed that on a 32-bit architecture, the
machine's talking in 4-letter words ;>
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
"Closed Mondays." The Walker Art Center
--
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: Michael Han <[email-masked]>
Date: Mon, 01 May 2000 23:58:13 -0700

Previously from Michael Han
>structure against a *body?

Err, never mind. I was confused and thought that there were int's in
the ConfigWinPacket struct. And so I've answered my other question as
well.
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
"I was thinking of the immortal words of Socrates, who said, "I drank what?"
--
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]