Subject: FVWM: fvwm

From: "Andrew Renalds" <[email-masked]>
Date: Mon, 6 May 1996 08:55:32 -0500

I am the author of MFM - Motif File Manager.  It is a NeXTSTEP look-and-feel
filemanager for Unix.  I would like to collaborate with the current maintainers
of fvwm to integrate MFM with FVWM to create an easy to use public domain
desktop.  If you would be interested in such a proposition, please contact me.
 If you would like to examine MFM, see:

	ftp.x.org:contrib/desktop_managers/

Some of the things others have suggested to me is:

  - drag-n-drop to/from GoodStuff Applications Launcher
  - dynamic main window menu's
  - GUI interface to build .fvwmrc files

-- 

----------------------------------------------------------------------
Andrew T. Renalds				email: [email-masked]
ABN AMRO Bank, NV				voice: (312) 904-5096
Capital Markets / Treasury Services		fax:   (312) 904-5774
181 West Madison Avenue, # 4030
Chicago IL 60602
----------------------------------------------------------------------

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: <[email-masked]> (Charles Hines)
Date: Wed, 15 May 1996 11:30:58 -0400

Sorry it took so long to respond to this, but that happens
occasionally...

>>>>> "AR" == Andrew Renalds <[email-masked]> writes:

AR> I am the author of MFM - Motif File Manager.  It is a NeXTSTEP
AR> look-and-feel filemanager for Unix.  I would like to collaborate
AR> with the current maintainers of fvwm to integrate MFM with FVWM to
AR> create an easy to use public domain desktop.  If you would be
AR> interested in such a proposition, please contact me.

Well, honestly I don't think I'd make any changes to fvwm to work with
any specific file manager (several reasons: don't want to bloat the
code, don't see where it buys a lot since most individual programs
won't respond to the drag and drop protocols, don't want to have to
support several different file managers with several different drag
and drop schemes, etc), but I'd like to make some suggestions here
that might make it possible from your end only.

Please bear in mind that I don't use any file managers myself, and
have never seen MFM in action.

AR> Some of the things others have suggested to me is:

AR>   - drag-n-drop to/from GoodStuff Applications Launcher

Going with my above statement, I don't think I would ever make
GoodStuff (or rather FvwmButtons, the equivalent in 2.xx) have any
specific drag and drop capabilites.

But I think what might be better is to give MFM it's own toolbar (like
GoodStuff/FvwmButtons), which could perhaps be torn off (or made a
separate program entirely), and add code to MFM to allow it to be
compiled as an fvwm module.

Also, in the not too distant future there will be some modules that
will allow for shell script communication with a running fvwm, and an
idea similiar to that could be used as well (so MFM wouldn't have to
be invoked as a module).

And by building the toolbar into MFM, it would have drag and drop
functionality under any window manager, not just fvwm.  And under
fvwm, it could also possibly perform fvwm specific window manager
functions (much like tkgoodstuff).

AR>   - dynamic main window menu's

There are pseudo facilities to do this now in the 2.xx betas, and will
probably be slightly easier in the next beta (2.0.43) and the first
official release (2.1.0) which should be out shortly after that.

AR>   - GUI interface to build .fvwmrc files

