Looks excellent to me. I’d perhaps add a comment that the FvwmWiki [fvwmwiki.org] is another resource that can be used… 
– Thomas Adam
I edited the post to include FvwmWiki. I also moved the help function in front of the StartFunctrion defs so I can talk about functions in general before I start on the special case of StartFunction
Ok… well, finally I’ve done what you’ve all (ha!) been waiting for. I’ve taken 2.5.12 (not the CVS version, I must point out) and tweaked it such that the default menu at least looks friendly.
I’ve further defined / overwritten “ConfigFvwmDefault”, which was the file that used to supply those horrible grey/almost black window borders, with Nick’s new config file. I’ve also added/changed it slightly such that there’s a simple decor for all windows – if nothing more to demonstrate that you can have windows that close/maximise and minimise. I neglected (alas) to nab the new config file in the post above this one, so likely that invalidates most of my comments changes made to the file – feel free to do as you please, though.
There’s still a lot of work to do – the ‘ConfigFvwmDefault’ file is the one that that FvwmSetup form copies over to $[FVWM_USERDIR] – that being the case, we’re going to have to bombard that file with a bootload of comments, in addition to the excellent “GettingStarted” file that is already defined. I’ve started to add comments to the ConfigFvwmDefault file, but they’re peacemeal at best, and far from perfect… bear with us.
Nick – what do you think? I’ve yet to add xft font definitions in-built to Fvwm’s internal decor, should no config file be found. I had some issues in doing that, so left it as it was – the menu’s at least show them, and if the ConfigFvwmDefault file can be read, it is far from a problem, anyway.
Some suggestions that we can now start to think about…
* WindowOps Menu
* RootMenu
* Key/Mouse bindings
* Complex Functions
* Stroke Functions
etc, etc. I’ve also included in the tarball my “al.sh” script which invokes Xnest so that I can work on this without starting up VT8. I’m sure some will find it useful.
Please, let me know if/what I’ve done is any good or not, and if there’s anything that needs improving.
I suppose you want to know where the tarball is? It’s Right Here.
– Thomas Adam
Fetching it now 
My suggestion for WindowOps -menu:
To next desk (/page)
To previous desk (/page)
Ok, changed some glaring bugs (unsure about how they got there), so you’ll have to redownload the tarball.
Some feedback I’ve had from some poor souls I tested this with (my housemates in fact):
* The red writing on the banner wallpaper against the blue background looks weird.
* The shadow on the menu’s font makes it very hard to read. I agree with this – perhaps we can switch to white, to offset the contrast a bit?
You’ll note that currently, the “helpfile” is set to /usr/local/share/fvwm – this is intentional for the time-being, and will be changed pending further revisions, recommendations, etc.
– Thomas Adam
Downloading again. I missed your comment about xnest first time round. That’ll help here since I’m running nvidia drivers and I get the dreaded black screen of death if I swap VCs to often.
The window icons are a good idea - I hesitated to suggest any earlier, but having to work, around the barebones decor is one of the biggest pains of FVWM.
The drop shadow seems to give everyone problems, so by all means, let’s change it. I’ve a had a bit play here. Maybe gray80 for the shadow and reduce the shadow down to 2 points? White with a three point shadow looks like a 70’s flashback somehow.
The “anywhere” on the banner could use some emphasis. White works quite well there. Does anyone else find the FVWM moggy looking a little pixelated? It seems to be an artifact of the way FVWM handles transparency. If I put it onto a blue background, it seems smooth enough.
Window operations: are we having multiple desktops? I don’t mind, but we might want different colors for the grad for each of them so there’s some visual distinction. Of course then we’ll need a pager - there’s a danger of feature creep here as the excitement sets in.
Shade, stick, keep on top, keep on bottom, close, destroy… We could do with a default icon for that iconify button…
Heh, we’ll I have a cheap S3 card here which has served me well… 
I tested this on my P166 and it’s fine. It even works on my 486, although as that only has an 8bit colour display, the gradient backgrounds look a little odd. Useable, nevertheless.
Well, there isn’t one. Internally, to Fvwm (assuming it cannot find any config file to load), the only thing it sets up is the default root menu, and the window colours. Decor’s are only defined by us (the user) so to that extent, we have some flexibility.
Ok, I’ll incoporate those suggestions. I’m also going to have to look into using it as a default font in Fvwm if not config is found – my changes resulted in a segfault each time, but I think I know why, so stand-by for that change.
I can’t say I’ve noticed it, but I haven’t been looking too hard, to be honest. I’m no good with the Gimp, Nick – can you possibly change the background wallpaper to reflect the changed colour to white, and shove it on the web for me to download?
There is that – the way Fvwm does things from a default manner is that the SetupForm (I don’t mean that hideous win95 one) copies over ConfigFvwm<module_name> files from /usr/share/fvwm/Fvwm<module_name>/ (or wherever fvwm is installed) to ~/.fvwm – so all we would have to do is change each of those files in turn to fit whatever changes we want to make as and when they’re decided.
When Fvwm loads with no config (or even if it does read ‘ConfigFvwmDefaults’) no Module config files are loaded until the user installs whatever they select from the SetupForm anyway. I would suggest that adapting that FvwmForm to suit our needs would be beneficial.
Yes – the bindings of mouse → window as I have them at the moment were just for me to play about with, and at a minimum effort allow people to move windows around, shade them, etc.
What do you think?
– Thomas Adam
Good to know I’m a week or two away from rehabilitating my P166, and with no cd-rom updating the system is going to be a right pain.
Done and done. Here’s one with a transparent background:
The white text does show up in the grad, honest 
And here’s one on solid blue.
We may need to bind mouse 1 clicked on the banner window to popup the root menu, lest someone click on the banner, wonder where the menu is, and decide the software is broken.
Interesting. I hadn’t taken it that far, but I can see the sense in that, yes.
About the bindings or in general? The bindings are all pretty intuitive to me. The only surprise came in not being able to work out how to raise a window. In general, I think it’s fine.
Anyway, I think it’s high time I was asleep. I’ll think some more on this tomrrow.
Ok, apart from my body clock being screwed, I’ve made the following changes (not in any specific order):
1. Changed fvwm-welcome.png to use the new “white words”.
2. Changed the font shadow to use two points, and gray80 as its colour.
3. Added some more comments to the ConfigFvwmDefaults file, and incorporated Nick’s original comments into the file where applicable.
4. Added a few minor comments to $[helpfile] as well as some URL references to suppliment the text.
5. Added an example ‘WindowOps’ menu bound to Window button 1.
Make sure you Redownload it. Apologies for the ever increasing updates…
It’s an improvement, even if it is mostly behind the scenes. As to what we should do next, I’ve had a think and come up with the following…
The file we’ve been editing thus far, in terms of features, should remain pretty much as it is. I’m reluctant to add anymore to it for fear of feature-creep.
I didn’t explain the concept very well in my last post, so I’ll try again. The ‘ConfigFvwmDefaults’ file is the file that is read directly after the internal config in fvwm is read (implies no user or system-wide fvwm config file could be found). However, the config file that the Setup-Form copies over is entirely separate. This is good because the ‘ConfigFvwmDefaults’ file is literally meant as the bare-minimum, and I think we’ve achieved that at least, barring one or two touch-ups to it.
So, what I propose is all we do is replace the config file the form is expecting to copy over to the $USER 's ~/.fvwm directory with the current ConfigFvwmDefaults file, but go to town in it – define menus left, right and centre, etc.
When we’ve done that, all that then needs to happen is we replace each of the ‘ConfigFvwm’ files in $[FVWM_DATADIR]/Fvwm/ with our own definitions. In that way, we won’t even need to re-write the FvwmForm that governs that setup form, we’d just be dropping in our own config files.
What do you think?
– Thomas Adam
I get some odd things with this verson. The font is messed up somehow:
[FVWM][FlocaleParseShadow]: WARNING -- bad shadow direction in font description:
Shadow=3 switch:xft:ArialBlack
And the default banner is back:
FvwmBanner: ERROR finding image file in ImagePath
FVWM also crashed the first time I started it. Possibly because I had set
export FVWM_USERDIR=$HOME/.fvwm.newconfigWhen the directory didn’t exist. It seems ok in that respect now though.
Posted at 6:11am? Is that a symptom or a cause?
Not to mention stylistic evangelism
I think its a good idea, although I think I might like to tweak the form itself a little bit. Font and colorset mainly from a quick look.
Certainly it seems foolish to put together a clean modern default look and then have the setup form produce module configurations that were hip and trendy in 1995. I mean take the FvwmButtons config. It’s distinctive and it doesn’t rely on having package X installed, but it’s undeniably dated. How to preserve those good aspects while updating the look of the thing. That’s the question generally, I think.
Which reminds me - what do you think about sticking a link to this thread on the giant Gentoo FVWM thread. “Hey kids! We’re designing the next default FVWM interface, come and see!”. We’d probably get some more feedback into the process, possibly at the price of more noise…
Grasshopping back… What do you think about calling scripts to do a little auto detection and code generation. Nothing too heavy, just to detect some applications and use them if they’re there. I know we’re straying into FVWM theme territory here, but its hard to imagine a modern user interface without some sort of “web” button.
Or possibly codegen the form and give the user a drop down list to choose from? Probably making the setup process overcomplicated then.
I think to kick this around a bit more. There are a lot of possibilities here.
I’ve been playing with the default FvwmButtons setup
I lost the border and titlebar. The layered relief looks a bit OTT, I think, and I still need to look at the IconMan. Also while most of the panel is transparent, the biff/xclock/xload panels are faking it. The biff button I can do something about, probably not the other two.
The big question is do we keep this layout or try something entirely different. Certainly I have an urge to shrink that massive great “expand the pager” button. I could also do with finding out which apps form part of the standard X distribution and what ways they can be tweaked on modern installations.
I’m not at all sold on the yellow clock face, either. But clocks are easy
anyway - I must be off. I’ll pick this up this evening
Woops – I have vim to autocomplete some words, and it seems it matched the “sw” in the font line, and expanded it to “switch”. :oops: Fixed now, though.
Fixed. It seems having a quote on the same line as the pixmap line:
*FvwmBanner: PixMap $[banner] #commentThrew the module parser function.
That’s an internal variable to Fvwm (ideally) – I wouldn’t set it in your environement.
Oh sure – that’s fine. I was talking more from an inclusion perspective. It’s not that ugly and would simplify things a bit for us. Chaning the appearence of it would help.
Absolutely. Well, it seems that in today’s world, people want the following:
- A Pager
- A Clock
- Mail notification
- Some sort of load monitor
As far as generic apps go (that come with X11 as standard) then there’s “xclock” (which can be manipulated), and “xload”. We could use:
Test (x /usr/bin/myapp) ..... as a means of determining if one can use, say, “rclock” in place of “xclock”, or we could write (munge? 
) some FvwmScripts together to replace the clock and the mail notification. Hmm, I’d favour this – it would hit two birds with one stone, wouldn’t it? Subtly introducing FvwmScript to them, and we’d be guaranteed it would work, regardless…
It would probably serve us well to look at fvwm-themes for ideas, epecially in FvwmButtons configurations. What about having a pager with a button at the top, and two side buttons to change/flip desks?
Bring it on – we’re gonna get killed. I’ll let you do the honours for that, Nick.
Ah, I was being too pre-emptive. See above about my suggestions about FvwmButtons.
Agreed. There’s a danger of not being able to enumerate all the options that way. Give the user a form that’s simple. I was thinking about the form – perhaps we should alter it (once we have the themes complete) such that a “preview” button is included along side each module so that a user can see a little screenshot of what each module looks like. I mean, I remember when I first installed Fvwm. I didn’t have a clue what “FvwmButtons” was, much less what “FvwmBacker” did. Not from looking at the setup form, anyway.
Sure.
Oh, before I forget latest revision is here.
– Thomas Adam
more noise? 
That means I’ve made noise on this… well, I’d like to think it as constructive critisism. 8)
That was poorly phrased, wasn’t it?
morbusg, your comments have been sensible and constructive. you are more than welcome
I think it’s more an idiom of the English language than anything… certai nly I had to re-read it to see where any ambiguity could have been picked up on. But as Nick says, your comments are appreciated.
– Thomas Adam
That’s the latest version built. The we seem to be on arial rather than arial black (still an improvement in any event)
No errors though and the banner works again.
I just wanted a clean room I could hack about if I wanted, and erase when necessary without undue complications. It seems to be ok now though.
And a web button, I’d say.
I’m up for that. The clock is simple enough, and I was already considering how to do the mailbox notification script. It’s the load app that’s the problem.
Something else I was thinking about. It’d mean switching to a lower cell size on the button box, but that’s about time too. I’ve also been playing with the idea of a shaped panel
[code]--------
| |
| time |
| |
| load |
| << |
| -------------- |
| PAGER |
[/code]
Certainly with a shape mask, possibly with a background graphic. We’ve got a very sky-like screen here, so clouds would work. Or perhaps something to suggest a trpoical island in the foreground with … but the more specific we are the narrower the appeal. Clouds should still work though. Or maybe a basic texture. if nothing else, we could hide the xload mechanics that way 
Done
Good idea. I’d go for that.
Check the config file – I might have made a mistake, or defined the font incorrectly – I don’t use xft fonts per se. Glad the banner works, I like that.
Yeah – I use stow to do all of this…
So stick to using “xload” and (if need be) we can supply an Xdefaults file that gets xrdb’d when fvwm starts up. I’d like to use xosview or torsmo (as they seem to be the choice du jour at the moment) but it’s not likely they’re going to be installed, alas. We could test for their presense, but that’s just another thing to worry about…
Yes, I like that.
Maybe clouds, but as soon as you mentioned that, I immediately thought of Windows XP and Windows 98. Heh. We have blue, and you mentioned tropical – possibly, but something subtle, so as not to detract from the real purpose of what’s available when the config loads, if that makes sense?
I’m glad you said that about being more specific leads to a narrower appeal. As boring as my tastes are (I’m still chuckling to myself at the irony of me participating in this), I’d probably advocate more on the plain colour/gradient front as opposed to pixmap and background images – it gives us a little more scope, by not theming things too much, if that makes sense?
Thanks, I read and saw the post, so hopefully that should stir the nest a bit, hehe.
Ok, that can be one of the last things to be done. I must admit I’m at a bit of a loss as for what “task” I/we should be doing next – did you want to design an FvwmButtons template of the kinds of things you were after? Did you want me to look at the other config files for the other modules? Did you want me to look at some FvwmScript stuff for mail notification?
What about FvwmIconMan? That thing has more options than anything I know - you can group windows based on anything, it’s crazy. I’d like to see its inclusion in this somewhere…
– Thomas Adam
Got it! It looks like a search-and-replace casualty. We have
Style * Font "Shadow=2 sw:xft:ArialGray80"
instead of
Style * Font "Shadow=2 sw:xft:ArialBlack"
I wouldn’t mind but I saw that before and thought it must be some nuance of font encoding I hadn’t yet encountered.
Sounds about right to me.
Yep. All the same, the L shape suggests a mask, which is a chance to do curves. Which needs some sort of border. I’ll have a play with it
mmm… and it’s not going to be in the outline I suggested. By all means go for an IconMan configuration. I seem to have started on the FvwmButtons setup, but there’s plenty of work to be done.
Anyone else? morbusg? dragon?
Heh, OK. Fixed.
Yep, OK, should be good.
It doesn’t have to be active explicitly, but having it would be a good idea so that if it is selected from the setup form it would at least do something useful. Perhaps if it were to run along the bottom, making sure it doesn’t steal the space from FvwmButtons? I wouldn’t necessarily want it active either, but that’s where it might go.
One thing that I’m interested in – how many virtual desktops are we going to define, and how many pages per desk? Since it is a faily big pager, should we say nine? And have four desks?
Just a thought.
– Thomas Adam