Subject: FVWM: problem with fvwm and Shake

From: Mark Bajuk <[email-masked]>
Date: Thu, 03 Mar 2005 12:05:15 -0500

hey there-

I'm experiencing a problem with fvwm and Apple's Shake (a compositing
package popular in the visual effects production world).  someone posted
the same problem to you back in august:

	http://www.hpc.uh.edu/fvwm/archive/0408/msg00104.html

I also found it listed as "incoming 1387" in your database.  it looks
like the conversation died without resolution.

Whenever a dialogue box or browser window for the application is opened
over the main application window (such as "open file", "import image",
"do you really want to exit  without saving", etc), the border of the
dialogue/file box flickers on and off as fast as it can, like 10 times a
second.  I can navigate the  filesystem via the browser window, but then
when I select my file and it loads, the dialog box never goes away and
I can never can get to the  session (although I can see that it loaded
in the background).

alternatively, if I hit the Cancel button on the browser window, after a
minute or 2 of fastly flickering border the interior of the browser
window disappears but the frame remains, flickering like mad.  after
another pause, the browser frame will finally vanish.

while this is going on, I cannot access any of my other terminal windows
or push or pop anything.  I can see on my xosview that my CPU is pegged
at 100%.

if I log in remotely, I see that it is fvwm that is taking up 100% of 
the processor.  if I kill the Shake application remotely, I see in my 
launching terminal shell that the application has exited (the prompt 
returns), but the Shake windows remain and fvwm continues to run at 
100%.  after a minute or 2, the windows (browser and main application 
windows) finally disappear and I get my session back.  the length of 
time seems dependent on how long the dialogue window has been up, as if 
there has been an enormous backlog of "type ahead" border updates, as it 
were.

To reproduce:

- launch Apple's Shake software
- in the menus go to File -> Open Script.  or Tools -> Image -> FileIn
- watch the border redraw like mad.

a couple of additional observations:
- if I first make the main application window small, such that the
second window does not overlap, the problem does not occur.
- this problem seems fvwm specific;  the app runs fine in, for example,
gnome.

if there is any soft of debugging/log inspection I can do to help trace
the problem, I'd be more than happy to oblige!

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

---

From: Dan Espen <[email-masked]>
Date: Thu, 03 Mar 2005 13:35:16 -0500

> like the conversation died without resolution.

I see it ending like this:

  I would look into the issue if I had any clu what you are talking
  about.  Please explain:
  
   * What is an "Apple Shake Interface handle"?
   * What applications are involved and where do I get them?
   * What exactly do I have to do to make this happen?
  
  Ciao
  
  Dominik ^_^  ^_^

Apple Shake is available for Linux,
but that's more money than I'm willing to spend to help
someone with a bug.
I don't think having the program would help anyway
it sounds like Fvwm and Apple Shake can't agree on the
dialog box window's position.  Fvwm wouldn't start
moving it around or redecorating it on its own.

Maybe you can try toggling the Fvwm 'decorate transient'
style.

If you bought the maintenance support shouldn't
Apple help out?  I couldn't find any open
support material at the Apple site.

-- 
Dan Espen                           E-mail: [email-masked]