Lowering the barrier to entry for FVWM newcomers

Talking about getting started using FVWM, the topic started drifting to the default config for FVWM:

Well, you need an xterm to modify the setup, and a quit option to exit the WM. It couldn’t be much more minimal :slight_smile:

Seriously though, a very little work on the default settings would make FVWM much more accessible to first timers. It wouldn’t take much.

Background. Something simple. A minimalist wallpaper would work, but failign that a gradient or even a solid color. Just something to show that something is in fact happening, and that the window manager didn’t crash whilst starting up. Maybe a message that says “click anywhere for a menu” since that’s not obvious.

Resources: A help option would be nice. Even if it just spawns

xterm -e more /usr/share/fvwm/getting-started-for-n00bs.txt

Something to point folks in the right direction.

Setup: I’d either lose the Fvwm95 setup form, or update it with some less antiquated options. It gives the impression that nothing important has happened for Fvwm in the last ten years.

Menu: A free font for the menu to make it a it easier on the eye. Maybe a colorset that uses something with a little more zing that battleship grey.

Just that much, and your newcomer would be so much more tempted to stick around.

The other thingI think would help is an improved theme architecure.

When I started with my first lightwieght WM. it was the themes that persuaded me to stick with it. Afterstep has this simplified “put the tarballs in the theme directory”. I downloaded a few themes, played mix and match until I had something I liked to look of, and then I was happy.

I still wouldn’t know how to do that with FvwmThemes. I’m sure it’s a very clever setup and all, but it seems less complicated to write my own config from scratch than to modify a theme to do what I want. And I’ve tried my hand at both.

Some sensible and modern application defaults would be nice as well. Maybe as part of a setup script. Mozilla or Firebird rather than Netscape - that sort of thing.

Of course, the question remains as to whether a larger userbase and/or greater mindshare is necessarily a good thing. I don’t think they should be the be-all-and-end-all for FVWM. But it seems to me some concessions to popular appeal could be made without losing out street cred entirely.

Opinions, anyone?

[color=blue][ I’ll get around to properly structuring this, it needs a moderator to be able to properly split the threads, so that there is no cross posting. Guess that’d be my job, then… :stuck_out_tongue:][/color]

You have to be a little “careful” though – all of this is subjective, and the final note has to rest with the developers. I’m not sure how much more “accessible” one can get. We already have fvwm-themes as a good base for people to start with – that has and shows what can be done, visually with a semi-graphical means to do it as well.

Of course, I take the point that perhaps anyone that is installing Fvwm pure (without fvwm-themes) might be in for a shock as to what greets them when they start fvwm up, but there are a number of reasons why I like this:

It doesn’t tie you into an interface straight off.
The fvwm package (with the exception of Debian’s) comes with three or four sample .fvwm2rc files anyway.

But that’s not the job of Fvwm to supply that. I’ll take your hint, though, maybe having a gradient background, or a block colour one, would perhaps offset things slightly. But it comes back to the point I made earlier, if you install Fvwm, the default location for a sample system-wide fvwm2rc file is already read, so you can at least see something.

You only get the setup form if fvwm cannot see the system-wide fvwm2rc file (it looks in a number of places for it). And even that, although ugly will get you going – your recent ramblings on that, Nick, depict that. As far as intuitive levels go – we cannot cater for everyone. There is a (heavy) onous on people to do it Their Way ™, and giving them a minimal (literaly so, in some cases) config allows them that freedom. And for those people which are left on their backs, with their legs twitching, often are able to do things for themselves. You’d be surprised at just how many people are able to take the initiative, and find the screenshots page or the aforementioned fvwm-themes page.

Ok, I perhaps like this idea. Although terse at times, ALL the information needed is in the man pages. You can’t deny that, and I realise that for any first-timers reading that can fill one with dread – it certainly did me. But bit by bit you can build things up.

It’s not Fvwm95 – it’s just an initial FvwmForm setup option. Yes, it is out of date. But then, you can turn your hand to the supplied .fvwm2rc files for that.

I disagree – again, that’s entirely subjective. It’s down to the individual. Not to mention, it is not the job of Fvwm to supply fonts, that’s X11’s job to handle that. Fvwm just makes use of what is available, and you cannot guarantee that the selected font is (whatever one you might have wanted to use as the de facto) – so Fvwm has to default to something, that for 99.9% of the time, will be available.

As for colour, pffft. I might find red offensive, or maybe green. It just shows a menu. :slight_smile:

I can see what you mean, and I appreciate the points you’re making, I just think you’re under too much of an assumption that people are unable to look beyond the default instance of Fvwm to something more pleasing.

