On May 29 at 8:14, John Culleton wrote:
,--
| Bruce Stephens wrote:
| > Dan Espen <dane_at_mk.bellcore.com> writes:
| > > Well, I had the same thought, but then I re-read the Description on
| > > the fvwm2 man page and that satisfied me.
| >
| > > If anything sets fvwm2 apart, its that its small and fast, and has
| > > just the right amount of built-in features.
| >
| > Well, it also ought to be configurable to a significant extent,
| > consistent with it being small.
| >
| > One of the things which I find useful is that it's *documented*. I
| >
| ...and it has some useful modules ready to go.
`--
Although I agree with everything that has been said (and note that `fvwm2'
is the most widely used window manager at our company by a huge margin,
thanks to a user-configurable "standard configuration" I came up with using
the wonders of FvwmM4), there are some things that I would like to see
addressed in future versions of `fvwm2':
. It should support multi-headed displays without having to run multiple
copies of itself. `vtwm' and other window managers can do it, `fvwm2'
should do it as well.
. Likewise, it would be nice if programs like FvwmButtons and FvwmPager
could support multiple instantiations without having to run a separate
copy for each button bar/pager/etc.
. The idea of forking a new application to do auto-raise, window list,
etc. seems totally silly to me. I would much rather have "dynamically"
loadable routines linked in when I start `fvwm2' and see just a single
process listed when I do a `ps': fvwm2. Not: fvwm2 (twice, once for each
screen), FvwmAuto (twice, once for each screen), FvwmButtons
(twice, one for each screen), FvwmPager (twice, once for each screen),
etc. Not to mention all the memory wasted by having all these modules
"separate". Although it is difficult to tell how much memory FvwmAuto
is *really* using (due to shared libraries and such), my guess is that it
is not insignificant:
USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND
eddy 5954 0.2 1.2 2576 1424 console S 09:17:17 0:00 FvwmAuto
eddy 5955 0.1 1.2 2576 1424 console S 09:17:17 0:00 FvwmAuto
Seems kind of silly when a feature like "auto raise" is really only a
a few K of code. I would much rather see this features somehow "dynamically
linked" to `fvwm2' at run-time (adding that few K of code to `fvwm2's
process space instead of forking a whole new process).
Just my thoughts!
Eddy
P.S. I've patched `fvwm2-2.0.46' to add some useful features:
. Automatic pointer warp to transient windows (great for programs
like Netscape that pop-up Find windows and such.) This would be
a great "style" feature (i.e., WarpToTransients/NoWarpToTransients).
. When placing a window (i.e., dragging around the "grid"), I have
redefined the mouse buttons to work as follows:
Button 1 = Place window (no change)
Button 2 = Place window, but allow it to be resized (i.e., while
holding button 2, you can drag to the window borders and
resize it while it is being placed. Very useful). If you
don't use the "mmw" style menus, this works already.
If you use "mmw" style menus, you can see how this works
by holding down "shift" and using Button 1. Not sure why
this feature is tied to mmw-styled menus, but I'd rather
see it always mapped to button 2.
Button 3 = Place window, but maximize its height (i.e., when you
click button 3, you select the top-left corner of the
window, but it is automatically resized so that it extends
all the way to the bottom of the screen. Great for xterms.)
If there is any interest in these patches, let me know where to send
them. I'd love to see them included in the next release of fvwm2.
--
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 majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Fri May 29 1998 - 08:39:40 BST