Lowering the barrier to entry for FVWM newcomers

Talk about anything related to FVWM, but don't ask support questions here!
thomasadam
Administrator
Administrator
Posts: 3043
Joined: Mon Nov 08, 2004 1:12 am
Location: England
Contact:

Postby thomasadam » Sun Apr 24, 2005 4:14 pm

Nick Fortune wrote: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.


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.

Nick Fortune wrote: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?


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.

Nick Fortune wrote:

Code: Select all

        FvwmIconMan: Already have set the number of managers                   


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.

Nick Fortune wrote: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?


Correct. It must be just what is in-built to Fvwm.

Nick Fortune wrote: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?


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

User avatar
Nick Fortune
CatCoder
CatCoder
Posts: 315
Joined: Thu Nov 04, 2004 2:11 am
Location: Stockton, England

Postby Nick Fortune » Sun Apr 24, 2005 4:42 pm

ThomasAdam wrote: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.

How about:

Code: Select all

DestroyFunc FuncDetectXterm
AddToFunc   FuncDetectXterm
+ I Test (X $[FVWM_CALENDAR_COMMAND]) Break
+ I Test (X xterm)      SetEnv FVWM_CALENDAR_COMMAND xterm
+ I TestRc (Match)      SetEnv FVWM_CALENDAR_HANGON '"xterm"'
+ I TestRc (Match)      Break
+ I Test (X xterm)      SetEnv FVWM_CALENDAR_COMMAND aterm
+ I TestRc (Match)      SetEnv FVWM_CALENDAR_HANGON '"aterm"'
+ I TestRc (Match)      Break
+ I Test (X xterm)      SetEnv FVWM_CALENDAR_COMMAND rxvt
+ I TestRc (Match)      SetEnv FVWM_CALENDAR_HANGON '"rxvt"'
+ I TestRc (Match)      Break
+ I Test (X xterm)      SetEnv FVWM_CALENDAR_COMMAND eterm
+ I TestRc (Match)      SetEnv FVWM_CALENDAR_HANGON '"eterm"'
+ I TestRc (Match)      Break
+ I Echo WARNING: No Terminal Emulator Found


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.
ThomasAdam wrote: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.

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.
ThomasAdam wrote:
Nick Fortune wrote:

Code: Select all

        FvwmIconMan: Already have set the number of managers                   

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.

Dunno either - just summarising for the forum in this case.
ThomasAdam wrote:
Nick Fortune wrote: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?


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.

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.

ThomasAdam wrote: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...

in which case should we drop the launcher and quit icon to rest on the bottom of the screen...

User avatar
Nick Fortune
CatCoder
CatCoder
Posts: 315
Joined: Thu Nov 04, 2004 2:11 am
Location: Stockton, England

Postby Nick Fortune » Tue Apr 26, 2005 10:59 pm

I did a bit more digging on the placement problem. I tried setting

Code: Select all

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:

Code: Select all

[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:

Code: Select all

[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: MinOverlap

So 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.

User avatar
Nick Fortune
CatCoder
CatCoder
Posts: 315
Joined: Thu Nov 04, 2004 2:11 am
Location: Stockton, England

Postby Nick Fortune » Wed Apr 27, 2005 12:46 am

And the winner is...

Code: Select all

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...

thomasadam
Administrator
Administrator
Posts: 3043
Joined: Mon Nov 08, 2004 1:12 am
Location: England
Contact:

Postby thomasadam » Wed Apr 27, 2005 1:36 am

Nick Fortune wrote:

Code: Select all

Style * ResizeHintOverride


That was always a contention style, but I've never had any issues with it.

Nick Fortune wrote: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.


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

User avatar
Nick Fortune
CatCoder
CatCoder
Posts: 315
Joined: Thu Nov 04, 2004 2:11 am
Location: Stockton, England

Postby Nick Fortune » Wed Apr 27, 2005 9:09 am

ThomasAdam wrote: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.

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.

User avatar
theBlackDragon
Administrator
Administrator
Posts: 714
Joined: Wed Oct 27, 2004 9:22 pm
Location: Zingem, Belgium
Contact:

Postby theBlackDragon » Wed Apr 27, 2005 10:33 pm

Nick, concerning your FuncDetectXterm, eterm generally likes to install itself as "Eterm" (mind the capital), just thought I'd mention that :)

User avatar
Nick Fortune
CatCoder
CatCoder
Posts: 315
Joined: Thu Nov 04, 2004 2:11 am
Location: Stockton, England

Postby Nick Fortune » Wed Apr 27, 2005 10:43 pm

Noted, thanks. Fixed in the next release :)

User avatar
morbusg
CatCoder
CatCoder
Posts: 344
Joined: Sat Jan 08, 2005 12:56 am
Location: Helsinki, Finland

Postby morbusg » Tue May 17, 2005 11:27 pm

Nick Fortune wrote:I'm quite happy to change it to alt-p. The major reasons for mod4 were a) to minimise the clash with other software and b) to make constructive use of an otherwise dead and irritating key on my keyboard.

I suppose we could make it shift-alt-p to minimise the clash potential. I don't know if it's worth the effort of explaining it clearly.

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).

User avatar
theBlackDragon
Administrator
Administrator
Posts: 714
Joined: Wed Oct 27, 2004 9:22 pm
Location: Zingem, Belgium
Contact:

Postby theBlackDragon » Wed May 18, 2005 10:57 am

morbusg wrote:
Nick Fortune wrote:I'm quite happy to change it to alt-p. The major reasons for mod4 were a) to minimise the clash with other software and b) to make constructive use of an otherwise dead and irritating key on my keyboard.

