Subject: FVWM: Is this a bug?

From: David Wu <[email-masked]>
Date: Mon, 05 Jul 2004 19:20:09 -0400

Hi all fvwm gurus, I think this may be a bug but i am not sure. 

Steps to reproduce
1. open up any window in fvwm 
2. grab a corner handle to resize the window, but do not move the mouse
yet
3. with mouse button 1 pressed down. give a burst of mouse movement in
any direction to resize the window and let go of the mouse.

expected result: window resized and resize operation finishes 
actual result: the window is still in resizing mode and require another
mouse button 1 click to quit resizing mode.

I have been using the latest snapshot with Dominik's alt+mouse3 resizing
patch (thanks Dominik) with this problem when i resize the window
quickly.

Thanks in advance.

David

--
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: Thomas Adam <[email-masked]>
Date: Tue, 6 Jul 2004 00:38:50 +0100

On Mon, 05 Jul 2004 19:20:09 -0400
David Wu <[email-masked]> wrote:

> I have been using the latest snapshot with Dominik's alt+mouse3
> resizing patch (thanks Dominik) with this problem when i resize the
> window quickly.

Nope, I can't reproduce this. But I would have said more that this
depends largely on how you have defined your mouse bindings.

-- Thomas Adam

--
"Annie Hall leaves New York in the end. Press rewind, and Woody gets her
back again." -- "Look Inside America", Blur.

---

From: David Wu <[email-masked]>
Date: Mon, 05 Jul 2004 20:30:30 -0400

I have been able to reproduce this with no .fvwmrc file
this is the behaviour on my machine even for normal resizing (just
grabbing the handle)

has anyone else experienced this? if not this is probably not fvwm's
fault and probably some settings on my machine. However i did not have
this problem resizing under other window manager.

Thanks again

David

---

From: David Wu <[email-masked]>
Date: Mon, 05 Jul 2004 20:51:00 -0400

Hello, in further investigation I tried out the latest stable release
(2.4.18) and I wasnt able to reproduce the bug. Therefore the bug is
only in unstable. I will try to investigate more on which version this
was introduced.

David

---

From: Ben Winslow <[email-masked]>
Date: Mon, 05 Jul 2004 23:01:07 -0400

> this problem resizing under other window manager.
It just recently started occurring to me after an upgrade (2004-06-03 to
2004-07-04, ISO8601 dates.)  Unfortunately, that's not a very narrow
date range, and I also recently upgraded to the broken Debian X packages
mentioned in the "<F11> | <F12>..." thread, so I can't even narrow it
down to a problem with X or fvwm specifically.

> On Mon, 2004-07-05 at 19:38, Thomas Adam wrote:
<obligatory "please don't top-post" message>

-- 
Ben Winslow <[email-masked]>

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 6 Jul 2004 11:25:40 +0200

> patch (thanks Dominik) with this problem when i resize the window

It's a bug im my latest event handling patches.  I was already
aware of the problem but did not have the time to debug it.

Fixed.

Ciao

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]

---

From: Rusty Phillips <[email-masked]>
Date: Tue, 06 Jul 2004 11:09:49 -0500

Here's an implementation that makes icon captures based on Scott
Smedley's suggestion and Tavis Ormandy's fvwm2rc file.

It forks off the stuff that takes a long time and renices it to the
lowest possible priority.  The downside is that  there's a small chance
it will result in not getting an icon, and or the wrong icon because
there is only one variable to store icon captures.  I have yet to cause
the second condition, though the first I can cause on my slow machine if
I try real hard.

I'll try to figure out how to make it thread-safe later on today.

This uses FvwmPerl, along with this command for it: 
DestroyFunc eval
AddToFunc eval I SendToModule FvwmPerl eval $*

Enjoy!

DestroyFunc CaptureIcon
AddToFunc CaptureIcon
+ I raise
+ I eval open(TEMP12,"xwd -silent -id $[w.id] |"); \
    local $/; \
    $e=<TEMP12>; \
    close(TEMP12);

DestroyFunc UseCaptured
AddToFunc UseCaptured
+ I eval my $pid; $SIG{'CHLD'}='IGNORE'; if(!($pid=fork)) { \
    open(TEMP12, "|convert -scale $[fvwm_icon_size] -frame 1x1 \
    -mattecolor black -quality 0 xwd:- \
    png:$[HOME]/.fvwm/icon.tmp.$[w.id].png"); \
print TEMP12 $e; close(TEMP12); \
cmd("WindowId $[w.id] WindowStyle IconOverride, \
     Icon $[HOME]/.fvwm/icon.tmp.$[w.id].png, StaysOnBottom"); \
     } else { setpriority 0,$pid,19 }

DestroyFunc FastThumb
AddToFunc FastThumb
+ I CaptureIcon
#Use perl to store the pipe so that it can be used in asynchronous
coding.
+ I Iconify
+ I UseCaptured

---

From: Scott Smedley <[email-masked]>
Date: Wed, 7 Jul 2004 02:45:21 +1000

Hi Rusty,

> there is only one variable to store icon captures.

I suggest putting the UseCaptured stuff in an external script (written
in bash for maximum portability, or perhaps a language you're more
familiar with?).

If you iconify multiple windows in a very short period of time, I can
see long delays occuring due to a FvwmPerl bottleneck. With an external
script, each iconify action will create a new process which should
complete (on average) a lot quicker.

There may be other ways to do it, just thought you'd appreciate
knowing what solution seemed easiest to me.

>      } else { setpriority 0,$pid,19 }

What an awesome function! Fvwm, Perl & a bit of shell scripting! :)