It might be… OTT at times, but it still shows what one can do with it, it shows what can be possible, and you can mix and match whatever you like.

Yes, that does need updating a little.

– Thomas Adam

Oh, I think a fair number of people can make that mental leap. FVWM has a reasonable userbase after all. I just think there’s a certain threshold beyond which a person will not look, either because they want something less challenging, or because they don’t see the potential of the software.

I think FVWM sets that threshold higher than is entirely useful. That’s not entirely a bad thing. Putting off those unwilling to do a little reading, and make a certain effort probably results in a more technically adept userbase.

I still think that threshold could usefully be lowered.

As for backgrounds and fonts - well, it’s not the job of say, XFCE, to supply a default wallpaper, either, but it does. I can’t see anything wrong with that. I’d be as happy with a color or a grad, personally, but I wouldn’t complain at a default wallpaper. I’ll grant you’d want to keep things fairly style-neutral to avoid putting people off … but it’s hard to imagine anything more offputting than a bare X11 mesh - my first experience of FVWM on gentoo.

Well, yes, but then if they can’t see the potential, that’s their loss. That’s harsh, but then if one is not willing to spend even a little time in trying something, you cannot hold FVWM against it. I remember having a discussion on the Fvwm mailing-list some years ago now about the possibility of Fvwm having a GUI-configuration component. Back then, the dotfile generator was the best tool, but even that had reached its limit.

For many people that want to look at Fvwm as a possibility, one of the first things they ask is “where is the GUI config tool”. When I quip to them that “xterm -e vi ~/.fvwm2rc” is it, they often glaze over in shock. But you can’t possibly have a GUI tool which enumerates all of the possibilities. OTOH, you could have one which does a few common options, the only danger with that (like the dotfile generator) is that people will often quickly come to the (wrong) conclusion that that’s all the possible applicable options available.


I wasn’t talking about wallpapers per se – fvwm-themes supplys its own. I was talking about the fonts.

– Thomas Adam

I can agree with that. The only question is how much (or how little) time we would wish them to spend. It’s not as if everyone looks at something and either instantly appreciates its full potential, or never will no matter how long they look. It takes more time for some users than for others. The higher the initial investment in time that is required, the more users there are that go elsewhere. And you may get some technically adept people who lack the time for more than a hasty evaluation.


I can’t see the difference between supplying a default wallpaper and a default font, myself. Just one freely available one would do, properly credited, of course.

Maybe – but again, that depends on their needs. I don’t think there is a consensus we can come to – it’s very much situation dependant. But to say there is some middle-ground that could provide a basis is still assuming that what we have currently is lacking. Maybe it is. It suited me well, but that’s just me. Maybe a little more work could be done on it.

Because installing a font is modifying an X11 install, and it depends how their fonts are organised. A wallpaper is not – that’s just a customisable aspect.

– Thomas Adam

I’m only proposing some background and a help entry on the menu. Plus possibly a note saying “click anywhere to get a menu” and maybe a font. That hardly constitutes stylistic evangelism,

Mmm… You said that some of the major distros pre-package a selection of ready made configs. I suppose had my first exposure to FVWM been such then I might take your point more readily. Assuming we want to rely on the distros.

All the same… there’s a feedback loop at work here. To have a grungy default interface that discourages all save a few hardcore, old skool types [1], and then to say “it’s good enough for me - why change it?” is to perpetuate the narrow appeal of the software.

Ok, I can see that. Still, you could detect, say, x.org and xfs and install into ~/.fonts contingent upon that (if I got that right). That’d cover the more modern setups, and in doing so catch most of the new converts who are the target audience for this effort. It shouldn’t be beyond our wit to organise something.

[1] Not to imply anything about you (Thomas) personally, obviously.

:slight_smile: Absolutely. Hmm, I hope that you weren’t reading that out context. I think it is a good idea. I was just a little anxious that it was heading the same way to what fvwm-themes has already achieved. I can see that’s not the case, though. Apologies if that seemed negative.

There is always that, I suppose. :slight_smile: RH, obviously used to supply their own config, that came in the form of AnotherLevel. SuSE also (and still do) provide their own fvwm configuration. AFAIK, other than Debian, the Fvwm installs on other distros just supply the sample fvwm2rc files that come with the fvwm source from the main site.

Of course, this doesn’t really help those people that don’t have those files, and get, as you say that “grungy default interfaces”.

No no – “good enough for me”, only in that I didn’t mind it, and I could use it to define my own style. That’s not to say it’s any good for other people. In fact it isn’t. I suppose I’m just naturally curious to see how things work.

