Subject: question about window_flags

From: Michael Han <[email-masked]>
Date: Wed, 03 May 2000 09:47:50 -0700

So I'm somewhat stuck trying to convert FvwmCommand and FvwmDebug
because both had the ability to display all the flags in their output
stream. I'm not sure how to make them read the new window_flags
structure without a lot of tedious code. FvwmCommand used to ouput a
line per flag member (if -i >1 and -F == 2) but this was easy because
it would just iterate over the flags ulong checking bits one by one.
FvwmDebug used to display the flags ulong as a hex representation.

I'm not sure that this is something we want anymore. If it is, the
FvwmCommand case is easy enough to handle, but involves lots of use of
the flag testing macros and lots of code. The FvwmDebug case is still
hard for me because I don't know of a way to treat a struct of
bitfields as an aggregate that doesn't cause compiler whining. I guess
I could change this behavior in FvwmDebug to something that is more
workable.

Anyway, has anyone got any ideas on how to proceed here?
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
"If you lend me some money, it'll be my treat."
--
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: Wed, 03 May 2000 14:04:04 -0400

Michael Han wrote:
> the flag testing macros and lots of code.

	There really isn't any alternative: within the new flags structure C
doesn't allow you to make assumptions about the ordering of bytes within
a word, or words within the aggregate structure (it's now longer than a
long int on 32-bit boxen), or even the ordering of bits within a byte.

	It's a trade-off. The majority of the code that references the flags is
easier to read and to maintain with the new structure.

>                                              The FvwmDebug case is still
> bitfields as an aggregate that doesn't cause compiler whining.

	There isn't; and if someone thinks of a way, chances are it'll Do the
Wrong Thing.

	As a side note, the reason these modules weren't caught during the GSFR
is that they used these low-level techniques to reference the flags.
Therefore they never caused any compiler errors when the old defines
were removed, and we overlooked them. We fixed what whined, and missed a
few things. I'm glad you're making the effort to go through all the
modules. It's tedious (yeah, you noticed that too, huh?), but needed.

Cheers,
Bob

---

From: Michael Han <[email-masked]>
Date: Wed, 03 May 2000 12:42:57 -0700

Previously from Bob Woodside
>easier to read and to maintain with the new structure.

Well, fair enough. I've added the code to FvwmCommand and all in all,
it wasn't too painful. The wonders of a good editor with a semi-robust
regex library... I'll commit my work on FvwmCommand pretty soon.

>	There isn't; and if someone thinks of a way, chances are it'll Do the

I thought so. So now I have a bit of a dilemma. There's no way to
mimic the old FvwmDebug behavior WRT flags. I could add a complete
flagging approach, but that would perhaps be overkill? 64 lines of
output per M_ADD_WINDOW/M_CONFIGURE_WINDOW packet is pretty
excessive, no? Perhaps it could be made a runtime option like in
FvwmCommand. Or perhaps even by passing the arg as part of the module
name. I.e., Module FvwmDebug displays no flag data; Module
FvwmDebugVerbose displays full flag data. Anyway, I very much doubt
FvwmDebug is of use to anyone besides fvwm-workers. Perhaps even an
#ifdef would suffice.

Anyway, beyond my basic ConfigWinPacket conversion in FvwmDebug, I'm
contemplating the following other changes, which I've already made: 1)
merge list_{add|configure} and list_old_{add|configure} into single
functions... No reason for all that duplicate code, IMHO; 2) Can pass
an output file name as argv[7] rather than being forced to accept
output to stderr. Of course, then you can't use module aliasing.

>modules. It's tedious (yeah, you noticed that too, huh?), but needed.

Yeah, I've noticed that. But it's actually not that bad. And it gets
me more familiar with things without requiring too much intelligence
on my part... ;>
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
"And, just like it should in all stories about philosophers, it ended
up in complete chaos." - Richard P. Feynman
--
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: Dominik Vogt <[email-masked]>
Date: Thu, 4 May 2000 04:28:49 +0200

> regex library... I'll commit my work on FvwmCommand pretty soon.

