"Donald H. Locker" <dhlocker_at_chrysler.com> writes:
> Oops.
>
> Forgot to mention that things move because many of the progs that I've
> seen do the equivalent of the winfo x and winfo y to get current
> coordinates while building a changes struct to pass to the wm. Of
> course, if wm has a different geometry, then a move "to the same
> place" results in [at least] a one pixel shift left and up. (Because
> if they really were the same, the wm ignores the new location request,
> but processes the rest of the Changes struct, which is what it is
> supposed to do.)
Correct. There are ways you might be able to do it, but only if X had
semaphores. Basically you have two programs (the window manager and the
application) concurrently reading and writing a shared piece of data (the
window geometry), so there's no end to the possible race conditions. Not
good. I know of no way to make a window grow upward or leftward safely in
X. I've been completely unable to get anyone to tell me a way either.
>
> This is most irritating in T.A.Phelps' tkman and Module FvwmIconMan
> (which I would dearly like to change from
>
> *FvwmIconMan*1*managergeometry 1x15-388-2
>
> to
>
> *FvwmIconMan*1*managergeometry 0x0-388-2
>
> but it wanders)
>
> Donald.
I haven't seen FvwmIconMan wandering for some time, but I avoid the upward and
leftword growing modes. A managergeometry of 0x0 isn't even legal, and causes
FvwmIconMan to give an error message and exit. Could you elaborate?
--
Brady Montz
bradym_at_cs.arizona.edu
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Wed Nov 26 1997 - 14:18:21 GMT