Subject: ClickToFocusDoesntRaise...Does

From: Bob Woodside <[email-masked]>
Date: Sun, 19 Sep 1999 00:46:45 -0400

I've been reviewing my list of little annoyances today, in the hope
that we could clear up a few before 2.4. Here's the first one.

	I use ClickToFocusDoesntRaise, which I consider only a partial success.
The problem is that HandleButtonPress (events.c) has code to try to
force a raise if one clicks on the window decorations instead of the
client area to focus the window. Now, apart from the fact that I can see
no useful purpose served by this, it cause a couple of problems.

	First, since I have functions that include a Raise command bound to
certain window components (e.g., the titlebar), this results in
redundant Raises. RaiseWindow gets called twice each time I Button-1
click on the titlebar of a window that doesn't already have focus.

	Second, it causes RaiseLower to behave in a silly way when it's bound
to a mouse click on a window decoration (I have Button-3 on the titlebar
so bound). Let's say I have a window that is somewhere in the middle of
the stack. First, the window gets raised as it gets focus; then the
RaiseLower command gets its shot, and decides that since the window is
on top, it should be lowered.

	I tried the following little patch. I see no ill effects so far, and I
find the behavior much friendlier. Can anyone tell me a good reason why
this code should be left as it is?

Cheers,
Bob

--- events.c	Sat Sep 18 23:31:37 1999
+++ events.c-new	Sat Sep 18 23:33:32 1999
@@ -1334,11 +1334,7 @@
   if((Tmp_win)&&(HAS_CLICK_FOCUS(Tmp_win))&&(Tmp_win != Scr.Ungrabbed))
   {
     SetFocus(Tmp_win->w,Tmp_win,1);
-    if (Scr.go.ClickToFocusRaises ||
-	((Event.xany.window != Tmp_win->w)&&
-	 (Event.xbutton.subwindow != Tmp_win->w)&&
-	 (Event.xany.window != Tmp_win->Parent)&&
-	 (Event.xbutton.subwindow != Tmp_win->Parent)))
+    if (Scr.go.ClickToFocusRaises)
     {
       RaiseWindow(Tmp_win);
     }
--
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: Sun, 19 Sep 1999 16:19:34 +0200

> this code should be left as it is?

The additional checks for the frame were the former CLICKY_MODE patch.
It has been in the earliest fvwm version 2 release I have access to
(2.0.38):

  #ifdef CLICKY_MODE_1                                                            
            if((Event.xany.window != Tmp_win->w)&&                                
               (Event.xbutton.subwindow != Tmp_win->w)&&                          
               (Event.xany.window != Tmp_win->Parent)&&                           
               (Event.xbutton.subwindow != Tmp_win->Parent))                      
  #endif                         
              {                                                                   
                RaiseWindow(Tmp_win);                                             
              }                                                                   

In 2.0.46 I find a comment in the TO-DO file:

  - Add ClickToFocusDontRaise style (so clicks in window don't
    automatically raise the window when giving it focus).  Note - this
    behavior currently exists if you compile with CLICKY_MODE_1
    defined, I believe.

So it seems that it was intended that clicking on the title always
raises a window.  Perhaps the reson is that by default only clicks
on the title/border were intended to raise a CTF window, but not
clicks in the client window? Then the correct condition would be:

  if (Scr.go.ClickToFocusRaises)
  {
    RaiseWindow(Tmp_win);                                             
  }
  else if((Event.xany.window != Tmp_win->w)&&
          (Event.xbutton.subwindow != Tmp_win->w)&&
          (Event.xany.window != Tmp_win->Parent)&&
          (Event.xbutton.subwindow != Tmp_win->Parent))
  {
    RaiseWindow(Tmp_win);                                             
  }

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: Bob Woodside <[email-masked]>
Date: Sun, 19 Sep 1999 21:20:36 -0400

Dominik Vogt wrote:
> 
> The additional checks for the frame were the former CLICKY_MODE patch....
> 
> raises a window.

	I'll have to think about this one. On first thought, I'd vote for
changing the meaning of ClickToFocusDoesntRaise, and eliminate the extra
checks. The alternative would be yet another option, like
ClickToFocusReallyDoesntRaise.

	I wonder how many ClickToFocus users have mouse clicks on the
frame/titlebar bound to functions like Move-or-Raise or
Resize-or-Raise...and have had for years? My guess is, a lot, and
they're getting double raises every time they click the titlebar (and
have been for years). The automatic raise is not only superfluous, but
undesirable in this case, and has other undesirable side effects like
confusing RaiseLower when it's bound to a mouse click.

	I think it's much more useful - certainly more flexible - to allow the
ClickToFocus user to control when the window is raised by the functions
bound to particular mouse button clicks on specific window components.

	Hmmm...come to think of it, the decision to focus or not could be
controlled this way as well; who needs FVWM to make the decision, when
the user can control which clicks focus via his bindings
(ClickToFocusMeansDoItYourself?) Better not go there, this close to 2.4.
Nevertheles, it's an intriguing idea.

Cheers,
Bob

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 20 Sep 1999 11:45:13 +0200

> confusing RaiseLower when it's bound to a mouse click.

I guess it's a relic of fvwm 1.x that nobody thought of
changing.  I vote to remove it completely and look if
someone complains.

> Nevertheles, it's an intriguing idea.

This change would be a bit too disruptive to existing config
files. 

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]