On Thu, 14 Sep 2006 09:07:12 -0400 "Michael V. De Palatis" <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 13, 2006 at 01:58:28PM +0100, Thomas Adam wrote: > > <snip> > > > > > That's all fine and good, but that sort of goes around what I > > > want to do. In Sawfish, it's a trivial matter of specifying where > > > you want a window placed with its matched windows. The nice thing > > > about doing it this way is that it *does* work with programs that > > > don't accept -geometry. > > > > Indeed, but then note that it's circumventative of a much larger > > issue -- wherein it ought to fixed at the application level. > > I don't know that it's really that something is "broken," per se. Just > because there is a different design philosophy does not equate it to > being "broken." But I digress... ICCCM... > > > > Those are broken applications, IMO. If a program doesn't accept > > > > geometry options then it's probably an annoying EWMH-based one > > > > which delights in remembering its position for you. See the > > > > main FVWM FAQ for ways of circumventing that with FvwmEvent, as > > > > well as another explanation for it in #fvwm's FAQ. > > > > > > I'll look through it again. Does this mean that there is a way to > > > get styles to place my window properly? So far, I didn't find > > > it... > > > > No it does not. Note the following (taken off the top of my head): > > > > Style someCrappyApplication NoPPosition > > > > DestroyModuleConfig FE-MoveWindow:* > > *FE-MoveWindow: Cmd Function > > *FE-MoveWindow: add_window myFunction > > > > Module FvwmEvent FE-MoveWindow > > > > DestroyFunc myFunction > > AddToFunc myFunction > > + I ThisWindow (some_name, !Transient) Move 200 800 > > > > That's what you would do. (And read up on the Move command and the > > sorts of parameters it accepts, as well as looking at possible > > ResizeMove as well depending on your needs). > > I'll give something like this a try, I guess. I guess I just don't > understand why I can't get Style or something similar to just execute > the Move command without having to do all this extra work. It seems > like this would be a common enough thing that it would be allowed. You're misunderstanding what the Style command does. It sets *attributes* of a client. The "Move" command which you're describing is a command that operates on windows. Note that certain properties that can be bound to clients affect whether or not the operation on them will work at all. Consider what would happen if you had this: Style MyApp FixedPosition Next (MyApp) AnimatedMove 600 200 What do you think would happen? > One advantage of having FVWM putting the window in a particular place > rather than passing parameters is that I have several computers, many > of which having different screen resolutions. If I want to, e.g., have > a particular window placed at the upper right corner of the screen, it > is far easier to get FVWM to act appropriately than have some sort of > script or alias that does the appropriate thing depending on which > computer I'm on. I don't see a problem with that -- the Move command accepts positional arguments as opposed to absolute ones (again, the description in the man page is worth reading.) > By the way, perhaps there are other window placement options that I'm > not aware of, such as an UpperRightPlacement or something of that > sort. Unfortunately, scanning the single, huge manpage is incredibly > difficult --- It would be a lot easier not to overlook things if they > were split up a little more. There has long since been a discussion on the FVWM-Forums about a "default placement" argument to FVWM, which I am not in favour of. Note that in your example, "UpperRightPlacement" can be achieved with: Move -0 +0 Again via FvwmEvent. As to the splitting up of the man page, I have long since had an idea a kin to 'man perl', but have never broached this with the developers. -- Thomas Adam
