Subject: Re: FVWM: Proposal on modules/languages

From: [email-masked]
Date: Mon, 4 May 1998 9:18:00 +0100

Brady Montz <[email-masked]> writes:

> This discussion on extension languages is quickly going to descend into
> chaos. I see the following desires:

[...]

> I suspect there is wide agreement with these two points:
> 
> 1. Fvwm's internal configuration language could be changed for the better.
> 2. If we add a new language, it should be done as a module. Most likely
people
>    would want this module to be as tightly coupled to fvwm as possible for
>    speed, using whichever dlopen, mmap, and threading facilities available
on
>    the various architectures. 

So far we agree...

> So, my proposal:
> 
> Lets table the discussion on tcl/perl/python/java/icon/scheme/... and focus
on
> improving the internal language and the module interface(s).

Here we disagree. I would prefer to abandon the current configuration
language as a basis for the future development, adopt an existing
configuration language, and then add fvwm functionality/API to this
new language.

I we for some reason want to be backward compatible, we will
automatically limit ourselves to a small number of languages, but we
will keep the current user group happy.

> Both are
> necessary before we dive into grafting on an interpreter, and it's quite
> possible that if done right, they will obviate the desire for such a
grafting.

I would much prefer to use an existing configuration language if at
all possible. Inventing a new language usually means the product will
be delayed quite a bit longer than necessary. And why not take that
complication out of the project?

> (I argue that if we add an interpreter, we will have to change the internal
> language for two reasons: it's likely we will want to refer to services
> provided by modules written in language X in the .fvwm2rc, and we might wish
> to unload some of the bloat in the internal language to language X.)

I don't understand this, sorry.

/tonny

--
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: Manfred Bartz <[email-masked]>
Date: 04 May 1998 21:08:20 +1000

[email-masked] writes:

> >    people would want this module to be as tightly coupled to fvwm as 
> >    possible for speed, using whichever dlopen, mmap, and threading 
> >    facilities available on the various architectures. 

If it would lead to a cleaner interface, I would have no objection to
making the interpreter part of the fvwm core.

> configuration language, and then add fvwm functionality/API to this

Exactly.  The current configuration language is a hodge-podge of
compromises and kludges.  Fvwm still is the leading, most configurable 
WM around and I don't want to take away from the considerable
achievement fvwm still represents.  
However, I very strongly feel that any new and significant development 
should not be compromised by a misplaced desire to retain compatibility 
with existing config files.  We probably should look at easing the
transition by providing a conversion tool, and that would not require
a compromise.

> will keep the current user group happy.

Anybody wishing to stay with the current fvwm2 can do so anyway.
Fvwm2 is a mature, powerful product and will still be relevant for
quite a few years even if new development ceases.

> complication out of the project?

Absolutely.  There are too many configuration languages as it stands.
Creating a new one would be madness.

So, maybe we should re-focus on which language would be most suitable.

Scheme is already being implemented in the fvwm-derived ``scwm''.
Since we don't want to re-invent any wheels, anybody wanting scheme
should look at contributing to scwm. 

Questions: 

1. What would we want to do with the configuration language?

2. How often would we use it.