I suppose we could make it shift-alt-p to minimise the clash potential. I don't know if it's worth the effort of explaining it clearly.

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: Select all

DestroyFunc MinimizeAll
AddToFunc MinimizeAll
 + I All (!"FvwmPager|FvwmIconMan|Panel", CurrentPage, !Iconic) Iconify true
 + I TestRc All (!"FvwmPager|FvwmIconMan|Panel", CurrentPage, Iconic) Iconify false

User avatar
Nick Fortune
CatCoder
CatCoder
Posts: 315
Joined: Thu Nov 04, 2004 2:11 am
Location: Stockton, England

Postby Nick Fortune » Wed May 18, 2005 6:47 pm

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.

thomasadam
Administrator
Administrator
Posts: 3043
Joined: Mon Nov 08, 2004 1:12 am
Location: England
Contact:

Postby thomasadam » Wed May 18, 2005 8:41 pm

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

User avatar
Nick Fortune
CatCoder
CatCoder
Posts: 315
Joined: Thu Nov 04, 2004 2:11 am
Location: Stockton, England

Where we are now

Postby Nick Fortune » Wed May 18, 2005 9:44 pm

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?

User avatar
morbusg
CatCoder
CatCoder
Posts: 344
Joined: Sat Jan 08, 2005 12:56 am
Location: Helsinki, Finland

Postby morbusg » Wed May 18, 2005 10:19 pm

ThomasAdam wrote: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.


Huh? No system immutable flags? Bugger.

User avatar
Nick Fortune
CatCoder
CatCoder
Posts: 315
Joined: Thu Nov 04, 2004 2:11 am
Location: Stockton, England

Postby Nick Fortune » Thu May 19, 2005 10:14 am

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?

User avatar
Nick Fortune
CatCoder
CatCoder
Posts: 315
Joined: Thu Nov 04, 2004 2:11 am
Location: Stockton, England

New Version - Patch and Tarball

Postby Nick Fortune » Wed May 25, 2005 1:34 pm

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.

thomasadam
Administrator
Administrator
Posts: 3043
Joined: Mon Nov 08, 2004 1:12 am
Location: England
Contact:

Postby thomasadam » Wed May 25, 2005 3:56 pm

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

User avatar
morbusg
CatCoder
CatCoder
Posts: 344
Joined: Sat Jan 08, 2005 12:56 am
Location: Helsinki, Finland

Postby morbusg » Wed May 25, 2005 4:15 pm

I'll give it a go and report if I have any problems.

User avatar
Nick Fortune
CatCoder
CatCoder
Posts: 315
Joined: Thu Nov 04, 2004 2:11 am
Location: Stockton, England

Postby Nick Fortune » Wed May 25, 2005 5:29 pm

ThomasAdam wrote: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.

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.
ThomasAdam wrote: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.

Again, entirely possible. I'm good with ordinary makefiles, but this .in and .am stuff is a bit outside my experience.

ThomasAdam wrote: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.

Can't argue with that - I just wanted to get the ball rolling again.
ThomasAdam wrote:They're really only very minor fixes. Tarball is here.

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.

thomasadam
Administrator
Administrator
Posts: 3043
Joined: Mon Nov 08, 2004 1:12 am
Location: England
Contact:

Postby thomasadam » Wed May 25, 2005 5:42 pm

Nick Fortune wrote: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 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.

Nick Fortune wrote: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.


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.

Nick Fortune wrote:Again, entirely possible. I'm good with ordinary makefiles, but this .in and .am stuff is a bit outside my experience.


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....

Nick Fortune wrote:Can't argue with that - I just wanted to get the ball rolling again.


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.

Nick Fortune wrote: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.


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.

Nick Fortune wrote: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'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

User avatar
Nick Fortune
CatCoder
CatCoder
Posts: 315
Joined: Thu Nov 04, 2004 2:11 am
Location: Stockton, England

Postby Nick Fortune » Wed May 25, 2005 7:34 pm

ThomasAdam wrote:
Nick Fortune wrote: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 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 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.

ThomasAdam wrote:
Nick Fortune wrote:Can't argue with that - I just wanted to get the ball rolling again.


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.

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.

ThomasAdam wrote: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).

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.

ThomasAdam wrote: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.


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.

ThomasAdam wrote:
Nick Fortune wrote: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'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.

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
Last edited by Nick Fortune on Wed May 25, 2005 8:29 pm, edited 1 time in total.

thomasadam
Administrator
Administrator
Posts: 3043
Joined: Mon Nov 08, 2004 1:12 am
Location: England
Contact:

Postby thomasadam » Wed May 25, 2005 7:54 pm

Nick Fortune wrote: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?


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.

Nick Fortune wrote: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.


I don't know what causes that.

Nick Fortune wrote: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.


That's OK. I don't mind keeping it on-going.

Nick Fortune wrote: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.


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.

Nick Fortune wrote: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.


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. :P

-- Thomas Adam

User avatar
Nick Fortune
CatCoder
CatCoder
Posts: 315
Joined: Thu Nov 04, 2004 2:11 am
Location: Stockton, England

Postby Nick Fortune » Thu May 26, 2005 12:14 am

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.

User avatar
Nick Fortune
CatCoder
CatCoder
Posts: 315
Joined: Thu Nov 04, 2004 2:11 am
Location: Stockton, England

Postby Nick Fortune » Thu May 26, 2005 12:07 pm

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.

thomasadam
Administrator
Administrator
Posts: 3043
Joined: Mon Nov 08, 2004 1:12 am
Location: England
Contact:

Postby thomasadam » Thu May 26, 2005 2:30 pm

Nick Fortune wrote: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


Return to “General FVWM discussion”

Who is online

Users browsing this forum: No registered users and 1 guest