Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode

2016-11-20 Thread Dominik Vogt 
On Sat, Nov 19, 2016 at 08:40:28PM +, Jürgen Hartmann wrote:
> 
> > > Unfortunately, this seems not to have any influence to our issue. After
> > > installing the modified binaries, Vmware still shows the old behavior:
> > > Returning from fullscreen mode yields a vanished window. This applies
> > > to Player 6.0.6 and Workstation 9.0.4.
> > >
> > > Did I throw out the right piece of code?
> >
> > Are you sure the patched fvwm was running?
> 
> That also was my first concern. But yes, I double checked that.

Try commenting out only the body of the if-condition, i.e.

--
args.do_return_true_cr = False;
if (
FCheckIfEvent(
dpy, &dummy, test_withdraw_request,
(XPointer)&args))
{
#if 0 /*!!!*/
...
#endif
}
--
 
Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode

2016-11-20 Thread Jürgen Hartmann 
> Try commenting out only the body of the if-condition, i.e.
>
> --
> args.do_return_true_cr = False;
> if (
> FCheckIfEvent(
> dpy, &dummy, test_withdraw_request,
> (XPointer)&args))
> {
> #if 0 /*!!!*/
>  ...
> #endif
> }
> --

This does the magic!

It seems to work perfectly, even if this is the only change done against the
officially released sources.

It works for both, Player 6.0.6 and Workstation 9.0.4.

Thank you very much, Dominik, for your persistent and successful help!!!

What is the secret behind this move? How does it work?

Juergen
(grinning happily)

Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode

2016-11-20 Thread Dominik Vogt 
On Sun, Nov 20, 2016 at 12:30:55PM +, Jürgen Hartmann wrote:
> > Try commenting out only the body of the if-condition, i.e.
> >
> > --
> > args.do_return_true_cr = False;
> > if (
> > FCheckIfEvent(
> > dpy, &dummy, test_withdraw_request,
> > (XPointer)&args))
> > {
> > #if 0 /*!!!*/
> >  ...
> > #endif
> > }
> > --
> 
> This does the magic!
> 
> It seems to work perfectly, even if this is the only change done against the
> officially released sources.
> 
> It works for both, Player 6.0.6 and Workstation 9.0.4.
> 
> Thank you very much, Dominik, for your persistent and successful help!!!
> 
> What is the secret behind this move? How does it work?

I have no idea, and I'd not even call that a workaround.  It just
seems that if you change random things, it starts to work.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode

2016-11-20 Thread Jürgen Hartmann 
> > What is the secret behind this move? How does it work?
>
> I have no idea, and I'd not even call that a workaround.  It just
> seems that if you change random things, it starts to work.

I see. That obsoletes my next question in the queue addressing side effects.

What would you propose to proceed?

Juergen

Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode

2016-11-20 Thread Dominik Vogt 
On Sun, Nov 20, 2016 at 10:02:39PM +, Jürgen Hartmann wrote:
> > > What is the secret behind this move? How does it work?
> >
> > I have no idea, and I'd not even call that a workaround.  It just
> > seems that if you change random things, it starts to work.
> 
> I see. That obsoletes my next question in the queue addressing side effects.
> 
> What would you propose to proceed?

1) Don't panic.  ;)
2) Try the attached patch.

Now, if I'd understand what (a) the patch in
HandleMapRequestKeepRaised() is supposed to do, and (b) why
XUnmapWIndow() is called in HandleUnmapNotify(), I think I could
write a decent fix instead of jsut disabling the parts of the code
that cause trouble.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
>From c179137faffbdebc5e2875a0f418b4679dc4fe94 Mon Sep 17 00:00:00 2001
From: Dominik Vogt 
Date: Sun, 20 Nov 2016 23:47:52 +0100
Subject: [PATCH] fix

---
 fvwm/events.c |   33 +
 1 file changed, 25 insertions(+), 8 deletions(-)

diff --git a/fvwm/events.c b/fvwm/events.c
index cc4cc8f..93cb251 100644
--- a/fvwm/events.c
+++ b/fvwm/events.c
@@ -518,6 +518,7 @@ static Bool test_map_request(
 	return rc;
 }
 
+#if 0 /*!!!*/
 /* Test for ICCCM2 withdraw requests by syntetic events on the root window */
 static Bool test_withdraw_request(
 	Display *display, XEvent *event, XPointer arg)