That’s true, I suppose. Well, I propose that you and I work together to produce something a little more… delectable. It seems that there are two issuse here:

  1. We either update a default .fvwm2rc file that is released with the main fvwm binary/source tarballs.


  1. We change the default FvwmForm that pops up if no .fvwm2rc is read. This is probably more desireable since it gives us (and hence new users) a more accessible means.

If we’re successful, we should propose our findings to the fvwm-workers mailing-list.

:slight_smile: Not at all. Apologies if I seemd combative or negative. That was not the case.

What do you think?

– Thomas Adam

Sounds good to me - I’ll see about a first cut when I get home tonight

Of which suggestion? :slight_smile:

– Thomas Adam

Good point :smiley:

I was thinking about a default tarball, but I agree that an updated setup form is going to be more valuable in the long run.

As I recall, the setup form doesn’t popup automatically, so much as sit as option three on the default menu. Maybe we could do both?

Yes, we can do both. I’m happy to (re)implement the setup form, although we should both establish the fact that the new .fvwm2rc should be what is created via the reimplemented setup form. So to that end, it isn’t worth updating the setup form until a proposed .fvwm2rc is put in place.

I hope that makes sense? :slight_smile: If you want to email me away from the forum, you can do so via my profile.

– Thomas Adam

Sounds like a good idea to me, but do keep in mind that some people still run on ancient hardware and use Fvwm because of it’s lightness, providing a “heavy” default config might damage that reputation…

Or do I see something wrongly?

Nope. I’ve got a nice little illustration of what I have in mind. It’s a 256 Bgradient from bule to grey as a background which gives a nice sort of “dome of the sky” effect, a smallish FVWM logo (the new one) as a banner with a “Welcome to FVWM. Click [color=red]Anywhere[/color] For A Menu” message. I applied the same colorset to the menu, and set arial black as the menu/title font, just because I had it handy.

I’d show you but my last kernel upgrade seems to dislike my usbkey, so it may have to wait until I get back to home base at the end of next week. I’ll see if I can wrangle a network port at work for 15 mins over lunch…

Of course, there are overheads with color gradients and true type fonts, and just because that’s way fast on my new laptop doesn’t mean it’ll run on so fast on someone else’s PII. I’ve got a 266 I can test it on next time I get to my parents place. I’ve even got a P166 laptop which usually runs using ratpoison. If it’ll run on there with sane response times, I reckon it’ll run anywhere.

In any event, I entirely agree, it has to be a lightweight config. If it can’t pass the P166 test then it’s a none starter.

Sounds good to me. I too have a P166 with which to test so we can certainly make sure it works well.

– Thomas Adam

Right. I’m back from Ireland and I’ve had a decent night’s sleep. Let’s get this show on the road.

Basic “Welcome” Banner and Menu.

Some windows so you can see the decor and colorsets. Hobbes is not part of the setup.

And here’s the code. It tries to show some examples of different ways to do things - lots of comments.


some setenvs to make it easier to move this stuff about

SetEnv resource_dir $[HOME]/.fvwm/New_Default
SetEnv helpfile $[resource_dir]/helpfile
SetEnv banner $[resource_dir]/fvwm-welcome.png

colorsets. Only two used. we might want a couple more for the forms

one solid color and one grad - nothing to greedy

Colorset 1 BGradient 256 blue gray, fg black
Colorset 2 bg DarkSlateBlue

styles - the font shadow may be a stretch, but it adds so much for

so little effort, I couldn’t resist

The I’ve not defined a decor, so the title bars just pick up a basic blue

I’ve defined a darker one for the focus window. Fvwm picks yellow as a

good contrast colour, and that in combination with the darker colour is

enough to pick out the active window

style * Font “Shadow=3 sw:xft:ArialBlack”
style * Colorset 1
style * HilightColorset 2

menus using the same colorset. the grad works nicely for the background

menustyle * Font “Shadow=3 sw:xft:ArialBlack”
menustyle * menucolorset 1

a very minimal backer - I expect we can even use the retain pixmap option

DestroyModuleConfig FvwmBacker: *
*FvwmBacker: RetainPixmap
*FvwmBacker: Command Colorset 1

this is our starting message

longer than usual timeout to give 'em a chance to notice the text

DestroyModuleConfig FvwmBanner: *
*FvwmBanner: NoDecor
*FvwmBanner: Pixmap $[banner]
*FvwmBanner: Timeout 6

startfunc stuff

DestroyFunc StartFunction
AddToFunc StartFunction

  • I Module FvwmBacker
  • I Module FvwmBanner