SCoTT. :)

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 6 Jul 2004 16:57:26 +0000

> + I eval open(TEMP12,"xwd -silent -id $[w.id] |"); \

How is this last eval different from just:

  eval $e = `xwd -silent -id $[w.id]`

>      } else { setpriority 0,$pid,19 }

Don't expect any random fork() to work in FvwmPerl. You probably want:

  DestroyFunc UseCaptured
  AddToFunc UseCaptured
  + I eval detach(); setpriority 0, 0, 19; \
	saveFile("$[FVWM_USERDIR]/capture-$[w.id].xwd", \\$e); \
	system("convert -scale $[fvwm_icon_size] -frame 1x1 -quality 0 \
		-mattecolor black $[FVWM_USERDIR]/capture-$[w.id].xwd \
		png:$[FVWM_USERDIR]/icon-$[w.id].png"); \
	cmd("WindowId $[w.id] WindowStyle IconOverride, StaysOnBottom \
		Icon $[FVWM_USERDIR]/icon-$[w.id].png");

Not tested, but something like this should work better.

Of course, you may cause xwd to save directly into the capture file to
save some megabytes of FvwmPerl's memory.

> DestroyFunc FastThumb
> AddToFunc FastThumb
> + I CaptureIcon
> #Use perl to store the pipe so that it can be used in asynchronous coding.
> + I Iconify
> + I UseCaptured

Regards,
Mikhael.

---

From: Piotr Zielinski <[email-masked]>
Date: Tue, 06 Jul 2004 18:07:01 +0100

This is what I have in my .fvwm2rc (partially stolen from Tavis, I think):

DestroyFunc CaptureWindow
AddToFunc CaptureWindow
+ I Piperead "xwd -silent -id $[w.id] > /tmp/fvwm.icons/icon.tmp.$[w.id].xwd"
+ I Exec nice -19 convert -scale 110 -frame 1x1 -mattecolor black -quality 0 xwd:/tmp/fvwm.icons/icon.tmp.$[w.id].xwd png:/tmp/fvwm.icons/icon.tmp.$[w.id].png; FvwmCommand "WindowId $[w.id] WindowStyle IconOverride, Icon /tmp/fvwm.icons/icon.tmp.$[w.id].png"

>From time to time the following code is executed for each window (much
more often for windows whose icon hasn't been captured yet)

ThisWindow (CurrentPage, Raised, !Iconic) CaptureWindow

However, capturing the icon when a window is being iconified still
introduces a noticeable delay, so I don't use it.  Also, I'm afraid
that merely Raising the window before capturing is not enough for the
above condition to be true (different layers, different pages, ...).

Piotr

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 7 Jul 2004 01:04:47 +0000

On 06 Jul 2004 18:49:24 -0500, Rusty Phillips wrote:
> 
> Okay, comments about that script:

Please write to the list, not to me directly.

> 1)  I had named pipes on the brain.  This statement works just as well,
> and is smaller.  Good idea.
> 2)  Actually, I tried using detach first.  It crashed FvwmPerl for me. 
> On the other hand, forking didn't.  That's the reason I used it in my
> scriptlet.

I may try to suggest a fix if I see the problematic code. Was FvwmPerl
killed by fvwm for exceeding the ModuleTimeout? This would indicate your
code problem.

> 3)  As to putting it in an external script, I didn't do that as Scott
> suggested because I wanted to make use of named pipes (as opposed to
> writing a temp file, thus wasting more time), and I wouldn't get them if
> I had it in an external script unless I made two of them and did some
> interprocess communication.  I didn't want to resort to that.
> 
> 4)  There shouldn't be a bottleneck because it forks (creates new
> processes), just as it would if you were using an external script.
> 
> 5)  "Don't expect any random fork() to work in FvwmPerl"
> Why not?  Won't it do a good job if you fork and exit like I did?  
> What sort of problems can I expect?  

In your solution you manually fork FvwmPerl. I don't see where you stop()
the child. So, it seems like you create a new FvwmPerl child on every
iconification. Internal detach() implements the forking correctly.

> I was under the impression that FvwmPerl used pipes to communicate with
> fvwm, and those are inherited by child processes.

Yes, but when 2 processes write to the same pipe, bad things may happen.
So, forking is not something you may do freely.

detach() may usually work, but unix pipes are not that safe on fork. So,
if you want to be safe, use a single FvwmPerl process with or without
unlock(), you don't really need concurrency, you should just be faster
than ModuleTimeout. Alternativelly, create a new module that creates
thumbnails on iconify events. Just keep in mind that there are always one
read and one write pipe to fvwm behind the scenes. So, you may fork short
children, but only the main process should read/write to fvwm if you
really want to be safe. You may need your own event loop then to
communicate with children and fvwm. Or maybe use signals from children,
but then unix signals are not that safe either and may interrupt pipe
sysread in the middle... But there is the light, you just should find it.

Regards,
Mikhael.

---

From: Rusty Phillips <[email-masked]>
Date: Tue, 06 Jul 2004 20:24:23 -0500

Ah...I see the error of my ways.  Each time I fork, it becomes a zombie
when it finishes.  So...maybe a little help?

Obviously, detach would be the way to go here, except that FvwmPerl
kills itself when you detach it (at the end of this command).  Is there
a nice way to fork with FvwmPerl and have the parent process remain to
collect more input, while the child exits when it feels like it?

I'll look into FvwmPerl myself tonight and see if I can come up with
anything.

Other than that, I think that xwd is not thread-safe for some reason. 
I'd prefer not to put a lock on it, but that's what I'm going to try
after getting this forking thing working in some manner.