Subject: FVWM: Wishlist

From: [email-masked] (Paul D. Smith)
Date: 01 Jun 1998 15:13:29 -0400

I've seen a few other people posting "WIBNI" stuff, so I thought I'd add
in my $0.02 in case anyone's looking for things to do ... :)

 1) Module cleanup.  It seems to me that there're at least a few modules
    where functionality is overlapping.  I appreciate that people have
    different priorities, but it'd be really nice for new users if there
    was one module for each task... and it would be nice to get one
    really excellent module rather than 2 or 3 pretty good ones.  The
    "Console" variants in the extras directory leap immediately to mind.

 1a) As part of #1, get a shared library for fvwm modules.  Pack as much
     stuff into it as possible--this may mean generalizing some of the
     stuff currently available in only one or two modules.  Once we have
     automake/autoconf support, we can use libtool to make shared
     library support almost trivial.

 1b) Also as part of #1, it would be nice if more modules allowed
     separate config files, rather than requiring things in .fvwm2rc
     (like FvwmButtons does, for example).  Configs for some modules
     (like FvwmForm!) can grow very large.  Also, it's nice if you can
     change the file, then see the changes without having to restart
     fvwm (or using a Console program).

 2) New core feature for SmartPlacement: have SmartPlacement try extra
    hard to avoid overlapping windows tagged StaysOnTop.

 3) FvwmForm -- this is a MOST handy module, but it needs someone to
    work on new features.

      - Cut and paste !!! (especially paste!)
      - Keyboard accelerators
      - Dropdown lists
      - Some more conditionals for the command invocation; I'd like a
        trinary operator.  Or, maybe something like the shell variable
        queries.

      - Nice to have: ability to draw lines across the window; ability
        to include pixmaps; etc.

 4) FvwmButtons

      - Allow "compressed" buttons, where the buttons aren't uniform
        width (or height, for vertical bars), but rather just as wide as
        they need to be.  This is most important for swallowed items.

      - A "tool tips" or "balloon help" feature.

      - One FvwmButtons app managing multiple button bars (I think
        there's one per button bar now, right?)  Generally I would like
        all "stay alive" modules to manage multiple instances of
        themselves where that makes any sense.

Gee, it seems like there were other things, too...

-- 
-------------------------------------------------------------------------------
 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--Bay Networks takes no responsibility for them.
--
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: Anthony Martin <[email-masked]>
Date: Mon, 1 Jun 1998 15:03:03 -0700 (PDT)

>     hard to avoid overlapping windows tagged StaysOnTop.

CleverPlacement can already do that, although currently the parameters
that determine how hard it avoids certain types of windows is hard coded.
Once the style flags are fixed, this can be made configurable.  To enable
CleverPlacement, use the following line in your rc file:

GlobalOpts SmartPlacementIsReallySmart

Tony

---

From: [email-masked]
Date: Tue, 2 Jun 1998 10:08:10 -0400 (EDT)

>  4) FvwmButtons

	- Allow a "hangon" title to be specified without having to use
	  the old (deprecated?) legacy syntax. 

	  What I'm talking about here is that the legacy fields:

	  [title icon command]

	  had an extension to Exec where it could be specified as:

	  Exec ["hangon"] command

	  Since this gives nice feedback that something is happening,
	  it would be nice if we could specify this somehow using the
	  Actions keyword.  Also, if the "hangon" never happens, there
	  should be some sort of timeout to reinstate the original
	  button appearance.

	  My suggestion:

	    Action (Mouse 1, Hangon "Netscape", HangTime 30) \
		'warp-or-run Netscape /usr/local/bin/netscape'
	  
	  This would do the following, when mouse button 1 is pressed
	  on the specified button:

	  1.  Change the relief of the button to indicate that
	      something is happening.

	  2.  Execute the specified function (not necessarily an
	      Exec).  In this case, "warp-or-run" will either warp to
	      the specified window if it exists, or will run the
	      command if there is no Netscape window.

	  3.  Hangon "Netsacpe" -- When a new window called "Netscape"
	      is mapped, change the relief of the button back to its
	      default state.

	  4.  HangTime 30 -- Set the relief of the button back to its 	
	      default state, if it hasn't already done so via the 	
	      Hangon title, after 30 seconds.

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

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