@@ -544,6 +545,7 @@ static Bool test_withdraw_request(
 
 	return rc;
 }
+#endif
 
 static int _pred_weed_accumulate_expose(
 	Display *display, XEvent *ev, XPointer arg)
@@ -3339,6 +3341,7 @@ void HandleMapRequestKeepRaised(
 	/* If the window has never been mapped before ... */
 	if (!fw || (fw && DO_REUSE_DESTROYED(fw)))
 	{
+#if 0 /*!!!*/
 		check_if_event_args args;
 		XEvent dummy;
 
@@ -3392,6 +3395,7 @@ void HandleMapRequestKeepRaised(
 
 			return;
 		}
+#endif
 
 		/* Add decorations. */
 		fw = AddWindow(
@@ -4159,20 +4163,31 @@ void HandleUnmapNotify(const evh_args_t *ea)
 	XEvent dummy;
 	XEvent map_event;
 	const XEvent *te = ea->exc->x.etrigger;
-	int weMustUnmap;
 	Bool focus_grabbed;
 	Bool must_return = False;
 	Bool do_map = False;
+	int do_unmap;
 	FvwmWindow * const fw = ea->exc->w.fw;
 	Window pw;
 	Window cw;
 
 	DBUG("HandleUnmapNotify", "Routine Entered");
 
-	/* Don't ignore events as described below. */
-	if (te->xunmap.event != te->xunmap.window &&
-	   (te->xunmap.event != Scr.Root || !te->xunmap.send_event))
+	if (te->xunmap.event == te->xunmap.window)
+	{
+		/* Handle normally. */
+		do_unmap = 1;
+	}
+	else if (te->xunmap.event == Scr.Root && te->xunmap.send_event)
+	{
+		/* Synthetic event on the root window; the client should have
+		 * taken care of calling XUnmapWindow. */
+		do_unmap = 0;
+	}
+	else
 	{
+		/* Nothing to do except updating some states. */
+		do_unmap = 0;
 		must_return = True;
 	}
 
@@ -4183,10 +4198,12 @@ void HandleUnmapNotify(const evh_args_t *ea)
 	 * unmapped (which is the case for fvwm for IconicState).
 	 * Unfortunately, we looked for the FvwmContext using that field, so
 	 * try the window field also. */
-	weMustUnmap = 0;
-	if (!fw)
+	if (fw)
+	{
+		do_unmap = 0;
+	}
+	else
 	{
-		weMustUnmap = 1;
 		if (XFindContext(
 			dpy, te->xunmap.window, FvwmContext,
 			(caddr_t *)&fw) == XCNOENT)
@@ -4206,7 +4223,7 @@ void HandleUnmapNotify(const evh_args_t *ea)
 		return;
 	}
 
-	if (weMustUnmap)
+	if (do_unmap)
 	{
 		Bool is_map_request_pending;
 		check_if_event_args args;
-- 
1.7.10.4

FVWM: Fix disappering fvwm windows

2016-11-20 Thread Dominik Vogt 
Hi Tom + Jürgen,

Tom reported some similar bug as in the current thread "Lost
Vmware window" (unfortunately not in the mail archive) in 2008
here:

  http://www.mail-archive.com/fvwm@lists.math.uh.edu/msg15827.html

I suppose both things are the same bug.  I've made a fix that
completely removes the code for the 2008 fix.  Could you please
both check out the branch dv/fix-disappering-windows from the git
repository and check that both your problems are /still) fixed?
The patch does fix the Vmware problem on my box, but the
description from 2008 is too vague to figure out how to reproduce
it.

Thanks for your help.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode

2016-11-20 Thread Jürgen Hartmann 
> > What would you propose to proceed?
>
> 1) Don't panic.  ;)

Truly a wise word... :)

> 2) Try the attached patch.

Done: It works great with respect to our issue. For Player and Workstation.

Concerning side effects, I can't say anything since I have no idea what
to look for.

> Now, if I'd understand what (a) the patch in
> HandleMapRequestKeepRaised() is supposed to do,

Which patch do you mean? Does the piece of code that you disable in events.c
origins from an earlier patch?

> and (b) why
> XUnmapWIndow() is called in HandleUnmapNotify(), I think I could
> write a decent fix instead of jsut disabling the parts of the code
> that cause trouble.

I am really glad that you are willing to dig into this.

Juergen

Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode

