Re: FVWM: window placement

From: Dominik Vogt <dominik.vogt_at_gmx.de>
Date: Sun, 27 Jan 2002 18:28:09 +0100

On Fri, Jan 25, 2002 at 02:11:24PM +0000, David wrote:
> Hi Neil,
>
> You wrote:
>
> > I am running fvwm2 version 2.4.4 and find that the window placement
> > algorithm is overriding the position which the Java application I am
> > running is specifying. Is it possible to configure fvwm2 so that
> > position specified by applications is honored when specified?
>
> I have been having some discussions about this lately with fvwm
> support and I think there are still some unresolved problems
> with fvwm window placement.

With "fvwm support", David means me ;-) Come to think of it, I
hope I'll again do more development than support in the near
future :-)

> First, there may be a problem with XFree86. Try running your application
> in twm and/or mwm which come with XFree86 and see if you still have the
> problem. If so, then it probably is a problem with XFree86,

If so, this is almost the proof that the problem is *not* in
XFree.

> and I don't think you will get much help from the fvwm group.

There is no such thing as an "fvwm group". We are all volunteers
that spend a lot of our spare time on working on fvwm. You may
think about us what you want, but please keep your opinion in
private mails and don't offend the people who spend many hours
each year to make fvwm better - for nothing but happy users.
Personally, I want to add that I rarely spend so much time with a
single bug report as this one (at least four ours up to now).

> Second, try this group again showing that it works in the other
> window managers and not here.

Whatever. Showing that something works in one WM and not for
another proves nothing. It may still be either WM that is broken
or the application, or the X server, or X11 itself, or the OS,
or ...

In the case of Java applications we already know about some
problems in fvwm that are not present in mwm. Unfortunately there
are some hacks in mwm to cope with Java apps, but we can't find a
proper spec to do the same in fvwm.

> I think you will not benefit from playing with the resources mentioned
> in the other email
>
> Style my-java-app UsePPosition
> UseUSPosition
>
> These are style options for placement where the app does not specify
> placement.

Sorry, you're misunderstanding something. These options are
intended to be used *when* the application specifies the position,
not vice versa. UsePPosition tells fvwm to use the application's
idea of the proper position and UseUSPosition tells fvwm to honour
the user's position specification from the X resources. The only
way a window manager can distinguish between them is by looking at
the us_position field of the window's wm hints. Since some
applications set this hint although the user did not specify the
position, fvwm can be explicitly told to ignore it and come up
with its own. By default, both styles are enabled, but many
config files have

  Style * NoPPosition

In this case, the quoted line should indeed help.

> I have a specific problem with placement also. If I create a popup
> window like this:
>
> ac = 0;
> XtSetArg( al[ac], XmNautoUnmanage, FALSE); ac++;
> XtSetArg( al[ac], XmNresizePolicy, XmRESIZE_NONE ); ac++;
> wid_dialog_login
> = XmCreateBulletinBoardDialog( TheTopShell, "loginpopup", al, ac );
>
> And then use the .Xdefaults for placement:
>
> mtest1*loginpopup.x: 442
> mtest1*loginpopup.y: 94
> mtest1*loginpopup.width: 500
> mtest1*loginpopup.height: 320
>
> mtest1*loginpopup*lbl_caption.x: 0
> mtest1*loginpopup*lbl_caption.y: 10
> mtest1*loginpopup*lbl_caption.width: 480
> mtest1*loginpopup*lbl_caption.labelString: LOGIN SCREEN
>
> Then the loginpopup.x and .y will be totally ignored even though
> for example the loginpopup*lbl_caption.x will be honored: this is
> the same in twm and mwm, and probably is a bug in XFree86.

I thought we had already discussed this. The resource strings
"x", "y", "width" and "height" have *no* *special* *meaning* in X.
I repeat to make it perfectly clear: the X server *completely*
*ignores* these settings.

It is the application's responsibility to do something with these
resources. If you want this done by the x server, please use
"geometry" which works perfectly if used properly (as I have
already shown with your application). Remove all .x, .y, .width,
.height and .geometry settings from your .Xdefaults file, add the
lines I sent you and restart the X server (if necessary, reboot
your machine) and it *will* work. Period.

The reason why *some* of the .width / .height settings seem to
work is because the *application* or the X toolkit has implemented
them. Please refer to the documentation of Xt and any
applications you use to find about which resources exist and which
do not. To find out the proper Xt resource strings, you can use
the editres program that comes with x. It also has a nice man
page:

  $ man editres

If you need a book about Xt, try

  O'Reilly, Vol. 5: X Toolkit Intrinsics, Reference Manual

All your questions should be answered in above documentation.

> If I add
>
> mtest1*loginpopup.geometry: 500x320+442+94
>
> Then the geometry specification 500x320 is honored in twm
> and mwm, but not in fvwm and I think probably is a bug in fvwm.
> Could the problems in your Java application be connected to this?

See above, works properly if used properly.

Bye

Dominik ^_^ ^_^

 --
Dominik Vogt, dominik.vogt_at_gmx.de
Reply-To: dominik.vogt_at_gmx.de
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Sun Jan 27 2002 - 11:21:58 GMT

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:37:52 BST