menu. this recreates the menu from the bare metal default, but loses the

Windows95-alike setup form and adds a “getting started” window.

DestroyMenu MenuFvwmRoot
AddToMenu MenuFvwmRoot ‘Builtin Menu’ Title

  • ‘&1. Xterm’ Exec exec xterm -bg navy -fg white
  • ‘&2. Getting Started’ FuncGettingStarted
  • ‘&3. Setup Form’ Module FvwmForm FvwmForm-Setup
  • ‘&4. Execute FVWM Commands’ Module FvwmConsole
  • ‘&R. Restart’ Restart
  • ‘&Q. Quit’ Quit

DestroyFunc FuncGettingStarted
AddToFunc GettingStartedFunc

  • I Exec exec xterm -T “Getting Started” -bg navy -fg white -e less $[helpfile] [/code]
    The only thing here that could be considered controversial is the resource directory. Basically, I have multiple configs installed

nick% ls -1 config_* config_Boroshan config_New_Default config_Romaine config_Scriptease config_Prisoner
And the resources (files, images, scripts, what have you) live the directories that you get by chipping the “config_” off the config file name. This means that I can maintain all these setups without any conflict in filenames between them. In this case the resources are minimal (banner, getting_started.txt) but I feel it’s good practice.

It’s a practice that also allows me to change setups on the fly by removing ~/.fvwm/config which is a symlink, linking the desired config in its place and Restarting. I have a bit of script to do that too


OK: Job One is to provide some way to access the menu

Let’s Bind it to Windows-C

Key C A 4 Popup ConfigMenu

Better define it now

The DynamicPopupAction stuff tells FVWM "if we get here and there’s not

menu in place, call this function"

DestroyMenu ConfigMenu
AddToMenu ConfigMenu

  • DynamicPopupAction Function MakeConfigMenu “Select Configuration”

Adapting this from Sa’s setup - destroy menu or destroy func?

DestroyMenu MakeConfigMenu
AddToFunc MakeConfigMenu

  • I Echo “Make Config”
  • “I” DestroyMenu recreate ConfigMenu
  • “I” AddToMenu ConfigMenu “$0” Title

Pet Peeve: There is NO reason why embedded shell commands have to be all on

a single line! Unless your intent is to obfuscate, why not lay it out in a

readable manner? No one is going to revoke your 1337 status just because they

can understand your bash scripts.

  • “I” PipeRead ’
    for i in ~/.fvwm/config_*;
    echo + $( basename $i | sed s/config_// )
    FuncSwitchConfig $i ;

DestroyFunc FuncSwitchConfig
AddToFunc FuncSwitchConfig

  • I Echo FuncSwitchConfig: $0
  • I PipeRead ’
    if [ ! -L $HOME/.fvwm/config ];
    mv $HOME/.fvwm/config
    rm -f $HOME/.fvwm/config;
    ln -s $0 $HOME/.fvwm/config;
    echo Nop;
  • I Restart
    This lives in ~/.fvwm/menu_config and autogenerates a menu based on available configs. I’ve bound the menu to Mod4+C rather than place it in the default config menus.

The other nice thing about this approach is that you can tar up a config, for someone to untar in comparative safety and use traight away. I’ve got a tarball for the setup above

Sorry, but that stays, as (probably) does the windows95 form. I’ll hide it in another option, but it should probably stay there.

I like this, Nick – and some obvious thought has gone into it. I’ll look at integrating it into the main internal fvwm setup form over the weekend, hopefully. :slight_smile:


– Thomas Adam

Thank you kind sir. I’ve no particular dislike of the windows95 form, except that it rather screamed “unmaintained” at me when I first tried FVWM. Win9X would work better - there are plenty of folks around who quite like Windows 98SE/Win2000 and, since the interface is pretty much the same, it would still work without the negative overtones.

Did I miss something else out? I don’t think I dropped anything else on purpose…

[edit - typo and clarifications ]

No, it’s all fine, Nick. I’ve just got to now modify the internal fvwm binary to reflect the new changes from your config.

– Thomas Adam

I would like to take part in this discussion.
I think it would be better off without any kind of ?Gradient’s (they don’t work in earlier versions?).
I’m working on a self-documented config-file where syntax and options are taken from the man-pages, and just commented in the config-file.
This was a bit too obvious to do, but in my experience, it is useful.
My config isn’t ready yet, as manpage parts need to be shortened quite a bit. But these kind of things would greatly benefit newcomers/themers/etc., I believe. Anyway, when it is, I put it in my themestuff -thread (called “X”).