On Sun, Feb 03, 2002 at 03:37:18AM -0500, Jacob Morzinski wrote:
>
> Configuration Information [Automatically generated, do not change]:
> uname output: SunOS coleco-sidewinder.mit.edu 5.8 Generic_108528-12 sun4u
> sparc SUNW,Sun-Blade-100 Compiler: /usr/gcc/bin/gcc Compilation CFLAGS: -g -O2
> prefix: /mit/windowmanagers
>
> FVWM Version: 2.4.5
> FVWM_MODULEDIR:
> /mit/windowmanagers/arch/sun4x_58/lib/X11/fvwm/2.4.5/fvwm
> FVWM_DATADIR: /mit/windowmanagers/arch/sun4x_58/lib/X11/fvwm/2.4.5/fvwm
> FVWM_USERDIR: unset
>
>
>
> Hello,
>
> I've just installed fvwm2.4 at my site, and wanted to send you a
> report on my experience. The report has turned out to be rather
> long -- you can read it or not, as you please. By the end I
> explain why I think I can't afford to replace v2.2 with v2.4.
> (I'm installing v2.4 alongside 2.2.)
>
> I'm glad that there are people working on fvwm. I like using the
> windowmanager. But I had some frustrations with this latest
> version, and wish that I hadn't had them.
>
>
>
> Broadly speaking, my frustration falls in two categories:
> sysadmin's frustration with the build system, and end-user's
> frustration with trying to upgrade to fvwm2.4.
>
>
>
> My sysadmin frustration is relatively minor. Two points of the
> build system were responsible for most of it. One was the fvwmbug
> shell script, and the other was the awkwardness of trying to install
> the program with the --program-suffix option to configure.
>
> The fvwmbug shell script hardcodes the username of the user who
> compiled fvwm2 into the script. This really should be
> configurable. I don't want personal bug reports any more than
> you want personal bug reports, and I should have the ability to
> configure which address "local" bug reports go to. (I worked
> around the issue by setting $USER to the target email address
> during the build. Ick.)
Well, it's meant only for bug reports going to us. Everybody can
edit the sender information in a mail program.
> The --program-suffix option would have been useful, because I wanted
> to install this fvwm as "fvwm2.4" to prevent users from running it
> accidentally. I couldn't use --program-suffix, though, because
> it transforms the names of all of fvwm's modules in addition to
> transforming the name of the fvwm2 binary. A module named
> "FvwmPager.4" doesn't work, when the config file is trying to
> run "FvwmPager". (I worked around this issue by hand-editing
> fvwm/Makefile after running "configure" but before running
> "make install". The "transform" variable I added worked, but I
> wish I could have specified at the configure stage.)
>
> On the bright side, I definitely appreciated the INSTALL.fvwm file.
> It gave useful information about where components would end up when
> installed, and saved me a lot of time that might otherwise have been
> spent crawling through the Makefiles trying to divine how they
> worked.
>
>
>
>
> My end-user style of frustration came when I tried testing the new
> fvwm2, to see how it would work for our users (who have been using
> version 2.2.2 before now). I'm sad to say that most of them will
> continue using 2.2.2 for the near future, because I don't have time
> to handle the cost of upgrading them. The most problematic issue is
> the config file changes, but another nuisance is fvwm's readiness to
> scream "ERROR!" at users.
That is because it's better to scream "ERROR" than to confront
users with broken config files that no longer work without a clue.
Most of the new error messages address commands or features that
are planned to phase out when fvwm-3.0 is released (whenever this
may be).
> One backwards-incompatible change in the config files that bit me
> is the change in how titlebar buttons are defined. My current
> system.fvwm2rc file, used with fvwm 2.0 and 2.2, has lines of the form:
>
> Key F6 WTSFI1357924680 M Move
>
> I wanted M-F6 to always invoke Move, and the manpage explicitly
> claimed that a context of "A" stood for "any context except for
> title-bar buttons", so I included title-bar buttons in the Key
> binding's context.
I see. The man page is incorrect. 'A' matches any context,
including buttons. I'm sorry if that has lead to
> In version 2.4, this Key binding has the
> side-effect of *creating* all ten title-bar buttons.
That's not a side effect but exactly what was always intended.
All title buttons that have a binding show up. By accident,
before 2.4, only mouse bindings activated the buttons.
> I can fix the
> global system.fvwm2rc file by using a context of "A", but this won't
> help users who have personal files based on modifications to the
> system one. They will suddenly be faced with titlebars with too
> many buttons.
Title buttons can be suppressed with the NoButton style:
Style * Nobutton 6, NoButton 7
etc. Of course you'd have to change config files too.
> They will also be faced with another nuisance: screaming <<ERROR>>
> messages. Fvwm will yell ERROR at users who use xbm images.
> ("<<ERROR>> XpmReadFileToXpmImage failed"), at users who have Key
> bindings for foreign-platform keys ("<<ERROR>> No such key: SunF37"),
> or at users who use v2.2-style config files ("<<ERROR>> IconPath is
> deprecated", and "<<ERROR>> Please replace 'GlobalOpts
> MouseFocusClickDoesntRaise' with 'Style * MouseFocusClickRaisesOff'")
See my comment above. I fail to see why it should be better to
let users run into these problems without a hint what has gone
wrong.
> There's nothing wrong with config file changes, as long as
> backwards-compatibility is maintained for a reasonable number of
> release versions. Given that GlobalOpts hasn't spent any time in the
> deprecated state, I'm irked to see it marked as obsolete. And is it
> really a [Fvwm]<<ERROR>> to use a deprecated line, such as IconPath?
We can't give much more of a hint than this. GlobalOpts *will*
vanish some day and then the users would have to find out on their
own what to do. BTW, there is a perl script that does most of the
conversions from 2.2 to 2.4 (utils/fvwm24_convert).
When developing we always have to make decisions about efficiency
vs. compatibility. Sometimes we make decisions agains the latter
to be able to have progress at all.
> If I just drop this new version of fvwm on top of the old
> installation, users will send email complaining of how the new
> one is broken, and of how it keeps telling them about ERRORs.
> I won't let someone sit at their computer one morning only to
> discover that they'll need to spend their morning fixing their
> dotfiles for today's new version of fvwm.
>
> I have had requests to install the new version, so I've done so, but
> it's sitting off to the side of the old version, named "fvwm2.4"
> instead of "fvwm2". That way people won't be able to accidentally
> run it, and when they do explicitly run it, they'll be able to
> put off upgrading their v2.2 config until they have time to do so.
>
>
>
> In closing, thanks for working on fvwm. I've been using it as
> my main windowmanager for the past four years. I'd love to see
> it become more of a mainstream windowmanager and less of a
> bleeding-edge windowmanager,
If you think that 'main stream' means 'constant feature set and no
bug fixes' then you'd better use a different window manager.
Fvwm is constantly changing, and sometimes its simply necessary
to not be compatible.
> but in order for that to happen,
> fvwm will have to be more careful about backwards compatibility,
> and about spewing diagnostic output.
Hm, when I run applications that you call 'main stream' my console
usually shows dozens or even hundreds of error messages ;-)
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
