Subject: Qustion about button grab and a patch for menu

From: Ke Huang <[email-masked]>
Date: Sun, 6 Jun 1999 15:51:23 -0500 (CDT)

First of all, here is a patch that enable hilight background on a gradient
menu. This is a feature I like, and it was available untill the recent menu
rewrite.

Do you feel this is the right behavior for menu, Dominik? I would like to know
your opinion... Maybe this should be made into a customizable option?

BTW, I do use SeparatorShort for my menus; I hope it would remain, but I could
live without it.

My question is about the stroke patch I submitted, here is the situation:

In my .fvwm2rc, I use Button 3 for the stroke button. This works pretty well,
except now that ButtonPress and ButtonRelease for button 3 are both sent to 
fvwm. Even when I am focused in another application. As I don't know much about
X programming, I really don't know how to solve this. What I want to do is for
fvwm to receive Button event wher I am in the context defined in the stroke
definition (for example, root). But when I am focused on another application's 
frame, I wanted to have some way for fvwm to release the grab on button 3. Can
anyone show me where should I change this?

*** fvwm/fvwm/menus.c	Sun Jun  6 12:23:32 1999
--- fvwm-test/fvwm/menus.c	Sun Jun  6 15:36:49 1999
***************
*** 2484,2492 ****
--- 2484,2494 ----
  
    /* Hilight or clear the background. */
    if (is_item_selected && MR_STYLE(mr)->look.flags.do_hilight
+ #ifdef 0
  #ifdef GRADIENT_BUTTONS
        && !is_gradient_menu
  #endif
+ #endif /* we do want to hilight gradient ment (kh) */
      )
    {
      /* Hilight the background. */

-- Ke Huang
------------------------------------------
e-mail:  [email-masked]  (preferred)
         [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: Mon, 7 Jun 1999 11:32:45 -0600

On Sun, Jun 06, 1999 at 03:51:23PM -0500, [email-masked] wrote:
> menu. This is a feature I like, and it was available until the recent menu
> rewrite.

Really? I thought it didn't work. Hmm, I think we had a discussion about that when
we made some enhancements to the menu gradient code and thought that wouldn't
work. But later we made a change that should have fixed it.

> Do you feel this is the right behavior for menu, Dominik?

Of course. What does the man page say about this?

> Maybe this should be made into a customizable option?

But it already *is* an option. Nobody forces you to use HilightBack if
you don't like it.

> BTW, I do use SeparatorShort for my menus; I hope it would remain, but I could

That's the problem with such features. If you have them you'll always find
someone who dosn't want to lose them :-)

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-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: Ke Huang <[email-masked]>
Date: Mon, 7 Jun 1999 11:04:26 -0500 (CDT)

>work. But later we made a change that should have fixed it.

Sorry for not making this clear. This feature was working for me in 2.3.2, and
It is broken since 2.3.3 (basically right after the menu rewrite). Now, by 
broken I meant the following config line will not give me a hillight without
the patch. And it is because in the hilight code, there is a specific check 
against gradient menu.

MenuStyle "*"\
    HilightBack Yellow, \
    Hilight3DOff, \
    ActiveFore Purple, \
    MenuFace DGradient 128 2 rgb:50/a0/a0 60 rgb:2f/b6/c2 40 white, \
    ItemFormat "%.4s%.1|%.5i%.5l%.5l%.5r%2.3>%1|"

-- Ke Huang

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 16 Jun 1999 22:52:54 +0200

>From what I see in the code you have already done it right. The buttons are
grabbed by fvwm over the corresponding parts of the windows. This is done
in the GrabWindowButton() and GrabAllWindowButtons() functions in
libs/Bindings.c.

I see you have missed some places where strokes should be handled. I've
fixed the places I am aware of. Can you try this with the latest CVS
code and tell me if it helps?

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: Ke Huang <[email-masked]>
Date: Wed, 16 Jun 1999 18:25:46 -0500 (CDT)

Actually the problem I reported with button grabbing is entirely my fault.
In my configuration, I had

Mouse 3 A A

to remove ALL of the bindings to mouse button 3. Unknown to me, this had the
side effect of causing fvwm to receive all buttonpress and buttonrelease event,
even if the pointer is in another window. Once I noticed this behavior, I
started to use

Mouse 3 R A

and this solved my problem. 

Although this works now, this behavior strikes me as incorrect. I would never
expect "Mouse 3 A A" to send normal application events to fvwm, because I would
expect "Mouse 3 A A" to just remove the bindings added by fvwm.

But everything works fine, now. So, I really don't have any problems.

-- Ke Huang

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 17 Jun 1999 01:38:30 +0200

> expect "Mouse 3 A A" to just remove the bindings added by fvwm.

That is exactly what it is supposed to do. The 'A'ny context tells fvwm
to bind this action anywhere on the desktop, regardless of where the
pointer is. 'R'oot is the context for only the root window. I don't
know where you got the idea, but certainly not from the man page, did you?

Bye

Dominik ^_^

---

From: Ke Huang <[email-masked]>
Date: Wed, 16 Jun 1999 19:16:59 -0500 (CDT)

I understand the idea of Any context to bind a key/mouse binding. But what I
didn't expect is that using Any context in the case of removal will remove
bindings not added by fvwm. The man page is clear on adding bindings, but it
did not make me realize that Any context removal will really remove everything.

But like I said, this is not a real problem, as making a special case for
removal is not really worth the trouble.

-- Ke Huang