I suggest writing a perl script to generate the necessary code.
In fact I was already thinking about something like this.  What
I really need in my daily work is a way to dump window structures,
the Scr structure, the stack ring and a window list to stderr
without adapting the code every time one of these structures
changes.  Printing flags would be just a subset.

> FvwmDebugVerbose displays full flag data.

I think a startup option is enough.

> Anyway, I very much doubt

No.  what if we ask somebody to provide us the output and (s)he
hasn't compiled it in?

> functions... No reason for all that duplicate code, IMHO;

Cleaning up duplicate code is always a good idea.
BTW, why are there *two* modules that print the same information,
i.e. Fvwm debug and FvwmCommand with the -m option?  I suggest
the following changes:

 a) Remove the -m option from FvwmCommand.
 b) Remove all module specific code from FvwmCommand.
    FvwmCommand can simply be an executable that is
    called from the command line only (e.g. FvwmCommand.bin)
 c) Write a wrapper script ("FvwmCommand") that acts as a module
    but throws away the module specific arguments and calls
    FvwmCommand.bin
 d) Move all packet printing code to FvwmDebug.

> 2) Can pass

What purpose would that serve?  With any decent shell you can
easily redirect stderr into a file:

  $ FvwmCommand 'my_fvwm_func' 2> .FvwmCommand.log

BTW, why should anybody use an alias? There are no module
options that FvwmCommand or FvwmCommandS use.

> me more familiar with things without requiring too much intelligence

I'm happy that you see it this way.  If we hadn't so many
people that are familiar with the module interface I'd have
to learn it myself :-)

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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: Sun, 07 May 2000 14:36:19 -0700

Previously from Dominik Vogt
>changes.  Printing flags would be just a subset.

Hmm, I'm seeing what you mean, but I'm not sure I can do it.

>[moved Dominik's reply further down]
>
>> 2) Can pass

I was referring to FvwmDebug here. Based on my understanding of how
modules get started, you can't do things like output redirects when
you start a module, hence it needs to be handled otherwise, no? As far
as aliasing goes, I see no reason anyone would use it -- I only
mention it because it's fairly standard behavior for modules to
support argv[6] as an alias.

> d) Move all packet printing code to FvwmDebug.

I'm not sure I understand what you propose. FvwmCommandS still has to
run, right? If we throw away the listening capability in FvwmCommand,
what you'll end up with, basically, is a wrapper that knows how to
talk to the file descriptors that FvwmCommandS sets up. We could
conceivably make it a single pipe that's one way into FvwmCommandS to
simplify further. I see no reason to continue to support FvwmCommand's
debug features, but I'm not sure what else you're proposing.
-- 
[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: Dominik Vogt <[email-masked]>
Date: Mon, 8 May 2000 07:45:47 +0200

> debug features, but I'm not sure what else you're proposing.

Did you notice that FvwmCommand itself can be started as a module?
Usually you start it from the command line and then it talks with
FvwmCommandS.  But if you start it as a module with '-m' it talks
to fvwm directly to dump module packets.  This is exactly what
FvwmDebug does, i.e. duplicate code.

Bye

Dominik ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-3883, [email-masked]
--
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, 08 May 2000 00:22:15 -0700

>FvwmDebug does, i.e. duplicate code.

? I don't see where in the code it can do that. When I try it it just
complains that it has no FDs and exits. Which is perfectly alright, I
think. Can FvwmCommand be invoked as a module? I thought there was a
strict separation: FvwmCommandS must start and must be started as a
module. FvwmCommand must be invoked at the commandline and talk to
FvwmCommandS...

In any event, I'm all for stripping out all the code in FvwmCommand
except that which is used for sending messages to fvwm via an existing
FvwmCommandS.
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
There is too much blood in my caffeine system
--
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: Dominik Vogt <[email-masked]>
Date: Mon, 8 May 2000 10:04:54 +0200

> module. FvwmCommand must be invoked at the commandline and talk to

Sorry, you're right, I must have been looking at the wrong source file.
FvwmCommande can *not* be invoked as a module.

Bye

Dominik ^_^