3. What kind of language would people find most approachable? 
   (Especially if it's used only occasionally?)

Comments?  Other questions to ask?

Cheers
-- 
Manfred Bartz <[email-masked]>
--------------------------------------------------------
"No! Try not.  Do, or do not.  There is no try." -- Yoda
--
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: Brady Montz <[email-masked]>
Date: 04 May 1998 12:51:08 -0700

OK, these are good points (I'm leaving the followup gunk at the bottom of my
post for those who don't have threading mailreaders). 

I see three main choices:
1. Keep the current architecture.
2. Add an SOL (some other language) to FIL (fvwm's internal language).
3. Replace FIL with SOL.

I personally would prefer #3. (thanks to Manfred and tonny for pointing out
the costs of my attempt at compromise). But my desire for compromise remains,
since there are many people who use fvwm that don't need a fat interpreter in
the executable. As for #2, I don't like that at all due to the need to
partition functionality between FIL and SOL(s).

The logical reply to that is to use swig, so people can use whichever
interpreter they wish. It probably is a simple matter to implement FIL (or
something like it), as a swigable thing for those who prefer the status quo.
I immediately see two hurdles:

1. Currently modules tell fvwm what to do by sending FIL strings to fvwm. This 
   won't work anymore, since the module writer can't know beforehand which
   language fvwm is going to be using. The solution to this is to probably
   give the modules the swig interface to fvwm as well. 
2. Once we have an interpreter running inside of fvwm, it will probably have
   it's own share of state. It's likely modules will want to
   read/write/execute those (note that this is the modules talking to the
   interpreter, not fvwm as in #1). I don't see any way to prevent modules
   from developing dependencies on the SOL here, but as long as we have a good 
   enough mechanism to support #1, modules should only talk to the SOL when
   then absolutely have to, so that's OK. 

Then there is the problem that I currently have plenty of people sending me
bug reports which include there .fvwm2rc files. It's hard enough getting these 
.fvwm2rc's to work right now. I'll probably go mad if people start sending me
.fvwm2rc's which require me to install tcl version x.y to fix their bug.

So, if we support:
a. FIL only, we frustrate people who want to do things in a real language (if
only I could write a function to do ...)
b. 1 SOL, then we better make sure we don't pick something which many people
   hate. 
c. 2 or more SOL's, then I don't see any way to avoid doing lots of work and
   dealing with logistical headaches.

So, proposing that we choose #b, replacing FIL with one SOL, we're looking at
Manfred's questions:

> Comments?  Other questions to ask?

I see two other questions:

4. How many resources are we willing to use, both in code bloat and requiring
   people to install whichever files language X needs to operate.

5. How nicely does language X lend itself to embedding.

My answers:
1. I want to be able to set the usual fvwm options (a=b type statements),
   maintain state about windows (so I can write functions to do things like
   SmartPlacement), and have real functions. I'd like to have it support a
   module interface, and multiple namespaces (ala python) so that I can
   write modules in that language which won't have namespace collisions with
   each other. Multithreading is probably a reasonably requirement.

2. I would probably do a LOT of programming in such a language, some of it
   released as modules.

3. guile or python

4. Either guile or python could be made to work with a minimal installation of 
   stuff, but the simplest thing for people to do is install the whole damn
   thing. Probably true for any interpreted language.

5. Both guile and python were designed from the beginning to be embedded. It's 
   probably fairly easy to map the window manager data structures onto python
   objects and vice versa. Guile might be more of a stretch.

Some URLs of potential interest:

http://www.python.org
http://www.red-bean.com/guile/
http://www.sun.com/sunworldonline/swol-10-1997/swol-10-scripting.html
http://www.lib.uchicago.edu/keith/crisis/

-- 
 Brady Montz
 [email-masked]

---

From: Bryan Bayerdorffer <[email-masked]>
Date: Mon, 04 May 1998 15:25:47 -0500

I have XEmacs 20.4 and fvwm 2.0.46 installed on both a Linux 2.0.30 system with
the Accelerated X 3.1 server, as well as on a Sun Ultra 2, Solaris 5.5.1, and
the (ugh) Solaris openwin X server, because MIT X has no drivers for the
Creator frame buffer.  The .emacs, .xemacs-options, and .fvwm2rc files in both
cases are identical, modulo some pathnames to xpm files and such.

The Linux setup works fine, of course.

On the Ultra, when popping a new XEmacs frame with gnuclient, fvwm switches to
the desk where the FIRST XEmacs frame was mapped, regardless of what the
current desk is or where the other frames are.  This began happening after I
switched from XEmacs 19.15 to 20.4; nothing else was changed.

I can't find anything in any docs, FAQs or the elisp source that gives me a
clue to stopping this highly annoying behavior.  Any ideas?

Thanks,
Bryan

-- 
 .. ..-. ..- -.-. .- -. .-. . .- -.. - .... .. ... --. . - .- .-.. .. ..-. . !!
Bryan Bayerdorffer         [email-masked]                [email-masked]
                   (Wit's End Computation Center)           (Analog Devices)
+1 512-427-1063  +1 512-427-1059 (fax)     Bar code: || | |||| || | ||  || ||||
PGP key via finger     O-     Rock on completely with some brand-new components

Problem:  "Number three engine missing."
Solution: "Engine found on right wing after brief search."

---

From: brian moore <[email-masked]>
Date: Mon, 4 May 1998 15:15:35 -0700

> partition functionality between FIL and SOL(s).

I agree with #3, but I'm not ready to say that Perl, Python, Scheme, or
Tcl is the language.  I don't see any of them as being 'configuration'
languages.  Sucking in menus by doing:

%RootMenu = (
    'Title'  => 'Toys',
    'Xterms' => (
               'regularterm' => 'xterm',

(etc) would be sort of nifty, but does that really belong in a WM?  (And
I'm beginning to think it's nifty enough that I should play with
FvwmPipe or X11::Fvwm and see if I can hack something like that....)

It seems to me that adding a few hundred k to the size of fvwm for
this is probably not useful in the core, so what functions are missing
from the module interface that inhibit doing this in modules?

-- 
Brian Moore                             Kill A Spammer For Jesus
Sysadmin, C/Perl Hacker, Usenet Vandal 
--
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: "Patrick K." <[email-masked]>
Date: Mon, 4 May 1998 19:02:59 -0700 (PDT)

> FvwmPipe or X11::Fvwm and see if I can hack something like that....)

   Now I don't want to yelled at :)   but how about taking
   the approach of HTML tags?  What you typed up there got
   me thinking, what if we could have tags for each menu and
   menu items?  Like:

   <MENU NAME="Root-Menu">
      <MENUITEM   NAME="Xterm"
                  ACTION="xterm -T $LOGNAME@$HOSTNAME">

      <SUBMENU    NAME="Utils">
         <MENUITEM   NAME="Top" ACTION="rxvt -T Top -n Top -e top">
         <MENUITEM   NAME="Xload" ACTION="xload -fg green -bg black -hl red">
         <MENUITEM   NAME="Calculator" ACTION="xcalc">
      </SUBMENU>
      <!--
       ! and so on ... -->
   </MENU>

   Same with FvwmButtons... you could use the syntax used for
   HTML tables (ie. <TABLE> tag).

   Or does this sound totally stupid? :)

   Sleep on it guys....

Patrick ...
[email-masked]

---

From: Brady Montz <[email-masked]>
Date: 04 May 1998 20:46:38 -0700

> Sometime in the late 1900s it was said:
..
>          <MENUITEM   NAME="Calculator" ACTION="xcalc">

It's simpler (and parsers already exist) to just do this the scheme way:

("Root-Menu"
  ("Xterm "xterm -T $LOGNAME@$HOSTNAME")
  ("Utils"
    ("Top" "rxvt -T Top -n Top -e top")
    ("Xload" "xload -fg green -bg black -hl red")
    ("Calculator" "xcalc")))

Or with python, just replace () with [] and add some commas; perl and tcl are
basically the same.

If you want to have more flexibility, then you can have classes for menu,
submenu, and menuitem, and use constructors (example in python, will work in
any language with objects):

# defined internally in fvwm:

class Menu:
    def __init__ (self, name, menulist=[]):
	self.name=name
	self.menulist=menulist

    def __repr__ (self):
	return "{Menu = <%s, %s>}" % (self.name, self.menulist)

class MenuItem:
    def __init__(self, name, action=""):
	self.name=name
	self.action=action

    def __repr__ (self):
	return "{MenuItem = <%s, %s>}" % (self.name, self.action)

# defined in fvwmrc

M = Menu("Root-Menu", 
	 [ 
	     MenuItem("Xterm", "xterm -T $LOGNAME@$HOSTNAME"),
	     Menu ("Utils", 
		   [ 
		       MenuItem ("Top", "rxvt -T Top -n Top -e top"), 
		       MenuItem ("Xload", "xload -fg green -bg black -hl red"),
		       MenuItem ("Calculator", "xcalc")
		   ])
	 ])

With appropriate cleverness in the __repr__ functions, you could make it print
out the menus in the current fvwm syntax. The nice thing of using a real
language for this, rather than an HTML like syntax, is that it just falls out
that the user can create new types of objects to put in a menu. Probably you
just require than all menu items have to have a certain base class which
contains the member functions to exec the action. If you export some graphical 
functional to the scripting language, then you could even allow the menus and
menuitems to be responsible for drawing themselves. This would make trivial
such things as constructing a menu which automatically finds the the list of
available fonts, and draws each font with the appropriate typeface. 

If the language supports eval() (which I don't believe java does, right?) then 
you can do even more wild things, with modules generating menus dynamically by 
sending the magic strings to fvwm (like a menu for all xterms on the current
desktop).

---

From: Bob Woodside <[email-masked]>
Date: Tue, 05 May 1998 06:19:23 -0400 (EDT)

> switched from XEmacs 19.15 to 20.4; nothing else was changed.

        Sounds like they've changed the way XEmacs sets window titles for
the various frames, and you have StartsOnDesk specified for XEmacs. Do a
little poking around with FvwmIdent to see what looks different. I still 
have 19.15, so I can't check this out directly.

---

From: Albrecht Kadlec <[email-masked]>
Date: 05 May 1998 14:27:39 +0200

> >          <MENUITEM   NAME="Calculator" ACTION="xcalc">
...

much too cumbersome. I want to be able to read the damn thing (that's why I
can't convince myself to use FvwmM4).
the signal / noise ratio is too low for html code to read.

>     ("Xload" "xload -fg green -bg black -hl red")

looks pretty efficient typeing-wise.

> 	return "{MenuItem = <%s, %s>}" % (self.name, self.action)

ok, so the average user doesn't have to touch this, but exportable classes
do help pretty much, if you want to extend fvwm.

> available fonts, and draws each font with the appropriate typeface. 

I do think that this on-the fly menu-generation & interpretation isn't an
issue on any decent machine (>=pentium), that's able to run MS word
(isn't that interpreted in winbasic - at least it's as lame)

And I simply wouldn't use that menu on our sparc IPC. :-)

I'd like this pretty much.

> sending the magic strings to fvwm (like a menu for all xterms on the current

I strongly support this route.
I've never met anything more flexible than emacs with its hook functions.

-- 
Albrecht Kadlec
Vienna University of Technology / Department of Automation
----------------------------------------------------------
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them? To die: to sleep;
No more; and by a sleep to say we end
The heart-ache and the thousand natural shocks
That flesh is heir to, 'tis a consummation
Devoutly to be wish'd. To die, to sleep.	-- Shakespeare: Hamlet
--
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 Bayerdorffer <[email-masked]>
Date: Tue, 05 May 1998 13:38:07 -0500

In message <[email-masked]>, Bob Woodside writes:
=-        Sounds like they've changed the way XEmacs sets window titles for
=-the various frames, and you have StartsOnDesk specified for XEmacs. Do a
=-little poking around with FvwmIdent to see what looks different. I still 
=-have 19.15, so I can't check this out directly.

It wasn't a StartsOnDesk problem, however it did have to do with the window
title.  Thanks to [email-masked] for the following patch, which made
the problem go away (for me):

--------------

[email-masked] (Olaf Titz) writes:

> No, it doesn't use the last buffer's name, or anything set in .emacs
> any more. It uses the fixed string "shell", and this has changed from
> 20.2 to 20.4. At least for me.

File an official bug report if you haven't already done so and apply
this patch (this changed between 20.3 and 20.4). Note that the comment 
still applies, be carefull with the the modeline spec.

Index: frame-x.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs-20/src/frame-x.c,v
retrieving revision 1.30
diff -u -r1.30 frame-x.c
--- frame-x.c	1998/04/07 05:39:41	1.30
+++ frame-x.c	1998/04/21 20:58:50
@@ -2038,7 +2038,7 @@
    * frame, and that may not have been set up yet.  The redisplay
    * will update the frame title anyway, so nothing is lost.
    */
-  /* update_frame_title (f); */
+  update_frame_title (f); 
 }
 
 static void

Jan

P.S. Note, the patch is against 21.0b36, you might need to apply it by 
hand.

---

From: Dan Espen <[email-masked]>
Date: Tue, 05 May 1998 16:49:41 -0400

>    objects and vice versa. Guile might be more of a stretch.

I  don't see how  you have   answered  #4 above.   Wouldn't having  an
interpreter hooked up  to fvwm2   consume  lots of  memory   instantly
transforming fvwm2 into CDE?

Wouldn't any  new "fvwm plus interpreter"  project be redundant to the
scwm  project?  (It  doesn't  seem  to me  that  it  makes much  of  a
difference whether the interpreter is Scheme, Perl, Tcl, Java.)

I haven't  come to any final  opinion, I'd like to  see how scwm works
out, but so far I'm not having many problems I can't solve with fvwm2.

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
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: Brady Montz <[email-masked]>
Date: 05 May 1998 16:16:51 -0700

> transforming fvwm2 into CDE?

Probably about a meg. Certainly significant. There will be some memory
benefits to getting rid of the internal interpreter as well. 

> out, but so far I'm not having many problems I can't solve with fvwm2.

I didn't know about the scwm project until recently. I agree that it seems
quite redundant, so much so that I suggested in my last post that perhaps it
would be best for everyone if scwm became fvwm version 3. 

I personally have lots of problems with FvwmIconMan, and other modules which I 
would like to write, that would be solved by having an interpreter in fvwm.

---

From: Nathan Froyd <[email-masked]>
Date: Tue, 05 May 1998 22:24:45 -0500

I couldn't really find another post I wanted to respond to, and didn't
feel like spawning a new thread, so here's my 2c on the current
situation.

1) FVWM is a pain to configure. So is any other X11 window manager.
Personally, I feel that the least offensive (besides the obvious choices
like wm2 and wmx) is actually TWM. The 'Decor' idea in FVWM is bloated
and very difficult to work properly with, IMHO. TWM offers more
per-window capability. However, since the trend seems to be swinging
toward an interpreted language, this TWM-style config file is out of the
question (unless someone feels a pressing need to work on it).

2) My vote for an interpreter would be Scheme. Tcl/Tk seems to have a
lot of problems with different versions. Python might be a good choice,
but since I have no experience, I would have to abstain. Please, let's
not munge Perl into the mix - I have nothing against Perl - but let's
leave Perl to do what it was designed to do. Another advantage to Scheme
(Guile, IMHO :) would be the ability to eliminate Decors (can anybody
tell I have a grunge match against Decors?)

(title-style-set! "Emacs" '(hgradient ...as before, offering TWM
per-window syntax while retaining the power of FVWM.

FVWM is probably in need of an overhaul - there's a couple places in the
code that could definately use cleaning up. I vote we make a big push
toward a 'final' version (2.1 or whatever) and then start looking at
scwm.

Nathan

---

From: [email-masked] (Randy J. Ray)
Date: Tue, 05 May 1998 23:22:30 -0600

>>>>> "Bob" == Bob Woodside <[email-masked]>
>>>>> wrote the following on Tue, 05 May 1998 06:19:23 -0400 (EDT)

  Bob>         Sounds like they've changed the way XEmacs sets window
  Bob> titles for the various frames, and you have StartsOnDesk
  Bob> specified for XEmacs. Do a little poking around with FvwmIdent
  Bob> to see what looks different. I still have 19.15, so I can't
  Bob> check this out directly.

There was a slight change in that respect-- XEmacs no longer has the ':' in
the window title. I start an XEmacs process at start-up (I run it as a server),
and had a Wait that needed tuning once I upgraded.

Randy
--
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Randy J. Ray                                                    [email-masked]
Campbell, CA                                                      [email-masked]
Web page coming soon
--
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: Chris Siebenmann <[email-masked]>
Date: Wed, 6 May 1998 18:19:38 -0400

|    Now I don't want to yelled at :)   but how about taking
|    the approach of HTML tags?

 What's the point? Seriously: what's the point to just making menu
configuration more verbose and more annoying? I don't see any, and
I think it's a step backwards. I'd suggest evaluating a new config
language with the question 'what does this do better than the
current approach?'

	- cks

---

From: Albrecht Kadlec <[email-masked]>
Date: 07 May 1998 12:05:30 +0200

> benefits to getting rid of the internal interpreter as well. 

minus FvwmAuto which is much too much for a simple raise from a focus_change hook.
same for FvwmAudio/FvwmEvent which supplies the event hook functionality,
that fvwm2 is misssing.

USER       PID %CPU %MEM  SIZE   RSS TTY STAT START  TIME COMMAND
albrecht   274  0.0  3.1  1988   960  ?  S  Apr 28   0:17 /usr/X11R6/bin/fvwm2 
albrecht  3182  0.0  2.2  1540   700  ?  S   11:48   0:00 /usr/X11R6/lib/X11/fvwm2/FvwmButtons 10 7 .fvwm2rc 0 8 
albrecht  3183  0.0  1.9  1536   612  ?  S   11:48   0:00 /usr/X11R6/lib/X11/fvwm2/FvwmPager 12 7 .fvwm2rc 0 8 0 0 
albrecht  3189  0.0  1.2  1464   376  ?  S   11:49   0:00 /usr/X11R6/lib/X11/fvwm2/FvwmAuto 16 7 .fvwm2rc 0 8 500 
albrecht  3067  0.0  1.3  1488   404  ?  S   11:35   0:00 /homes/albrecht/bin/Fvwm/FvwmEvent 16 7 .fvwm2rc 0 8 

~3 Meg RSS for Fvwm & modules with 

This could be better with shared libraries, but we've been waiting for 2
years now. And if guile is a shared lib, there should be other apps using
it too. (BTW: any plans for a guile-using multithreaded emacs ?)

albrecht   382  0.0  1.3  2196   428  ?  S  Apr 28   0:03 xload -title xload:boole -geometry -1500-1500 
albrecht   384  0.0  0.9  2160   288  ?  S  Apr 28   0:00 xclock 
albrecht   725  0.0  0.3   848   112  p3 S  Apr 28   0:00 tail -f /homes/albrecht/.xsession-errors .mailfilter.log 
albrecht  3506  0.0  0.9  2204   292  ?  S  Apr 30   0:07 xbiff 

~1 Meg for Button Applications

one xterm + tcshell for console (shared text with other terminal windows, so not counted)

albrecht   995  0.1  7.4 20112  2304  p3 S  Apr 28  22:34 emacs
albrecht  4310  0.1 40.3 22768 12488  p3 S  May  5   3:12 emacs -f gnus 
albrecht  4482  0.1  8.8 25164  2752  p5 S  May  5   3:20 /usr/local/bin/netscape http://www.public.usit.net/pinecrst/ 

ok I also have to work here

> would like to write, that would be solved by having an interpreter in fvwm.

And I think "my" modules FvwmAudio->FvwmEvent and FvwmAuto are simply
one-liners in lisp.

FvwmAuto in elisp: 
(add-hook fvwm-enter-window-hook (progn	(sleep-for 0 300)
					(raise)))

-- 
Albrecht Kadlec
Vienna University of Technology / Department of Automation
----------------------------------------------------------
... and, could someone please be so kind to post an algorithm to
cope with this world in real time, using incomplete knowledge !?
--
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]
Date: Thu, 7 May 1998 11:25:28 -0400 (EDT)

I'm using Fvwm 2.0.46 on my Digital Unix system (a preliminary release
of Digital Unix 5.0).

In my .fvwm2rc file, I have the following Mouse lines:

	Mouse	1	T	N	Move-or-Maximize
	Mouse	1	FS	N	Resize-or-Raise

The functions called are described below:

	DestroyFunc	 "Move-or-Maximize"
	AddToFunc	 "Move-or-Maximize"
	+ "I"	Raise
	+ "I"	Focus
	+ "M"	Move
	+ "D"	MaximizeVert

	DestroyFunc	 "Resize-or-Raise"
	AddToFunc	 "Resize-or-Raise" \
	  "I"	Raise
	+ "I"	Focus
	+ "M"	Resize

My understanding is that this should allow me to do the following:

1.  Mouse button 1 on the title bar will always raise and focus the
    window, and if the mouse moves, the window will be moved.  On the
    other hand, if it is a double click, the "MaximizeVert" function
    will be called (which maximizes only in the vertical direction;
    function is not included here).

2.  Mouse button 1 on a frame (the corners) or a side (the frame above
    the title bar and below the window) will raise and focus the
    window, and if the mouse moves, it will allow me to resize the
    window.

The problem occurs when I click on the title bar on a window that isn't
currently focused.  Instead of getting running "Move-or-Maximize", fvwm
runs the "Resize-or-Raise" function.  This doesn't happen if the window
already has the focus.

I can prevent the calling of the "Resize-or-Raise" function by removing
the "S" from the "FS" in the second Mouse line, but that prevents me
from being able to resize vertically or horizontally (I can only resize
diagonally).

My current workaround is that if I wish to move a window without the
focus, I will click on the window (to give it the focus), release the
mouse pointer, and immediately press it again.  Fvwm then runs the
Move-or-Maximize function, which is what I want.  It's an extra click,
though.  And I STILL occasionally get caught with a window that resizes
when I really want to move it.

Is there a bug in fvwm's logic that makes it think a title bar on a
window without the focus is instead a window "side?"  If this has been
reported before (I may have missed it on this mailing list, although I
have been reading it for a couple of years), is there a plan to fix it
in the (hopefully) upcoming 2.0.47?

-- 
(void) lar3ry();                                      [email-masked]

     "Sometimes it happens.  People just explode.  Natural causes."