Actually, two of these exist right now that I know of:

    - FvwmConfig, module included in 2.xx, but isn't very good as far
      as I know (that's stated right in the man page - honestly I've
      never even compiled it.  Rob made it before he retired from
      working on fvwm).

    - The Dotfile Generator, which also can create .emacs and .tcshrc
      files.  Never seen it, but I've heard good things about it.
      Check out the official fvwm web page (http://www.hpc.uh.edu/fvwm/)
      for a pointer to it.

Not trying to discourage you from adding one to MFM, just letting you
know that some exist.

Also, if certain little, prefferably generally applicable code changes
or additions to fvwm could make things easier, I may add them.  I did
one such thing for the freeware OFFIX drag and drop protocol (see
http://gutenberg.lcmi.ufsc.br/OffiX for info on that, which I should
probably have a pointer to on the fvwm home page) that allowed client
message events to be passed on from an icon to the program instead of
being ignored, which I thought should probably be done anyways (even
though every window manager that I looked at seemed to just throw that
event out in this case).

Now, I should respond to a related note:

>>>>> "Bryan" == Bryan W Headley <bheadley@[email-masked]> writes:

Bryan, check your sendmail.cf file ^^^^^^^^^^^^^^^^^^ or tell your
provider that they may be munging the mail addresses...

Bryan> Guys,

Bryan> Have been trying to install 2.0.42 on HPUX 9.05. Either the X
Bryan> config files used by imake are totally fried or we're in big
Bryan> trouble.  The files get through including sys/types.h and have
Bryan> the nerve NOT to know what a caddr_t is! (Or couse, HP has
Bryan> these things in there, about three levels deep into #if
Bryan> defined(_HPUX_SOURCE) et al.

I know several people on the mailing list have compiled under HPUX.

Bryan> Next issue: I'm closely associated with the mfm people. (mfm is
Bryan> a very nice desktop manager) What kind of work do you think the
Bryan> two groups should do make these two programs work more
Bryan> hand-in-hand?

See above.

Bryan> One area which seems a "must" is the ability to make a element
Bryan> on the buttonBar be a drag-and-drop receiver.

As you see in my above comments, I don't think it's a must (but that's
just me).

Bryan> In other words, if I drag a file off of mfm and onto a
Bryan> WordPerfect icon on the buttonbar, it'd be nice if WordPerfect
Bryan> could be 'taught' in invoke itself with the name of the file.

This would require coding changes on WordPerfect's part, for it to do
it itself, which is actually different from what you requested.  The
button bar would have to be recoded to recognize the drop, and invoke
WordPerfect with that file passed as a command line parm to it.  The
former would actually have much more functionality, as you could then
probably also drag onto a running WordPerfect...

Bryan> Another feature, which would be neat, but somewhat NeXT-ish,
Bryan> would be the ability for me to grab a binary, say, "NeXs", and
Bryan> move it into the buttonBar, thereby CREATING a new buttonBar
Bryan> icon for NeXs".

Good for a simple linear button bar, but the latest version of
FvwmButtons is more powerful layout wise.  Besides, how would you tell
whether or not what you were dragging was meant to be a new button or
a parameter to another exec?  And where to get the icon?  This would
be much simpler in an MFM specific toolbar (like I discussed above), I
think.

Bryan> What do you folks think? We have a fine window manager and a
Bryan> fine desktop manager.  What makes windowing environments
Bryan> successful is that the two work together in synergy.  To be
Bryan> able to do this at the free(d)ware level on X would be a
Bryan> tremendous benefit to everyone.

As I said, I actually don't see where it buys a lot, since not many
programs would recognize the drag and drop protocol themselves.  That
would be the real win (for those that like and use drag&drop).  But
until one becomes a real standard...

Chuck

*******************************************************************************
Charles K. Hines <[email-masked]>
IBM Logic Synthesis developer [BooleDozer (TM)]
Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]

IBM Internal email:                        "Go back to sleep, Chuck.  You're
  [email-masked],              just havin' a nightmare--of course,
  HINESC at FISHKILL, HINESC at FSHVMFK1    we are still in Hell." Gary Larson
*******************************************************************************
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked] (Albrecht Kadlec)
Date: Wed, 15 May 96 21:22:49 +0200

>>>>> Charles Hines writes:

Chuck> Going with my above statement, I don't think I would ever make
Chuck> GoodStuff (or rather FvwmButtons, the equivalent in 2.xx) have any
Chuck> specific drag and drop capabilites.
don't need to.
FvwmButtons isn't interested in the information, which is passed from Mfm
to the application. It just might forward it (Black Box!).

Chuck> But I think what might be better is to give MFM it's own toolbar (like
Chuck> GoodStuff/FvwmButtons), which could perhaps be torn off (or made a
Chuck> separate program entirely), and add code to MFM to allow it to be
Chuck> compiled as an fvwm module.

Chuck> Also, in the not too distant future there will be some modules that
Chuck> will allow for shell script communication with a running fvwm, and an
Chuck> idea similiar to that could be used as well (so MFM wouldn't have to
Chuck> be invoked as a module).

Chuck> And by building the toolbar into MFM, it would have drag and drop
Chuck> functionality under any window manager, not just fvwm.  And under
Chuck> fvwm, it could also possibly perform fvwm specific window manager
Chuck> functions (much like tkgoodstuff).

I'd vote for an mfm feature to create one or more toolbars with drag &
drop, which I could swallow from FvwmButtons then.
No hassle for Chuck who is already quite overloaded, no long response times
on feature requests from the mfm people, no mfm specific drag & drop target
functions in fvwm(buttons). 

Chuck> There are pseudo facilities to do this now in the 2.xx betas, and will
Chuck> probably be slightly easier in the next beta (2.0.43) and the first
Chuck> official release (2.1.0) which should be out shortly after that.

can't wait to see them.....

Chuck> Actually, two of these exist right now that I know of:
[...]

I guess, you can't do all the tweaks from a configuration generator, but
it'd certainly help novices/occasional users.

well a combined desktop/file manager is no new idea.
I guess it started with Apple, went on to Norton Desktop for Windows, PC
Tools Desktop for Windows, Windows 95 has then more or less just killed the
market for these afterproducts for Windoze.

