Subject: do we need pan frames?

From: Dominik Vogt <[email-masked]>
Date: Fri, 19 Mar 1999 22:51:40 +0100

I wondered why we are using these weird pan frame windows
anyway. Couldn't we simply check if the pointer is within
a few pixels of the screen border (as defined by EdgeThickness
command). Instead of triggering the HandlePaging function
when the pointer enters a pan frame we could check this
for each MotionNotify event.

Any ideas why these pan frames were used in the first place?

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: Tim Phipps <[email-masked]>
Date: Mon, 22 Mar 1999 13:45:30 +0000

Dominik Vogt wrote:
> 
> Instead of triggering the HandlePaging function

fvwm doesn't ask for MotionNotify events at the moment so entering the
pan frame is the only way to tell that the pointer is at the edge of the
screen.  I don't know how much of a performance hit turning on motion
notify events would be, I don't notice any slowdown with xeyes but it
does generate a lot more network traffic.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 22 Mar 1999 15:08:21 +0100

> does generate a lot more network traffic.

The performance problem is even bigger. We had to call HandlePaging
not just for MotionNotify but for all events. Furthermore we couldn't
wait for events but had to do a check, pause for a few microseconds
and call Handle Paging. So I guess this solution isn't feasible.

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: "Eddy J. Gurney" <[email-masked]>
Date: Mon, 22 Mar 1999 11:32:30 -0500

On Mar 22 at 15:08, Dominik Vogt wrote:
,--
| On Mon, Mar 22, 1999 at 01:45:30PM +0000, Tim Phipps wrote:
| > Dominik Vogt wrote:
| > > 
| > > Instead of triggering the HandlePaging function
| > > when the pointer enters a pan frame we could check this
| > > for each MotionNotify event.
| > 
| > fvwm doesn't ask for MotionNotify events at the moment so entering the
| > pan frame is the only way to tell that the pointer is at the edge of the
| > screen.  I don't know how much of a performance hit turning on motion
| > notify events would be, I don't notice any slowdown with xeyes but it
| > does generate a lot more network traffic.
| 
| The performance problem is even bigger. We had to call HandlePaging
| not just for MotionNotify but for all events. Furthermore we couldn't
| wait for events but had to do a check, pause for a few microseconds
| and call Handle Paging. So I guess this solution isn't feasible.
`--
Can something be done about the pan frames always "being on top" then?
Right now, if you have a window whose border is in the "pan frame" area,
you can't access the functionality provided by that window's border --
instead, fvwm2 thinks you are clicking on the root window, because the
pan frame is apparently mapped to the root window. I complained about
this on the fvwm mailing list back in March of 1998.

Example: xterm window has bottom border at bottom of current desktop.
DesktopSize is 1x4. Move mouse to bottom of xterm window and click in
border. Instead of doing a "resize" (even though the cursor changes
to the resize cursor), the "Root" menu pops up (since that is what I
have bound to button 1 clicks in the root window).

Another (unrelated) request:

Can we change the window placement policy in move.c so that you can
resize a window that hasn't been mapped yet (while it is still in
rubberband mode) WITHOUT depending on the "EmulateMWM" flag? Currently,
if EmulateMWM is NOT set, you can use button 2 to resize a window 
while it is still "rubberbanded" (very nice feature). If EmulateMWM
is set, you have to usr Shift+button 1 to accomplish the same thing (yuck!)
Why not just make it button 2 OR shift + button 1 ALL the time? You can't
map this functionality to anything else via the config files anyway.

Is:

          if(((Event.xbutton.button == 2)&&(!Scr.gs.EmulateMWM))||
             ((Event.xbutton.button == 1)&&(Scr.gs.EmulateMWM)&&
              (Event.xbutton.state & ShiftMask)))
            {
              NeedToResizeToo = True;
              /* Fallthrough to button-release */
            }

Should be:

          if(((Event.xbutton.button == 2) ||
             ((Event.xbutton.button == 1)&&
              (Event.xbutton.state & ShiftMask)))
            {
              NeedToResizeToo = True;
              /* Fallthrough to button-release */
            }

Also, how about implementing a feature from (v)twm that while a 
window is in the "rubberband" state (before it has been mapped, you
are deciding where to place it), you can click button 3, and it 
places the window and automatically resizes it vertically to the
bottom of the screen. Very useful when opening an xterm; you just
have to position the upper left corner, tap button 3 and you have
a nice (tall) xterm.

In summary, it would be nice if during window placement (rubberband
mode), the following actions worked:

  Button 1: Place and map window (already in place)
  Shift+Button 1: Lock window location, mouse motion then resizes the 
                  rubberband frame (already in place if EmualateMWM set)
  Button 2: Lock window location, mouse motion then resizes the rubberband
            frame (already in place if EmualteMWM is NOT set)
  Button 3: Place top left corner of window, automatically resize vertically 
            so that bottom of window is positioned at bottom of screen.

Button 3 functionality could be added with functionality something like this
in "AddWindow":

        int     new_width, new_height;

        new_width = tmp_win->frame_width;
        new_height = Scr.MyDisplayHeight - 2 - tmp_win->frame_y;
        ConstrainSize(tmp_win, &new_width, &new_height);
        SetupFrame(tmp_win,tmp_win->frame_x,tmp_win->frame_y,new_width,new_heigh
t,TRUE);

Lastly, is anyone working on a "WarpToTransient" feature? I hate the fact
that windows like "Find" require me to move the cursor into the window so
I can type in it...

Eddy

---

From: Tim Phipps <[email-masked]>
Date: Mon, 22 Mar 1999 17:04:21 +0000

> this on the fvwm mailing list back in March of 1998.

You can turn them off with EdgeThickness 0. I don't think there's much
point in having them if they're not at the top.  Since they are
InputOnly and therefore invisible you wouldn't know where to put the
pointer to get scrolling if they weren't guaranteed to be on the top.  

In the current CVS and when 2.3.0 gets released you will be able to turn
the pan frames on and off in functions, This means you can have the pan
frames off most of the time and have them come on during a Move with the
following:

AddToFunc PanMove I EdgeThickness 2
+ I Move
+ I EdgeThickness 0

Is this useful?

> map this functionality to anything else via the config files anyway.

This will probaly get fixed after the great style flag rewrite.  Fvwm
has run out of bits for style and several features are overloaded on top
of others.  It's going to happen honest!

> that windows like "Find" require me to move the cursor into the window so

This will be possible in 2.3.0.  FvwmEvent has been changed to pass the
windowId when triggering events, and the WindowId command has been
changed to take conditions like Next/Prev.  If you get FvwmEvent to call
a function on a map event you can have the following function:

AddToFunc MapEvent I WindowId $0 (Transient) WarpToWindow

You can even have certain windows deleted as soon as they pop up if you
know their name.

Cheers,
Tim.