Your message dated Wed, 3 Feb 1999 05:50:31 +0100 (CET)
with message-id <[EMAIL PROTECTED]>
and subject line Fixed.
has caused the attached bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I'm
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Ian Jackson
(administrator, Debian bugs database)
Received: (at submit) by bugs.debian.org; 24 May 1997 21:29:05 +0000
Received: (qmail 28517 invoked from network); 24 May 1997 21:29:05 -0000
Received: from gateway.compass-da.com (HELO extractor.compass-da.com) ([EMAIL
PROTECTED])
by master.debian.org with SMTP; 24 May 1997 21:29:04 -0000
Received: by extractor.compass-da.com; id AA08209; Sat, 24 May 97 14:29:00 PDT
Received: from clsi.columbia.compass-da.com(162.17.30.22) by
extractor.compass-da.com via smap (V1.3)
id xma008203; Sat, 24 May 97 14:28:51 -0700
Received: from ultra.tibu (ultra.columbia.compass-da.com [162.17.30.15]) by
clsi.columbia.compass-da.com (8.6.12/8.6.9) with ESMTP id RAA21673; Sat, 24 May
1997 17:18:28 -0400
Reply-To: [EMAIL PROTECTED]
Received: by ultra.tibu (SMI-8.6/SMI-SVR4)
id RAA28497; Sat, 24 May 1997 17:30:06 -0400
Date: Sat, 24 May 1997 17:30:06 -0400
Message-Id: <[EMAIL PROTECTED]>
From: "Daniel S. Barclay" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: default settings problems - general (philosophy) and specific
Package: fvwm2
Version: 2.0.43-BETA-0
Problem: bad design philosophy for default settings
The Debian system.fvwm2rc file says:
# The defaults that this file sets up follow my own taste. They
attempt to set
# up a nice, easy, comfortable environment for the "ordinary" user. ...
This is not a good idea.
The default settings should be designed consciously. They should NOT
simply be the personal preferences of the Debian package maintainer.
They should not ignore the defaults from the upstream package developer
without better reason.
There are two main problems with the current Debian default settings:
1. Representative features of FVWM2 are suppressed. Debian users who try
FVWM won't see (and be able to use) its normal features until they
dig into the configuration files and documentation.
For example, consider the desktop pager.
In Debian, fvwm2 is configured with no pager or other visual
indication that you can switch between pages or desktops.
In the original FVWM distribution, the sample system.fvwm2rc
file provides access to the pager (in the Module-Popup menu)
without requiring any customization.
A user who tries FVWM from the original distribution can
easily find the pager and explore it.
A user who tries FVWM on Debian won't easily see what FVWM
can do. Such a user might find out about the pager (from
digging through the documentation), and successfully configure
it before being able to explore it.
This seems quite contrary to much of Debian's philosophy of
pre-packaging things.
2. Useful default settings from the original distribution are deleted, making
customization more difficult.
Again, consider the desktop pager.
I installed fvwm2, but I got no desktop pager when I ran it. After
reading about the Debian hook-file setup, and looking through the fvwm2
and FvwmPager manual pages, I added "Module FvwmPager 0 0" to the
system
init-restart.hook file.
This got a pager to display, but when I used it to switch to a
different page, the pager disappeared.
After a while, I figured out that I needed to add 'Style "FvwmPager"
Sticky' also.
However, that setting is in the default configuration file in the
original distribution. Why was it removed? If it had been left in,
the pager would have worked usefully once I enabled it by adding the
"Module ..." line.
(In fact, it was only by finding and downloading the original
distribution to look at its default configuration that I was able
to figure out what to add. (The FvwmPager manual page doesn't point
out that you'll want to make it sticky.))
One other specific problem is the change to the actions of mouse clicks on
window borders.
In the default configuration of the original FVWM distribution, if any
side-bar of a window is visible, you can move the window by dragging with
mouse button 1.
This is important, because the title bar of a window might not be visible
and usable for moving the window--the title bar might be behind other
windows, or off the edge of the current viewport.
(The sample system.fvwm2rc file says "Mouse 1 TS A Move-or-Raise" and
provides resizing via the corners with "Mouse 1 F A Resize-or-Raise".)
For some reason, the default Debian configuration sets button-1-dragging of
a window side-bar to resize the window instead of moving it. :
Mouse 0 T A move-and-raise-or-raiselower
Mouse 0 F A resize-or-raiselower
Mouse 0 S A resize-or-raiselower
Now how do you move a window without having to raise it to see the title bar?
(This break what is normally one of the major advantages of FVWM over other
window managers I have used--you can move or resize windows without disturbing
the stacking order.)
And how do you move a window whose title bar isn't in the current viewport?
Especially, what if it's off the top of a top-row page? There's no page
above it to go to to display the title bar.
(And why provide virtually duplicate functionality? Yes, the Debian
settings let you resize only one dimension without accidentally resizing
the other, but this gain is not worth the loss.)
Also, why does Debian discard other standard FVWM settings of different
actions for different buttons? FVWM has some useful settings. Why were they
all deleted?
Specifically, a button-2 click on a title bar would send a window to the back,
regardless of whether it was in front or not.
(Button-1 raises a partially-obscured window, and lowers a fully-raised window.
The button-2 form lets you lower a window directly, without waiting for raising
and redrawing, and without having to evaluate whether one click or two is
necessary.)
This specific case was quite useful, and in general it is useful to have other
buttons perform variations. FVWM's design for the buttons and functions
seems pretty reasonable. Why does Debian discard all that?
If the Debian packager likes to use FVWM that way, that is his prerogative.
However, the version that Debian ships to the world should not have that as
a default.
I realize that Debian might want to simplify things for more-novice users,
and that someone might think that making all the buttons do the same thing
would make things simpler. However, this change to FVWM is not appropriate.
It's a lot easier for novice users to ignore variations on other buttons than
for them (or not-so-novice but non-expert users like me) to restore all the
functionality that was removed.
Would you please reconsider your design philosophy and not make FVWM harder
to use? Someone spent some good effort designing the Debian hook-file
modification to FVWM. That appears to be designed very well. Please
revisit the design of the default configuration settings themselves so the
design quality matches.
Daniel
