You want to do the man page re-org as part of this submission? Fair enough; I’ll see about doing a rough cut.
Which reminds me, I had some issues with the background not updating. I should take a look at that too.
Good plan.
Agreed. Do you fancy putting a notice on the general fvwm list? it’s about the only resource I can think of that we haven’t tried to tap.
I don’t mean the man page “butchering” that you and I have planned as the next collaborative work, if you look at ‘man fvwm’ especially at the menu section, you’ll find scattered references to the default internal menu and to the “old” config file in general. If you want to go through and change it, by all means do so. Without reading the entire man page (again 
) I couldn’t say to what extent the “old” theme is embedded into it. Not much, from what I can tell.
I think it should be done as part of this release. Whilst seemingly boring, it would at least demonstrate the seriousness and thought that we’ve given this.
I’ve had it on one or two occasions. It seems to be related to the way in which the FvwmButtons are redrawn as a result of a change of Desk.
Sure. Stand by for that… 
I’ve also re-kicked the gentoo forums to make anyone feeling guilty even more so, to try this thing out and reply with recommendations here.
– Thomas Adam
Fair enough. It’s about time I read the thing properly anyway 
A minor tweak to the config:
[code]DestroyFunc StartFunction
AddToFunc StartFunction
Test (!R $[FVWM_USERDIR]/.noshow) AddToFunc StartFunction I
Module FvwmScript FvwmScript-StartMsg
Test (R $[FVWM_USERDIR]/.noshow) AddToFunc StartFunction I
Module FvwmBanner
[/code]
Currently we have the banner being displayed over the top of the StartMsg script, which looks weird, especially since the banner in incorporated into the script 
[edit]
Here’s another one I find useful:
[code]DestroyFunc FuncMaximiseFullScreen
AddToFunc FuncMaximiseFullScreen
Just a thought.
The desktop colour update problem seems to have gone away. Just before I compiled this release I was getting FvwmBacker crashing; said it needed to be started by fvwm (which it in fact was). That and the background update problem seem to have gone away in this release, so maybe it was related.
I’ll tackle that man page tonight, after Dr.Who 
A quick update, for the record and for anyone else following progress and helping with the testing (this thread is turning into a blog ):
We’ve been getting some feedback coming in from the fvwm mailing list, and in particular from one jpkotta, (to whom our thanks) who gave the setup a right good thrashing.
one thing that cropped up right away was that the clock didn’t display right due to (we think) ArialBlack not being found. I changed it to use
Font "shadow=0:xft:sans:bold;-bitstream-bitstream vera sans-bold-r-*-*-*-*-*-*-*-*-*-*"
And got this: 
which seems just as clear and a little better laid out. If xft isn’t installed, it uses bitstream vera bold, which is maybe what we should be doing throughout. props to morbusg and theBlackDragon who saw this coming a long time back.
It seems there are placement and decor issues using old configs with the version of FVWM we’ve hacked to accomodate the new default config. This is weird and counter-intuitive, since pretty much all we’ve changed are config files. Nevertheless, it looks like the title decor from the “no config” configuration isn’t being properly overriden by config files. For instance, I’m getting two extra buttons and my title bars in arial black. Anyone else want to try this? If there are any other cases of bleed through, we could do with knowing about it sooner rather than later
We’ve fixed a few more-or-less trivial bugs. A couple of typos , nautilius not picking up the no desktop option.
Some debate about whether to detect for terms other than xterm. Apparently Mandrake/Madriva doesn’t/didn’t install xterm by default. I’m willing to add in some alternatives; Thomas had his reservations about doing so. I’ve not taken any action yet.
We’ve had a request for named desks. I wasn’t worried about that since we don’t display desktop names. Then again this could be another issue that could mess up preexisting configs when FVWM bumps to the next release. Anyone have a setup or know of an app where this would cause problems?
There’s a weird FvwmIconMan bug somwhere. Sometimes it decides it’s going to grow upwards and creates a great big window the fill height of the screen. If anyone has any ideas or has seen something similar before, we’d love to know about it. It may or may not be related to this error:
FvwmIconMan: Already have set the number of managers
Otherwise, I’ve been going through the man pages looking for things that need changing. Looks like it’s not too bad/ I assume we’re documenting the “bare metal” behavior on the man page and not the post-setup one?
I’ve added a credits section to the Interface document. We need this to credit the icons and font in order to comply with licencing requirements.
We should do with something about icons. I tend to prefer Style * NoIcon myself. Failing that, where do we want them? My first thought was to send them to the trench between the launch bar and the quit icon. That would impact anyone who wanted to add launchers as a first step to modding the interface. Maybe grow right to left from the quit icon? or upwards from the quit icon perhaps?
right - that’s pretty much it. Nothing to post 'cause I’m still in the middle of about three things. More later
The more we try and second-guess, the more less-intuitive things become, IMHO. That said, Xterm is (bar the silliness that Mandr{ake,iva} seem to do) the de-facto terminal.
The names were purely arbitrary - and I chose them at random. AFAIK, there are no apps that rely on Desktop Names to be set in Fvwm, and if they do, they’d almost certainly be customised to a particular config file, I’d have said.
That error is in the way I had configured FvwmIconMan. According to what I’ve seen/read/observed, it’s harmless. I fail to see how it relates to the FvwmIconMan appearing vertically rather than horizontally.
Correct. It must be just what is in-built to Fvwm.
Maybe - but then we have the issue of the “xterm” scenario creeping up on us… as in which/what/where are there any icons installed. There might be some in /usr/share/icons, or /usr/X11/share/icons. Of course, this is where wm-icons comes in handy, but we cannot assume that that package is going to be installed always.
And anyway, we have FvwmIconMan – do we really need icons? We might if the user decides via the Setup Form that they don’t want to bother with it…
– Thomas Adam
How about:
[code]DestroyFunc FuncDetectXterm
AddToFunc FuncDetectXterm
That way we still use xterm if it’s there, and only if it isn’t do we start messing about with alternatives. It’s just a safety net.
Sure. I wasn’t entirely sure I understood the issue though. Might as well throw it open and see if anyone actually relies on the naming.
Dunno either - just summarising for the forum in this case.
Mmm… I was thinking to import one more icon from 48x48-infox set we’re already borrowing for our icons. There’s a big iconify icon that’d do to convery the idea that “something is iconified here”. Additionally, we already have icons we can use for tems and browser instances. Anything else takes the default icon, or they can supply their own. I’ve credited wm-icons in the acknowledgements section of the interface doc; maybe we should add them to the helpfile as well.
in which case should we drop the launcher and quit icon to rest on the bottom of the screen…
I did a bit more digging on the placement problem. I tried setting
BugOpts ExplainWindowPlacement and then launching my quit script under my regular fvwm and out hacked on. The appropriate path element (/usr/bin, /usr/local/bin) was boosted to the front of $PATH in both cases
On FVWM vanilla:
[FVWM][__explain_placement]: placed new window 0x3800001 'Session Termination!':
desk 0 (current desk)
current page
position 440 330 (used program specified position)On FVWM newconfig:
[FVWM][__explain_placement]: placed new window 0x2200001 'Session Termination!':
desk 0 (current desk)
current page
position 87 528, placed by fvwm (normal placement)
placement method: MinOverlapSo it seems that either the geometty flag is not being honoured, either because the placment style is pre-empting it, or because it’s not being seen by the WM. The manual says that placement styles are invoked only if no geometry is specified, so I’d guess the geomerty isn’t being passed on.
A quick test with xterm -g -1-1 and xterm -g +0+0 demonstrate that this effect isn’t restricted to modules
Any ideas?
[edit]
As a quick test, I copied ConfigFvwmDefaults.old over FvwmDefaults and restarted - placement then behaved as expected. It’s definitely some sort of bleed through from the defaults file.
[ It’s possible we’re seeing fvwm bugs here that’ve never come to light because the ConfigFvwmDefaults file isn’t generally modified by users. Or possibly because bugs have been fixed in the ConfigFvwmDefaults in the past rather than in the code. ]
I suppose the next thing to do is to comment out the new defaults file line by line until I find the culprit.
And the winner is…
Style * ResizeHintOverride
I comment this out, along with the actions for the two extra buttons and the font style and my config displays as I would expect it to display.
Let’s see if the raiser finds this clears up his problems…
That was always a contention style, but I’ve never had any issues with it.
I still don’t understand why I cannot reproduce any of the symptoms raised. To me, it is isn’t logical as I have nothing different set than anyone else using the configfiles to date. The more I try and reproduce these issues, the harder I fail, which is frustrating as it means I am unable to correct the problem.
– Thomas Adam
Which is in itself surprising. Maybe I should build a non-gentoo vanilla
fvwm and see if that exhibits the behavior.
I take it you’ve tried a few different configs with it? It’s possible that your regular config acts to mask the issues.
Nick, concerning your FuncDetectXterm, eterm generally likes to install itself as “Eterm” (mind the capital), just thought I’d mention that
Noted, thanks. Fixed in the next release
I’ve gotten a lot of catching up with this thread, so sorry coming in a bit late about this topic. How about an icon? You could have a “hide pager” icon, which could be left in there somewhere, and when you click it again, the pager would come back.
My guess is, gnome (and windows) users would find that logical, and something that they would expect to be there (well, they would expect a “minimize/unminimize all windows” -button, but anyway).
The last one is pretty easy to make, this is what I use:
[code]DestroyFunc MinimizeAll
AddToFunc MinimizeAll
I think I’d tend towards having the “minimize all” option in the menu, at least if we were going for windows similarity. In some ways another keyboard toggle would be better.
Apologies for the silence – Nick and I have been exchanging email communication – I’ve been very busy with Uni work, but now have a little time to play with this some more…
Nick, could you just recap to me where we are with this? I know from our discussions with jpkotta that some headway was made – and I am about to embark on the reasons why our config file doesn’t override some of the internal builtins. Can I ask, Nick, that you link to any lastst versions of files?
Oh, and as far as the pager/icon issues goes, yet again, such things are subjective – if a user wishes to change them (and it is a good demonstration of the reasons why they should – and hence one of the reasons why we’re working on this) then they can. But I’d rather keep the minimise all option for now.
Kindly,
– Thomas Adam
The big problem seemed to be settings from ConfigFvwmDefaults not being flushed before the user config is read. Particularly, I’ve noticed the font and window button icons persiting beyond what we had expected. I can generate a test config to demonstrate some of these issues at least.
The question is: bug or feature? If it is a feature, it goes a long way to explain why that barebones config persisted for so long. There are also functions in the standard ConfigFvwmDefaults file like EWMHActivateWindowFunc that are required if certain features are to work properly.
So if it’s a bug, we may encounter some resitance to getting it fixed. If it’s a feature, we may well need a rethink.
One approach would be to create $HOME/.fvwm and put the configuration elements from ConfigFvwmDefaults into that. That would solve the bleed-though issue for pre-existing configs.
So that’s roughly it. I think I had possible fixes for all the bleed-through issues I was aware of, including one from Jonathan Kotta for the weird taskbar problem. That’s one that I had problems replicating reliably, and so is very welcome.
Aside from that, we were pretty much there. We need to tidy up the banner/popup script issues, and I think if we’re going to autolaunch the setup script in the event of a no-config startup we probably want to embed the banner in the script, as per the default setup.
That’s all I can think of offhand. Anyone think of anything I missed?
Huh? No system immutable flags? Bugger.
A few things following on from my last post.
First of all, I missed one thing from the outstanding bugs list - the positioning problem. Basically fvwm seems to disregard geometry arguments and place new windows according to the placement policy. I still don’t have a proper fix for this one. I’m currently running using our hacked fvwm and as a consequence all my
buttons have to have geometry specified in the configuration, or else I have to add code to move them after placement.
Next: I had an idea for a config to show the problem: an empty config file. I’d expect that to produce the basic x11 mesh, no buttons, ugly fonts, etc, etc. What I get is exactly the same as if I had no config at all. The distinction here is that fvwm’s existing userbase built their configurations expecting a blank slate to work from - or at least a specific set of customisations. It seems unreasonable to pull the rug from under them.
Last thing: we don’t need to create a user config to do this properly. The manual says that /usr/local/share/fvwm/config (FVWM_DATADIR hopefully) will be read if no user config exists. We can put our customisations in there and then they should absolutely not affect user configs, since they will not be read if the user config exists. The downside is that if a user config breaks from an early syntax error, they’ll get the X11 mesh config rather than the "welcome to fvwm one, which may well be confusing. I don’t see how to avoid this.
All the same, I think the $[FVWM_DATADIR]/config route is the way to go.
[edit]
I tried this, moving the new ConfigFvwmDefaults file to config and the restoring the old version of ConfigFvwmDefaults. Under this setup my usual config runs without unexpected effects, the new one behaves as expected, and a null conifg produces a bare mesh - albeit with very pretty menus.
Anyone else want to try this, just to be sure it’s not just some peculiarity of my machine?