Subject: module incorporation(s)

From: Nadim Saeed <[email-masked]>
Date: Fri, 23 Apr 1999 14:53:16 -0700 (XXX)

I know there _was_ talk about cleaning up the module directory (not in
the literal sense of moving and updating files, but in the "incorporation
sense"), was there any consensus ?

For example:
  FvwmButtons   vs. FvwmWharf     vs. tkgoodstuff    vs. FvwmGoodStuff
  FvwmWinList   vs. FvwmIconMan
  etc..

What I'm getting at is this, could we see what feature(s) one module has over
the other and try to have one module that would incorporate _all_ the
feature(s).  For example, I think you can accomplish everything you want with
FvwmIconMan vs. FvwmWinList (keep in mind that I'm a FvwmWinList user) except
for two things that I know of:

  a. FvwmIconMan does not allow one to have the title names be
     centered-justified on the button versus left-justified (ie. one
     can't get the same FvwmWinList look from FvwmIconMan).

  b. FvwmIconMan shows a window is iconified using a button-like indicator
     instead of parentheses.  In FvwmWinList "  title1  " means non-iconified
     while " (title1) " means iconified.

Could FvwmIconMan be modified to accommodate the above noted (and other) minor
changes ??  I think there is virtue in doing that -- redundancy ought to be
avoided and frowned upon :-)

I've never used FvwmWharf but I wonder whether the changes are cosmetic as
well.  Even if they are a bit more beefy, couldn't you include all of
FvwmWharf's/tkgoodstuff's features into FvwmButtons ??

Should I enter a bug/enhancement entry ?  Thoughts ?

Thanks

 - Nadim (please cc replies; I'm an archive reader :-)
--
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: Steve Robbins <[email-masked]>
Date: Mon, 26 Apr 1999 16:39:04 -0400 (EDT)

[ I'm re-sending this because the first time I got a "relaying denied"
bounce message! ]

On Fri, 23 Apr 1999, Nadim Saeed wrote:

> feature(s).

This does happen.  Dominik merged a couple modules into FvwmRearrange, and
Dan replaced FvwmTalk with a form of FvwmForm.  I think the only thing
stopping this from happening is that someone has to sit down, go carefully
through the code of both modules, and combine them. 

> avoided and frowned upon :-)

I heartily agree with the remark on redundancy and repetition.

If someone submitted a clean patch merging the features of one module into
another, I suspect it'd be applied in a second.

> FvwmWharf's/tkgoodstuff's features into FvwmButtons ??

It has been suggested that Wharf be dropped in favour of Buttons, but one
or two people pointed out something that Wharf has and Buttons lacks.

Ditto for IconMan vs. IconBox.

Other modules that seem to be redundant:

** FvwmAudio -- hasn't this been totally superceeded by FvwmEvent?  The
leading comment suggests it is a direct descendent of Audio:

 * renamed & cleaned up so that FvwmEvent (TaDa !!) is a general event
   handler module.
               -- 21.04.98 Albrecht Kadlec ([email-masked])

** FvwmSave and FvwmSaveDesk -- how do these compare/interact with the
session-management stuff?  Superficially, they seem to have similar goals.
Is that true?  I haven't looked carefully at this, but I assume the
session-guy did.  (Matthias?)

--
Steve Robbins                              <[email-masked]>

When love is gone, there's always justice.
And when justice is gone, there's always force.
And when force is gone, there's always Mom.

---

From: [email-masked]
Date: Tue, 27 Apr 1999 09:12:35 -0400 (EDT)

> or two people pointed out something that Wharf has and Buttons lacks.

Just a note here to point out that while tkgoodstuff can probably
subsume most of the functionality of FvwmButtons or FvwmWharf (and even
FvwmIconMan) it uses a completely different configuration language than
other modules (tcl/tk), and as such, the other ones cannot really
replace it.  For another thing, it has a completely GUI-driven
configuration.

Actually, it would be "neat" if Fvwm2.x had a GUI-driven configuration
capability, but always such a suggestion gets bogged down into
implementation details:  language (tcl/tk?  python?  Java?  perl? 
Scheme?) and environment (GNOME?  KDE?  CDE?), to name a couple.

I don't think this will ever be resolved to everybody's liking.
 
tkgoodstuff is written in tcl/tk, so the choice of implementation
language is moot.  This is OK with tkgoodstuff, since it remains an
"external Fvwm2 module."

-- 
Larry Gensch					      [email-masked]

I would really appreciate it if the login command had a better sense of humor.

---

From: [email-masked] (Paul D. Smith)
Date: 27 Apr 1999 10:11:51 -0400

%% [email-masked] writes:

  lg> Actually, it would be "neat" if Fvwm2.x had a GUI-driven
  lg> configuration capability, but always such a suggestion gets bogged
  lg> down into implementation details: language (tcl/tk?  python?
  lg> Java?  perl?  Scheme?) and environment (GNOME?  KDE?  CDE?), to
  lg> name a couple.

Well, we're moving that way now with the work Dan has been doing; he's
using FvwmForm scripts as the "language".  Check out what happens if you
start the latest CVS fvwm with no .fvwm2rc or system.fvwm2rc files
available...

The environment isn't really relevant here, is it?  If you have GNOME
apps (that set the GNOME attributes on their windows) you get GNOME
support... I assume that if/when we support the others similar things
will happen.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
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: Steve Robbins <[email-masked]>
Date: Wed, 28 Apr 1999 22:12:03 -0400 (EDT)

>                -- 21.04.98 Albrecht Kadlec ([email-masked])

I looked at the man page, and found a notice that dates from 2.0.47d: 

	NOTICE
	       FvwmAudio has been superceded by FvwnEvent and is no longer
	       supported. Please start using FvwmEvent as soon as possible.

Then I searched the mailing list archives, and found a discussion from the
end of July/98 about dropping FvwmAudio.  It seems that FvwmAudio was
dropped in 2.0.47c.  Three days later 2.0.47d came out with FvwmAudio
restored.

As far as I can see, the issue was that FvwmEvent did not support being
aliased.  To quote Dan E:

	FvwmEvent doesn't support being invoked with an optional second
	argument as a substitute to being sym-linked.

	The code to do so is quite simple, if argc = 7, use argv[6] as the
	program name.  FvwmForm is a good example.

	<http://www.hpc.uh.edu/fvwm/archive/9807/msg00000.html>

Now, it looks to me like FvwmEvent never *did* get this code added!  It
also looks like it is a simple matter of inserting two lines in main():

    if ((s=strrchr(argv[0], '/')))      /* strip path */
        s++;
    else                                /* no slash */
        s = argv[0];
+   if (argc>=7)                        /* if override name */
+       s = argv[6];                    /* use arg as name */

Is that really all it takes?

If so, how about we make the change, ditch FvwmAudio, and fix up
sample.fvwm2rc not to refer to it anymore?

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 29 Apr 1999 15:26:00 +0200

> sample.fvwm2rc not to refer to it anymore?

I have no objections. Of course users shouldn't be required to
completely rewrite their config, so if there is a simple way
like aliasing FvwmEvent to FvwmAudio...

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: Steve Robbins <[email-masked]>
Date: Thu, 29 Apr 1999 10:44:04 -0400 (EDT)

> like aliasing FvwmEvent to FvwmAudio...

Good point.

I believe that a symlink FvwmAudio -> FvwmEvent would do the trick.  I can
do the Makefile magic, but I can't test it, as I have no way to play
sounds...

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 30 Apr 1999 12:04:22 +0200

> do the Makefile magic, but I can't test it, as I have no way to play

I can test this if someone sends me a configuration for FvwmAudio
(I never used it myself).

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-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: Dan Espen <[email-masked]>
Date: Fri, 30 Apr 1999 10:19:55 -0400

> (I never used it myself).

*FvwmAudioPlayCmd audioplay
*FvwmAudioDir $HOME/audio
*FvwmAudio startup doh.au
*FvwmAudio shutdown Goodbye.au
*FvwmAudio unknown doh.au
*FvwmAudio add_window drip.au
*FvwmAudio focus_change tap2.au
*FvwmAudio destroy_window beep_drop_of_water.au

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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: Fri, 30 Apr 1999 10:20:23 -0700

Previously...
>*FvwmAudio destroy_window beep_drop_of_water.au

IIRC, this won't work right now... It could probably be made to work,
but I'm pretty sure that there's at least a little bit of twiddling
that needs to be done to convert from the above to something that'd
work in FvwmEvent... The situation's not helped by a couple
documentation errors in the manpage, which are remnants from FvwmAudio
I think, that are no longer true of FvwmEvent... Most importantly in
the above, the PlayCmd doesn't exist... You now need to do something
like

FvwmEventCmd Exec exec audioplay

And there's simply no equivalent to FvwmAudioDir...

This is all based on memories from a couple months ago... I submitted
a documentation patch way back to fix all these doco bugs, but it
seems to have been dropped or partially applied.
-- 
[email-masked]
I will not belch the National Anthem
 - The collected wisdom of Bart Simpson
--
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]