keyword to specify initial geometries

a new DefaultGeometry keyword ?

  • That would be cool. After all, that’s the job of the WM.
  • It’s not worth it, we can live with some flickering.
  • No, this is just a useless load of junk.

0 voters

Some (badly behaved) applications do not let the user configure the initial geometry of their main window (e.g., Mozilla).

It should be possible to tell fvwm to use a specific geometry for each new window with a given name.

Currently it is only possible to tell fvwm to “catch” the event which occurs when a new window opens with a given name, and to move and resize the window when this event occurs. However this is a kludge, the window is first opened with a wrong geometry and then it is moved and resized.

It would be better if fvwm opened the window with the right geometry from the start, rather than open it and then move it. It would avoid any kind of flickering.

So I request a new keyword, like “DefaultGeometry”.

It seems other WMs can do it (e.g. Afterstep).

I very strongly agree, even though I don’t think I’d use the feature that much mysefl.

I would LOVE THAT! I can’t stand how some programs open up on the bottom right, where others open at the top left. I would love to be able to set where programs open and maybe even where certain windows for certain programs open.

For instance. I use Ubuntu with Synaptic. When I click “Search”, a new window pops up. This window is randomly placed on my desktop. I would like to be able to set that window to center itself directly in front of Synaptic’s window.

Heh, I switched to sawfish and now I have that feature :slight_smile:. Maybe fvwm will win me back if they add this feature hint hint

I know. I’ve written about this to death. It does break the ICCCM. I did
run across a patch for mozilla that did this at one point. (Google for
“mozilla geometry” – I think it was on the faq.org site.)

Why? The geometry is a facet of the client — it’s the client that sets
the initial geometry.

It’s not always that noticeable – it’s a kludge only in that the
application needs to be fixed. We shouldn’t go breaking FVWM.

I suspect all Afterstep does is to use the “kludge” method you describe above.

– Thomas Adam

I have a more pragmatic point of view. A number of clients are broken. There is an easy uniform way to work around this. Why not implement it ? Sure, it’s not the right solution, but it’s completely harmless, and very helpful for people who are prepared to use a feature of their window manager even if the said feature should not exist according to ICCCM.

It’s not always noticeable, but it is sometimes much more than noticeable, and that’s the point.

Adding a keyword that nobody would be forced to use would certainly not break FVWM. But perhaps you are talking about breaking ICCCM compliance, in which case I very strongly disagree that it would matter at all in this case, but I am not willing to argue about it here and now.

I haven’t looked at Afterstep’s source code recently, but from the user’s perspective, Afterstep puts windows in specified locations without any flickering; how it does it is unimportant.

Whether it exists in the ICCCM is irrelevant – there’s plenty of options that do. Where I have trouble adding a feature is if it breaks ICCCM compatability, since many applications do still adhere to this.

The discrepencies you’re referring to though can be somewhat circumvented via the various *PPosition style hints you can set on windows, and then (where desired) using some form of Resize command to adjust the window’s size. In almost all cases where this involves, say, Firefox, there appears to be options such as -width and -height to provide a very crude means of XGeometry. I don’t suppose for one minute the applies to all applications that eschew -geometry options.

Note that I have zero official status about what is/does not enter into the FVWM codebase. However, I would like to think that the more pragmatic view is to lobby these (often) EWMH-based applications that completely eschew any form of standards in terms of the ICCCM (which, I might add, FVWM is fully-compliant with) and get them to include support for user-supplied geometry settings.

I realise it’s an annoyance for most people, and I agree that is as well, but I don’t believe FVWM should evolve into an application which fixes the cosmetic appearence of an application’s shortcomings. That should be the developers job of the said application.

These are just my views of course. :)

Ultimately though, this is the wrong place for your suggestion. If you feel that strongly about it, implement it yourself and/or ask on the fvwm-workers mailing list. Once again, I do not speak for anything official about FVWM and besides uttering my own opinions here, that’s all I am able to do with any conviction.

– Thomas Adam

That statement is only true with

Style * MoveByProgramMethod UseGravity

:wink:

That’s alright – I never said “out of the box”, I simply made reference to the fact that it is. :P

– Thomas Adam