Subject: FVWM breaks xfm and moxfm

From: Bob Woodside <[email-masked]>
Date: Wed, 01 Dec 1999 10:19:03 -0500

I think some changes made in events.c a couple of weeks ago cause a
problem for file managers of the xfm family - they no longer seem to
detect double clicks with Button-1, which is how you navigate through
the directory tree.

	I've found that if I hold down the Alt (Meta) key while double
clicking, the clicks get through. Does anyone have any idea what's
happened here?

Cheers,
Bob
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 2 Dec 1999 10:11:23 +0100

> clicking, the clicks get through. Does anyone have any idea what's

Yes, I rewrote part of the decor code to make it work with rxvt's
transparency.  I'm quite sure there are several binding problems
cause by the introduction of the new decor_w (it has the size of the
frame and is the parent of all decorative sub windows).  Bob, could
you try to debug this?  I've got no time at all right now.  I've
noticed the same with XNest but thought it was a XNest bug:
My double click bindings on windows inside XNest running fvwm
don't work either.

Bye

Dominik ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Bob Woodside <[email-masked]>
Date: Thu, 02 Dec 1999 08:04:20 -0500

Dominik Vogt wrote:
> transparency.

	Which I believe is a bit on the buggy side to begin with.... :-(

> Bob, could you try to debug this?  I've got no time at all right now.

	Seems like 'tis the season...  :-(

	I'll try to take a look at it this weekend, if I can figure out what
the change was.

Cheers,
Bob

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 2 Dec 1999 16:02:07 +0100

> 	Which I believe is a bit on the buggy side to begin with.... :-(

Well, X doesn't support transparent windows.  That's the whole problem.
With all the work I and Geoff Wing spent debugging rxvt's transparency,
I guess you won't find a better implementation.  Eterm uses a different
approach, but that requires a third-party program (esetroot).

> 	I'll try to take a look at it this weekend, if I can figure out what

Don't mind about the individual changes, they're not going to change
back.  Try to track down what is happening with the Button... events
instead.  We've got to find out why single clicks pass through to the
application but double clicks do not.  I'm quite sure this problem
can be resolved within HandleButtonPress() alone.

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Thu, 02 Dec 1999 17:58:34 +0000

> Yes, I rewrote part of the decor code to make it work with rxvt's

What are the problems that this solves?  I don't think we should be
adding stuff to fix bugs in other clients especially GPL ones under
current development.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 2 Dec 1999 22:34:18 +0100

> adding stuff to fix bugs in other clients especially GPL ones under

The problem that most 'transparent' applications set
'CopyFromParent' background on all their ancestory to
get the transparent look.  In my eyes it's the only
sensible solution, but it doesn't work if the window
manager wants to set its own background in a direct
ancestor of a client window.  Hence I introduced the
decor_w.  Now the frame windows is neither visible
nor ever drawn into and rxvt can happily do whatever
it wants with the frame background.

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 3 Dec 1999 09:10:14 +0100

> it wants with the frame background.

Furthermore:

My patches for smooth windows shading w/ bottom titles and
smoother opaque resizing wouldn't have been possible without
the decor_w.

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Fri, 03 Dec 1999 11:12:01 +0000

Dominik Vogt wrote:
> > get the transparent look.

That's very bad. Clients should not draw in other windows. It will
always cause problems.

> > In my eyes it's the only
> > sensible solution,

Well if the client want to be bad mannered and impose its ideas of
border appearance it could shape it's top level window and fvwm would
shape its ancestors to match (shape it with a rectangle of the same size
as the client). e.g. oclock. Personally I would like to be able to
decode if the borders are there or not.

> > but it doesn't work if the window
I'm concerned that this is going to add to load on the x-server.  There
are now three fvwm windows roughly the same size as the client instead
of two. Only one of them has the BackingStoreNotUseful flag set (rxvt
will load a pixmap into two of them and fvwm draws in the other) so the
server memory will go up 33%.

> smoother opaque resizing wouldn't have been possible without

Fair enough, this is a good reason to keep it.  I hope this doesn't
drive you over the edge but smooth shading doesn't work perfectly with
shade windows.  Try oclock, the oddities are different with
titleattop/bottom.

If we are going to keep it I think we should put in some efforet to
ensure the load on the server is kept low. We could make the frame and
parent windows depth 1 since neither are visible.

Cheers,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Fri, 03 Dec 1999 11:34:10 +0000

> decode if the borders are there or not.

  decide

> shade windows.  Try oclock, the oddities are different with

  shaped windows.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 3 Dec 1999 13:03:42 +0100

> decode if the borders are there or not.

Shaping is no solution for terminal emulators since they don't
really want to be transparent but rather let the root background
show through.  Furthermore changing the shape of a window
is really *really* slow.

> server memory will go up 33%.

So, then let's set BackingStoreNotUseful for the frame window.  It's
*never* visible.  It should be possible to reduce the frame window's
memory consumption to the size of the structures on the X server.

> shade windows.  Try oclock, the oddities are different with

8-) He, that's funny!  Does anyone know how to move the shape
mask?  Is there something like win_gravity for shapes?  BTW,
does anybody know where I can find documentation for the
shape extension?

> parent windows depth 1 since neither are visible.

Hm, if we make it depth 1 I think it's not possible to make
the background 'CopyFromParent'.

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Fri, 03 Dec 1999 14:22:17 +0000

> show through.  Furthermore changing the shape of a window
I think you misunderstood. What I meant that rxvt could create a filled
rectangle the same size as itself and shape itself with that.  It
wouldn't look transparent at all but fvwm would detect the shape and
remove the borders. I don't think it would be much slower as it would be
a very simple shape.

Anyway I think what rxvt is doing is wrong.  It should not be attempting
to alter the appearance of the window manager frame.  Users are quite
capable of typing "style rxvt handlewidth 0" if they want the frame to
be gone.

> the background 'CopyFromParent'.

I've had a peek in the rxvt sources and it looks like setting the parent
win to depth 1 may fix the problem that decor_w fixes.  If it does would
you be happy about removing decor_w?

Cheers,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Fri, 03 Dec 1999 15:50:11 +0000

> you be happy about removing decor_w?

Forget this, I've just tried and failed to get the client parent window
to be depth 1. decor_w lives.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 3 Dec 1999 17:56:58 +0100

> remove the borders. I don't think it would be much slower as it would be

Hm, funny idea.  But I definitely *want* a border on my 'transparent'
terminal windows.  On the other hand I don't use transparency because
I like to change my background pixmap from time to time.  Instead I
use a dimmed version of my standard background.

> capable of typing "style rxvt handlewidth 0" if they want the frame to

I don't think that rxvt was trying to annihilate the window
border.  It's just that is set 'CopyFromParent' on it's
ancestors so that the root background would be visible in
the client window.  Unfortunately we used the background
for a similar purpose.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 3 Dec 1999 18:09:43 +0100

> server memory will go up 33%.

Will the X server need memory for the parts of the frame/parent
that show through the client window because it uses 'CopyFromParent'?

> If we are going to keep it [decor_w] I think we should put in some efforet to

I've changed the frame window to BackingStoreNotUseful.  Fvwm doesn't
draw into the frame window anymore.

Bye

Dominik ^_^

---

From: Brad Giaccio <[email-masked]>
Date: Fri, 3 Dec 1999 12:12:59 -0500

> use a dimmed version of my standard background.

Just as an aside you should try Eterm in conjuction with esetroot, it 
allows you transperancy with a shading wich gives a very nice effect.

Brad
 
-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Bob Woodside <[email-masked]>
Date: Mon, 06 Dec 1999 10:15:04 -0500

Dominik Vogt wrote:
>                                                          Bob, could

	Hmm...I've found that if I use mousey-focus, the problem with xfm/moxfm
goes away. Dominik, I thought you were a mouse focus kinda guy. Do you
by any chance have the MouseFocusClickRaises GlobalOpt set? (I've also
found this to cause the same problem.)

Cheers,
Bob

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 6 Dec 1999 17:15:55 +0100

> found this to cause the same problem.)

