Subject: FVWM: FvwmGeom: The Saga continues (fwd)

From: Elad Eyal <[email-masked]>
Date: Tue, 19 Aug 1997 23:07:27 +0300 (IDT)

Good morning,

	Is there any way to know when fvwm is 'busy' and when it's 'idle'.
Suppose I want to display a rubberband over the screen. If I want fvwm to
iconify a window, I'll need to hide the rubberband while it does it, and
redisplay it after it's done. Currently I have there a 
sleep_a_little(150000) which is almost too slow to be bareable, but this
is obviously not the best solution. The problem is that I paint the
rubberband with XDrawRectangle directly over root, and not in a window of
itself, ergo problems with window which overlap.

http://www.cs.bgu.ac.il/~elad/GEOM.tgz
 _
(_  /  _    /          ( E-mail pigeons nest in binary trees )
(__/__(/\_(/	http://www.cs.bgu.ac.il/~elad

--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Brady Montz <[email-masked]>
Date: 19 Aug 1997 13:29:29 -0700

> (__/__(/\_(/	http://www.cs.bgu.ac.il/~elad

Fvwm really needs the ability to do synchronization with modules in this
fashion. I had similar problems with FvwmIconMan when the user would use fvwm
to move my icon manager window. This is a complicated problem. My hope is that
after fvwm2 is officially released we can redo the module interface to allow
for tighter integration on such things.

None of that helps you though. I gather that your problem is just that while
rubberbanding, you send a command to fvwm to unmap a window. It's not that
fvwm is doing other things behind your back.

If so, then it shouldn't be too hard to add a new message type to handle
this. When a module sends a command to fvwm to execute, fvwm sends back a
packet when that command is completed. It seems that we would just have to
send that message back after the call to ExecuteFunction() in
HandleModuleInput() in module.c. Wouldn't be hard at all. And since your
module would be the only one using it for now, it shouldn't be a risky thing
to add.

It seems a reasonable thing to add. If a module wants fvwm to do something, it
should be able to know when it's done.

Now if you are worried about fvwm doing things that your module has no way of
knowing about, the only way to cleanly handle that is to add semaphores to
fvwm. The odds of that happening are probably fairly slim, and easily
controlled by the user (I quit netscape, which takes 20 seconds to actually
quit, and in the meantime start resizing windows. I should just know better).

-- 
 Brady Montz
 [email-masked]

---

From: Elad Eyal <[email-masked]>
Date: Wed, 20 Aug 1997 16:39:34 +0300 (IDT)

Good morning,

> to move my icon manager window. 

And how did you deal with it? (Or /where/ did you deal with it? I couldn't
find it in IconMan sources.)

> module would be the only one using it for now, it shouldn't be a risky thing

Apparantly, someone already did it. At least in my fvwm2-95 v2.0.42a,
HandleModuleInput() ends like that:

      ExecuteFunction(text,tmp_win,&Event,Context ,channel); 
      SendPacket(channel,M_FUNCTION_END,1,0,0,0,0,0,0,0);

and module.h states:

#define M_FUNCTION_END       (1<<22)

And it even works (providing you take into accout the M_FUNCTION_END
following the M_CONFIG_END. So much for today's hard work). Thanks.

> quit, and in the meantime start resizing windows. I should just knowbetter).

Absolutely. That's why there's a "refresh screen" a mousedrag away. :-)

 _
(__/__(/\_(/

---

From: Brady Montz <[email-masked]>
Date: 20 Aug 1997 12:26:11 -0700

Elad Eyal <[email-masked]> writes:

> > fashion. I had similar problems with FvwmIconMan when the user would use
> > fvwm to move my icon manager window.
> 

I removed an option which a lot of people liked (where it unmapped itself when 
empty). That resulted in removing all the ugly attempts at fixing the
problem. My particular problem was a race condition which led to FvwmIconMan
no knowing where it was on the screen correctly. 

> > module would be the only one using it for now, it shouldn't be a risky
> > thing to add.
> 

Well, looks like we should add that to fvwm then.