2016-11-20 Thread Dominik Vogt 
On Mon, Nov 21, 2016 at 12:27:45AM +, Jürgen Hartmann wrote:
> Concerning side effects, I can't say anything since I have no idea what
> to look for.
> 
> > Now, if I'd understand what (a) the patch in
> > HandleMapRequestKeepRaised() is supposed to do,
> 
> Which patch do you mean? Does the piece of code that you disable in events.c
> origins from an earlier patch?

Yes, it that piece may have been an attempt to fix the same or a
similar bug with another application.

It's really complicated, but let me try to explain what's going
on, in case we need to understand why I made the current patch -
at some time in the distant future.

--

1)

Window managers have special powers in X.  In the presence of a
window manager, certain requests of the clients are "redirected"
to the window manager for confirmation.  In the case at hand,
clients cannot map top level windows without the window manager's
consent (i.e. the MapRequest event gets redirected to the window
manager).  The same is not true for unmapping.  Clients can always
unmap their windows; the window manager is just informed when that
happens.

2)

There is this old "Inter Client Communication Conventions Manual"
version 2, that defines three distinct window states that any
window manager should implement: normal, iconic and withdrawn.
The latter means that neither the window nor its icon are visible.  
The ICCCM2 also describes how to get a window from each state into
the other two states.

3)

To withdraw a normal or iconic window, the client is supposed to
first unmap the main window.  As the window may not be mapped at
that time, for example if its iconic, the window manager may not
receive an UnmapNotify event for that.  To make sure that the
window manager gets it, the client is supposed to send a synthetic
UnmapNotify event to the root window (the window manager always
gets events for the root window).  (This synthetic event contains
the id of the unmapped window.)  In response to this event, the
window manager is supposed to write down that the window is now in
withdrawn state, and unmap the *icon window* if its visible.

4)

In HandleUnmapEvent() there was some code from the ancient past of
fvwm, that - whenever fvwm received an UnmapNotify (that it did
not trigger itself) - *it would unmap the window (that is was just
told has already been unmapped*.  I can only guess why this code
was there, maybe the author thought that the client was asking for
permission to unmap the window.

5)

For some strange reason, when vmplayer wants to un-fullscreen a
window, it requests the window manager to end fullscreen state,
then withdraws the window as described above, and after that I
lost interest in event debugging.  Supposedly it maps the window
again after that.

==>

Putting it all together:

  * vmplayer requests end of fullscreen mode
  * vmplayer unmaps the window
  * vmplayer sends the synthetic event as described above
  * vmplayer maps the window again (which needs fvwm's consent).
  * fvwm receives the events generated by vmplayer
  * fvwm looks at the two UnmapNotify events it gets (one real and
the syntehtic one) and calls XUnmapWindow.  This generates
another UnmapNotify event.
 * fvwm sees the MapRequest and generates the decorations
   for the window.
 * fvwm receives the UnmapNotify it generated itself, destroys the
   decorations and leaves the window unmapped.

Duh.

Obviously vmplayer cannot handle this strange situation and ends
up with no window mapped.

--

As far as I understand it, HandleUnmapNotify() is broken at least
since the day in 1998 when the fvwm sources were moved to CVS.
I've spent much time thinking about this, reading the ICCCM2 and
the Xlib manuals, and now I'm convinced that HandleUnmapNotify()
must never unmap the client window itself.  (The *icon* window is
a different story.)  However, since there's no documentation about
this bit of code, it's hard to guess whether there are or were
really broken clients that needed this buggy window manager
behaviour.  Anyway, if there are such clients, they won't work on
any modern window manager.

Over the years there were several patches to fix problems caused
by unmapping windows in HandleUnmapNotify, but none of us ever
figured out the real bug for more than fifteen years.  :-/

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: FVWM: Fix disappering fvwm windows

2016-11-20 Thread Jürgen Hartmann 
> Hi Tom + Jürgen,
>
> [...]
>
> I've made a fix that
> completely removes the code for the 2008 fix.  Could you please
> both check out the branch dv/fix-disappering-windows from the git
> repository and check that both your problems are /still) fixed?
> The patch does fix the Vmware problem on my box, but the
> description from 2008 is too vague to figure out how to reproduce
> it.

This branch solves my problem, for Vmware Player 6.0.6 and Workstation 9.0.4.
Great!

> Thanks for your help.

Wrong direction: I have to thank you! :)

Greetings
Juergen