In general I think, it's a good idea, but I don't know how to have fvwm2 &
mfm part one root window in a smooth manner (- without bounding boxes:
"You can't put that file icon there, because it's the fvwm side of the root
window !!!"), without them being integrated.
Even if mfm were a module for fvwm, it'd just have some sort of transparent
window (rectangular!) in which to place it's icon. No placing icons
anywhere else.

(might be that I overlooked sth. here, I've some sort of "incompleteness"
feeling)

Would certainly be nice. One way was desribed above: mfm button bar, maybe
swallowed by FvwmButtons.

Maybe sth like this already exists (roughly):
Create a button which executes the command "wordperfect `print_selection`":
you just mark the file with the mouse and press the button.
Mfm could always put the highlighted file in the pastebuffer automagically,
so that you just click on the filename and then on the button.
(I know the command isn't print_selection, but `p?? -xyz`, but I can't
remember now.)

It's not directly drag`n`drop, but it`s close, and fvwm shouldn`t support
multiple drag`n`drop interfaces.

It might be different, if mfm and other file managers could come to terms
with a single drag'n'drop interface, but maybe not. ;^)

Chuck> This would require coding changes on WordPerfect's part, for it to do
Chuck> it itself.
If wordperfect recognized a file dropped onto it's icon, it'd still do so,
if swallowed in FvwmButtons (maybe via an own iconmanager - ewww, that
needs some smoothing), or in a special iconbox, filled with drag'n drop
receivers, swallowed into FvwmButtons (I like the latter MUCH less).

This should be doable quite easily - am I right ?
(I guess our Capacity on these issues is still with The Green Men, is he?)

I do second that, but it would mean either integrate, or use existing
interfaces. (Maybe with slight extensions, as long as they are generally
useful extensions. No one wants to see mfm-specific functions bloat fvwm,
when most people don't use them. But then I think most people would use the
file manager part, if they were integrated. It's maybe just a matter of 
"I don't need no steenking Windoze" ?)

Chuck> As I said, I actually don't see where it buys a lot, since not many
Chuck> programs would recognize the drag and drop protocol themselves.  That
Chuck> would be the real win (for those that like and use drag&drop).  But
Chuck> until one becomes a real standard...

It shouldn't even bother fvwm, which drag'n'drop interface the application
uses. Just make sure, FvwmButtons can swallow an iconified application and
passes on all events from the icon to the application.

If WordPerfect and Mfm can agree on an interface to use, fvwm shouldn't
keep them from communicating.

just my 0.02$,
albrecht
-- 
Should I stand out in the rain
Do you want me to make a daisy chain for you
I'm not the one you need -
What do you want from me	-- Pink Floyd
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: "Bryan W. Headley" <bheadley@[email-masked]>
Date: Thu, 16 May 1996 21:47:24 -0500 (CDT)

> compiled as an fvwm module.

That's been done (known as the "devices" window in mfm), but it's currently
not detachable. The way it works is, you drop something on one of the targets,
and a script of your own devising is run. So, a "device" like the printer can
in fact run lpr %s, etc., or a "device" called WordPerfect can invoke itself
with dropped file as the document (no special ability of WP required)

I'd hate to be forced to a separate toolbar, only from the standpoint
that you have Button/GoodStuff icons, and the mfm icons competing for space.
If they were swallowed, then there's the possibility that the drag-n-drop
icons would be shrunk too small to be usable. And besides, you'd still 
potentially have two icons for the same app, which is a royal pain.

What we got now are icon buttons which are sensitive to depressing, and
evoke the action specified in the Buttons/GoodStuff region of the .fvwm2rc
file. What I am seeing is extending that, so we have a depress action specified,
and a file-drop action.

At that point, there's the issue of not wanting to support one drag-n-drop
protocol over another. I've not done of survey of the others that are out
there, but certainly I can look at what it would take to grab Andrew's
drag-n-drop library, make it into a fvwm module (so you provide everyone
equal opportunity for support), and go from there. The question is,
(since I'm a user of 1.2.4r and not very familiar with 2.x yet), I know
the window manager can talk to modules; are modules allowed to talk to 
other modules? Especially, can their advising the other module of something
be considered an "event"?

And if they are, would you folks like to have more than one action type
associated with the FvwmButtons module?

> provider that they may be munging the mail addresses...
 
Thanks. I think I got that one licked.

> I know several people on the mailing list have compiled under HPUX.
 
Yeah, and we got 1.2.4r running happily, too. I just never saw such wholesale
disregard of things in the system header files. I HAVE to figure out how
our imake configuration files did that... :-(

> until one becomes a real standard...

Actually, Andrew's was published a while ago in the X Resource, so if
nothing else, there might be some folks out there working from his paper.

As with everything else, standards are meant to be ignored until something
"killer" arrives, who may not even feature that standard prominently, but
still compel folks to go that route. OLE is a classic of that paradign :-)

-- 
-------------------------------------------------------------------
Bryan W. Headley                       Home:    [email-masked]
211 East Pineview Drive                Office:  [email-masked]
Round Lake Park, IL 60073, USA	       Voice:   847-740-1446
                     "Better Living Thru Panic"
-------------------------------------------------------------------
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].