OK, I’ve made the changes I talked about above and packed them up as a tarball and also as a patch.
This is a full source tree tarball - mainly because I needed to tweak some files over on Thomas’ side of the fence. The patch is against vanilla fvwm 2.5.12, and not against Thomas’ last distributed tarball (which would probably have been more sensible - still).
I think this version should satisfy most outstanding issues. Please try it out and see if I missed anything.
Cheers, all.
It would have been nice to have seen you use a unified diff – as they’re far easier to see what changes have been made. I suppose I agree with your changes to fvwm.c – I’m not that bothered either way, just as long as you think it’s what’s best in this case.
I’ve gone ahead and fixed some outstanding bugs present with your tarball, as well as cleaning up some timing issues with FvwmButtons displaying (or not displaying as was the case.) Your ammendments to the Makefiles left out some important files, I’ve since fixed.
I need to generate proper diff patches to submit to fvwm-workers, which I’ll do at some point. I’m still not convinced it’s release-worthy yet, I just wish more people would test it.
They’re really only very minor fixes. Tarball is here.
– Thomas Adam
I’ll give it a go and report if I have any problems.
The major decider was jpkotta’s email where he reported blue lines from colorset 1 and 2 that couldn’t be shifted. If this doesn’t fix that then we can probably revert. I was reluctant to fiddle with your changes, but at least this gives us a test.
I’ve never generated a patch file before, so I’m not sure what a unified diff is. I just googled for “patch”, “diff” and “howto” and got “diff -Naur”. I’ll be grateful for any advice on the matter.
Again, entirely possible. I’m good with ordinary makefiles, but this .in and .am stuff is a bit outside my experience.
Can’t argue with that - I just wanted to get the ball rolling again.
I’ll give them a shot tonight when I get back.
I’d appreciate your thoughts on the null config matter. What should a user expect to see from a null config. From a consistency viewpoint, he or she should see a blue grad. From one of backward compatibility, an old style bare x11 mesh would be better, since that’s the foundation existing configs are built on.
If we do it one way we run the risk of confusing newcomers. If we do it the other we break pre-existing code… At the very least the helpfile needs modifying to reflect the problem.
I wouldn’t worry about it, Nick – I was unable to reproduce the issue at the time – perhaps symptomatic itself of the issue overall? I couldn’t say.
I apologise, since the command you ran is the correct one – it’s just that it didn’t look anything like a patch file I’d have expected from that command.
I don’t think it was anything you did directly, perhaps more of a consequence. I can’t say. .in and .am are GNU-buildtool specific files (as generated via autoconf and aclocal). If there’s a high enough need to do so, I might post a tutorial on the subject…
It never stopped, it’s just that University is taking up more of my time then I’d like. I’m now on revision week, although I’ve been concentrating on finishing off my Ruby bindings to Fvwm.
The “mesh” idiom is not one of expectancy, by any means. I don’t quite follow the “foundation for exisiting configs” idea. If you mean it’s what’s first seen if a background is not set on the root-window, then perhaps, but most WMs (and DEs for that matter) tend not to display it (twm being the exception, of course).
As for the nullconfig idea – I’m indifferent. I suspected my changes would cause internal conflicts to FVWM – although it’s not quite proven if that’s the case or not. As it stands, the in-built menu is still applicable, so that’s something in favour of it. It’s really only there in the very worst-case scenario. It would take an error in installation for the DefaultConfig file not to be read, anyway. So I suppose leaving out the internal colourset definitions in this instance can’t hurt, especially if it abates any of the conflicting issues from last time.
I’d rather “confuse” the newcomers than I would make contradictory changes in the code. Besides which, I find it slightly pretentious that the assumption here is that they would get confused, given the case for a nullconfig is slim at best. I’ll look at updating the helpfile to reflect this.
– Thomas Adam
I did wonder about that. could it have been a side effect of testing using Xnest? I stopped using Xnest because I got some odd effects which didn’t seem to happen otherwise. Perhaps the converse could hold true?
Failing that, there are going to be some platform dependant problems. My desktop machine, currently on loan to my father, always gets the mad taskbar bug which I’ve hardly ever seen on my laptop.
Well the last thing I want to do is pressure you. If you want to take some more time (and if this is revision week, then that’s probably sensible) then I’ve got plenty to be getting on with. Just say when you want to pick up the thread.
Well, let’s suppose you’re building a config from the ground up under the current defaults. We’ll further stipulate that you like to have a single menu icon on your taskbar.
Under the current defaults, you start out by adding a button, the result of which is you get a taskbar with one button.
Under our new config, you’d get four buttons - it would be necessary to turn off the extra ones. That’s not a problem for folks working from the new config, but a lot of old ones are are founded on the zero buttons principle. There are other areas where it applies as well.
The point is that the null config is the starting point for every FVWM config currently in existence. Change those default conditions and’re going to break some configs. I expect that can sell some limited breakage to the workers list if it’s in a good cause, but on the whole I’d they’d prefer a minimal impact. Someone is going to have to answer a lot of “the last FVWM update broke my config” posts otherwise.
Poor choice of words perhaps. Consider this: New user starts off, gets a nice minimal config. Reads the manual, thinks “ok - I’ll write my own config”.
Then he creates an empty config, adds a single menu item, and suddenly loses the background, the menu buttons… I’d be confused by that - I’d think I’d broken fvwm.
[edit]
fixed a broken quote
Maybe. Xnest is far from perfect, but it usually an accurate depiction of what should happen. I did also run it outside of Xnest, with no apparent issues – even more so with the latest update.
I don’t know what causes that.
That’s OK. I don’t mind keeping it on-going.
True, but it’s a facet of the configuration file being read, and not inbuilt. With the test data I’m using here, writing my own config does clear the buttons, whether I define two or four. But your point is taken.
Fine, so leave the internals as they currently are, then. I don’t want to be responible for questions like that. It’d get too tedious. 
– Thomas Adam
Using the new fvwm build and my old config I get four icons rather than two on my titlebars and the title fonts are in ArialBlack rather than the Oberon font I selected.
The problem seems to be that, while the new ConfigFvwmDefaults file has been copied to $FVWM_DATADIR/config, the old ConfigFvwmDefaults file has not been restored.
Like I say, on my machine the effects of ConfigFvwmDefaults do not seem to get flushed.
hmm… must remember posting after having had a few is a bad idea.
Thomas, are you sure you uploaded/linked to the proper tarball? That one looks like the old one to me.
Damn. Well-spotted. I’ll get on that a bit later. Oops…
– Thomas Adam
Staying to the original topic: My suggestions:
alt+tab -: Installed fvwm, reading fvwm beginner guide in my browser, starts fvwm, looks around, presses alt+Tab to go back to brower for furthur rea… Uh no alt+tab???
IMHo Something bsic as Alt+tab must be in the default config. I mean clearly its impossible for ppl to use fvwm without basic window switching.
nad it wasn’t easy figuring out also, took me hours before I cld get alt+tab working… and that too isn’t perfect.
Clickto raise: You ppl must have your reasons for not having this, but to me it seems that this definitely should be the default behaviour, specially when alt+tab isn’t there.
Just think about it from the point of view of somene completely unfamiliar with FVWM , how do you expect them to switch windows without alt+tab or click to raise?? The only way left is to resize a window, click the title of the window needed to be raised. To switch again, resize this window click title bar of the first window. how can this be default!!
Iirc Alt-Tab pops up the WindowList by default, which should be pretty straightforward to use.
Personally I find having to click on a window to focus it simply horrible. The fact that most people find this ‘natural’ is only because Windows (and the Windows emulating defaults of KDE and, to a lesser extent, GNOME) use this. Clicking on the titlebar seems like a pretty decent way to raise windows, if you set Style * ClickToFocusRaises windows will also get raised when you click somewhere in them, if this isn’t the default then I agree with you that this should be the case. I am against making ClickToFocus the default though as the only reason to do this would be Windows users’ familiarity with this way of focusing windows.
You’re under the impression that there’s some predefined behaviour. Cool. When Nick and I designed this, we were opting for something that couldn’t possibly please everyone, so we didn’t even try.
It is in the “default” configuration.
It has been a bone of contention with people for years – there’s lots of alternatives though:
FvwmIconMan
FvwmWinList
WindowList
FvwmWindowMenu
[…snip…]
– Thomas Adam
Us “ppl” can’t please everyone – welcome to the world of free-choice, subjecticism, and sweetness of light – where everything can be fluffy, with fairy cakes too, if you want.
See above. Look at FvwmAuto in using SloppyFocus. You might like it. Did you read this thread? I doubt it – there’s about ten pages on the subject of subjectivity, along with a pertty good rationale as to why Nick and I chose what we did. The entire point of this exercise was to make it such that you as a user could do what you wanted and to change those parts you didn’t.
I’m not going to say another word on this.
– Thomas Adam
It is not in mine… ubuntu here. Maybe it is different for different distros or maybe coz I am using version 2.5.14. Was it changed in the latter versions?
Click to focus?? where did that come from?? read my post again plz
well then you do agree with all I am suggesting. Thanks 
type this in google “define:suggestion”
Sloppyfocus?? Did YOU read my post?? ofcourse not! I clearly stated clicktoraise!!!
I am only suggesting a default config, how will that change what the user can do with his config?
Instead of writing a nice flamy attack I’ll give u a bit of advice man…
RELAX!!! you get worked up too often… maybe something’s up in your offline life, that’s spilling here… which happens to all of us.
The world doesn’t hate fvwm, you don’t have to defend it every time, specially when no one is attacking it. So just calm yourself… go out more often… just a bit of friendly advice 
Thought you should know this but I have been using linux exclusively for the past six months, so there is no need for such comments. Secondly a default config of a window manager has got nothing do with the freedom that linux gives.
Like i said stop ttreating linux as a religion.
Check to make sure your Numlock isn’t on. I think that probably messes up even the alt tab and there’s an FAQ around here somewhere that talks about the Numlock. If you’re using gdm (ubuntu defaults to it), I think that turns on numlock, but I’m not sure on this. It could even be something else in the boot-up process…
This was already addressed; The style line suggested by theBlackDragon should do what you want. Or were you suggesting it be in the default configuration? This goes back to what the others were getting at about personal choice and not being able to get a perfect default setting that pleases all people, all the time. I don’t like clicking for focus or having what’s in focus raised, so if this were the default, it wouldn’t please me.
The problem with text is that it’s easy to misinterpret the intent behind a posting. Try not to take offense at what people type, they may not have intended for such an interpretation.
No i was saying that everyone should be forced to use this :p .Isn’t it obvious that it was a suggestion for default config, what else could it be?? besides, I quote myself:
Is it possible that there is a config that pleases everyone, all the time? Did I suggest that what I say has to be right ??
Then what is the point for telling me that there cannot be a config that pleases everyone?
REMINDER:The topic of the thread is “Lowering the barrier for newbies”. the first line of my post :
In simpler terms these were my suggestions, neither did I say or feel or for that matter even possible that the default config pleases everyone.
Hi chesss, thank for taking an interest.
IIRC, part of the problem is that several of the distros customise the ConfigFvwmDefaults file which handles a lot of the default behavior. No reason why they shouldn’t really - it’s no different that Ubuntu setting its own wallpaper and themes for Gnome, but it does lead to confusion. For instance on Gentoo, if you start FVWM for the first time you get a basic horrible grey x11 mesh and it looks like the WM is broken (which is how I came to raise this subject). On the other hand some distros (I belive) add a basic backdrop. This made it quite hard to explain the problem on occasion, since people tend to assume that their distro does it the “proper” way.
Now on Gnetoo, alt-tab Just Works. On the other hand, when we started tweaking the tarball from fvwm.org alt-tab didn’t work for me until I pestered Thomas about it, so maybe it’s one of taviso’s tweaks to the gentoo ebuild - or maybe someone at Ubuntu doesn’t like alt-tab. The way to know for sure is to look in ConfigFvwmDefaults from the current tarball.
As for click to raise (alt-tab too, really) - you should bear in mind that we’re not FVWM devs as such. Thomas and I were working on a new desktop so we could submit it to the regulars of the fvwm-workers list and see if they thought it worth including. So if you’re saying that the current out of the box behaviour needs to change, then sympathetic as I am, you’re probably saying it in the wrong place.
So I suppose if you want to get some changes made, you could petition the Ubuntu devs; or you could subscribe to fvwm-workers. Or, if you like, you could help get the replacement desktop project up and running again. It’s something I’d still like to see happen.
They can’t do that, since it would break with how FvwmForm-Setup handles things. Since it’s an undocumented feature that FVWM reads this file before it processes any of its own startup files, it should be left alone. I have never encountered a distribution which has any need to modify this file – it’s somewhat pointless.
That grey mesh as you call it ;) is as a result of there being no wallpaper set. Now, I have known a lot of distros in the past to use things like xloadimage(1) and xsetroot(1) in X11’s global startup directorty in /etc/X11 to do things (RH and SuSE were infamous in this way) – but again, ConfigFvwmDefaults was never touched.
Nope – there’s nothing special about that. You’ll have to remind me what it was I was pesterd over (;)) but I suspect you were bitten by the NumLock bug.
Indeed – there’s many things about it which lay unfinished.
– Thomas Adam