Bob, I could narrow the problem down over the weekend.  It happens
exactly if buttons are grabbed in the setup_focus_policy() function
in add_window.c, i.e. if you use MouseFocusClickRaises or
ClickToFocus (plus I didn't care to remove the grabs if you switch
from ClickToFocus to Sloppy/MouseFocus).

My earlier guess that this might be caused by the excess Leave/EnterNotify
events proved wrong.  With xev I can verify that the window does indeed
get the double click, but for some unknown reason it doesn't interpret
it this way.  This seems to depend on the application: my rvxt windows
still recognize multiple clicks.

Bye

Dominik ^_^

---

From: Bob Woodside <[email-masked]>
Date: Tue, 07 Dec 1999 09:55:04 -0500

Dominik Vogt wrote:
> ClickToFocus...

	Right. The problem with xfm/moxfm is that the grab for Parent has to be
released at the same time as the grab for decor_w (in DoSetFocus) - and
reinstated for the window losing focus. Unfortunately, from there on
it's just gotten more and more convoluted - I never realized what a
delicate balance this was. After "fixing" this as described, I found
that I could no longer catch the focus change click in the client
window, without putting a grab on frame as well. That almost works...now
I'm trying to figure out how I've messed up the focus click on the
decorations (e.g., I can't click-hold-drag on the titlebar, I have to
click-release-click-hold-drag).

> This seems to depend on the application: my rvxt windows still
> recognize multiple clicks.

	It's very definitely application-dependent - I have several others that
understand double-clicks; and, at least in the case of xfm/moxfm, what's
really happening is doubtless buried under layers of Xtlib cruft.

Cheers,
Bob

---

From: Tim Phipps <[email-masked]>
Date: Tue, 07 Dec 1999 16:50:44 +0000

> the client window.  Unfortunately we used the background

Oh I think I see what rxvt is trying to do.  It sets CopyFromParent on
itself and all its ancestors and then does an XClearWindow on them all
when the root window pixmap changes.  I'm sure this is not the way to do
it.  It will fail if fvwm is run with a non-default visual option, and
it draws in the window managers windows. It doesn't work either. If I
use xv to set the root background rxvt doesn't notice until I move the
window.

All this is besides the point which is: fvwm should not be doing
anything to help or workaround bugs/features in rxvt.  That said it
looks like decor_w is useful for other things so let's keep it.

Cheers,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Tue, 07 Dec 1999 16:53:21 +0000

> that show through the client window because it uses 'CopyFromParent'?

I don't think so. It will just use the pixmap (which is shared among
many windows) to paint those areas when a refresh is needed.
> draw into the frame window anymore.

OK

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 7 Dec 1999 17:59:40 +0100

On Tue, Dec 07, 1999 at 09:55:04AM -0500, Bob Woodside wrote:
> reinstated for the window losing focus.

There should be no grab on the parent window anymore and the decor_w
has simply selected. The current method is summarised in the table
below (for ClickToFocus):

Frame            no grabs, not selected
  decor_w        selected
    title_w      no grabs, not selected
    left_w[]     no grabs, not selected
    right_w[]    no grabs, not selected
    button[]     no grabs, not selected
  Parent         no grabs, not selected
    client       grab all buttons

So you should never have to mess with 'Parent' or 'frame'.
I think all the grabbing in DoSetFocus is unnecessary now.
What happens if we remove thie grab/ungrab stuff there?

> Unfortunately, from there on

Bye

Dominik ^_^

---

From: Bob Woodside <[email-masked]>
Date: Wed, 08 Dec 1999 01:52:34 -0500

Dominik Vogt wrote:
> has simply selected. 

	Yes, I see you've made a lot of changes since I'd last updated.

> What happens if we remove thie grab/ungrab stuff there?

	It doesn't help the double-click case. I think the grabbing/ungrabbing
is necessary for exactly the type of programs represented by xfm/moxfm.
I suspect that our grabs clash with a grab done internally by some Xtlib
routine. I'm consistently seeing that we have to release our grab once
we focus the window (for ClickToFocus) in order for the app to recognize
the second click as part of a double click.

	The MouseFocusClickRaises case is a bit more awkward - the places where
grabs are released and restored for ClickToFocus won't work for
MouseFocus. The grab probably has to be freed in HandleButtonPress, when
we decide to raise the window.

	I'll tinker with it some more tomorrow.

Cheers,
Bob

---

From: Bob Woodside <[email-masked]>
Date: Thu, 09 Dec 1999 01:34:58 -0500

Bob Woodside wrote:
>   ....  I think the grabbing/ungrabbing is necessary for exactly the
> type of programs represented by xfm/moxfm. I suspect that our grabs
> clash with a grab done internally by some Xtlib routine. I'm
> consistently seeing that we have to release our grab once we focus
> the window (for ClickToFocus) in order for the app to recognize

	OK, I have this fixed now. Dominik, in my working copy I've changed the
grabs from the client window back to Parent. It seems to me that the
window manager shouldn't be putting grabs on the client window, any more
than the client app should try mucking with the window manager's
windows. Am I way off base here? Any other opinions?

> we decide to raise the window.

	...which is exactly what I did. AFAIK, this bug has been in
MouseFocusClickRaises ever since it was introduced. It's nice to see it
finally working.

Cheers,
Bob

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 9 Dec 1999 10:25:25 +0100

> windows. Am I way off base here? Any other opinions?

I moved the grabs to the client window because this prevents the
Enter/LeaveNotify events and is a bit easier to handle.  If it
works with the parent window - fine.  There were one or two places
where changes are necessary for client/parent grabs.  I'll take
care of these.

Bye

Dominik ^_^