Subject: re: fix for 2.5.4 xview

From: Elliot Sowadsky <[email-masked]>
Date: Mon, 11 Nov 2002 13:20:19 -0800 (PST)

.fvwm2rc is listed at end.

Secondary selections are selections w/ the mouse made while a Paste or
Delete key is held down.  During this time (key held down), a mouse click
should not cause a change in focus.  2.5.3 and prior didnt not cause change
in focus. 2.5.4 does.

> Bring up 2 xview (eg textedit) windows (1 and 2).
> Type some text in window 2.
> Click into window 1.
> Hold down Paste (L8) or Delete (L10)
  Select via mouse some text from window 2.
> Release Paste key,
> Selected text will get copied to window 1..
> Window 1 should keep focus (which 2.5.3 does).
> In 2.5.4, window 2 gets focus upon mouse click .

You can try this on any set of windows, even xterm.
The xterms won't do the copying that xview does, but you can watch the
window focusing.
Notice which window gets the active colors w/ each step.
Compare 2.5.3 w/ 2.5.4.

ie.
Start 2 xterms
Click into one xterm.
Hold down your L8 equivalent
WHile holding down L8 equivalent, left click mouse in other wondow.
2.5.3 will not do focus change (note titlebar colors).
2.5.4 will     do focus change on mpuse click..

--------------------------------------------------
focus.c

<<
change:	if (!FP_IS_LENIENT(FW_FOCUS_POLICY(fw)) && !focus_does_accept_input_focus(fw) &&  sf != NULL && sf->Desk == Scr.CurrentDesk)

to:	if (!FP_IS_LENIENT(FW_FOCUS_POLICY(fw)) && !focus_does_accept_input_focus(fw) && (sf == NULL || sf->Desk == Scr.CurrentDesk))

This isnt the 1st patch i sent for the xview focus problem.
That was too crude. This was the more refined one i sent.

--------------------------------------------------
<<
4) "... the icons in to left corner upon Restart is back.  Once
   opened tho, icons obey iconbox upon iconifying."

Only xview icons and all xview icons have this behavior.
It has to be a Restart without arguements.

--------------------------------------------------

I'm running solaris 2.5.1.
I start by running xinit.

# .xinitrc - OpenWindows startup script.
dis=`hostname`
DISPLAY=$dis":0"
export DISPLAY

--------------------------------------------------

my .xinitrc...

if [ -f $HOME/.Xdefaults ]; then
    xrdb $HOME/.Xdefaults &		# Load Users X11 resource database
else
    xrdb $OPENWINHOME/lib/Xdefaults &	# Load Default X11 resource database
fi
$OPENWINHOME/lib/openwin-sys &		# OpenWindows system initialization
xset s 7200  # screenblank delay
xhost + > /dev/null
exec fvwm2

--------------------------------------------------

my reduced fvwm2rc...

ImagePath          /home/elliot/bin/pixmaps

Style * ClickToFocus

AddToFunc StartFunction
+	I Exec xsetroot -solid #b15a27
+	I Module FvwmPager 0 0
+	I Module FvwmEvent

AddToFunc InitFunction
+	I	exec exec bin/start mailtool winmenu console
+	I	exec exec /usr/openwin/bin/cm

AddToFunc Clk-Dclk-HldMv
+	C $0
+	D $1
+	H $2
+	M $2

AddToFunc Clk-Hld-Mv
+	C $0
+	H $1
+	M $2

AddToFunc Op_Raise
+	I $0
+	I Raise

ExecUseShell /usr/bin/csh

AddToMenu Applications Applications Title
+	"$$ left"	Exec exec csh -f bin/xep left
+	"$$ right"	Exec exec csh -f bin/xep right
+	textk		Exec exec csh -f bin/xep textk

AddToMenu Quit-Verify "Really Quit Fvwm?" Title
+	"Yes, Really Quit" Quit
+	 Restart Restart
+	"Restart Fvwm253"    Restart /home/elliot_local/fvwma253/bin/fvwm
+	"Restart Fvwm254"    Restart /home/elliot_local/fvwm-2.5.4/bin/fvwm

AddToMenu Utilities Utilities Title
+	"Exit Fvwm" Popup Quit-Verify

AddToMenu WindowOps WindowOps Title

AddToMenu Ops "Root Operations" Title

AddToMenu "WindowOps2" "Move"  Clk-Dclk-HldMv Raise RaiseLower "Op_Raise Move"

AddToFunc window_ops_func 
+	C PopUp WindowOps2
+	M PopUp WindowOps2

Mouse 1         R	N       Clk-Hld-Mv Nop "Menu Applications" Nop
Mouse 2		R	N       Popup Utilities
Mouse 2		R	C	Popup WindowOps
--
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: Wed, 13 Nov 2002 12:43:59 +0100

On Mon, Nov 11, 2002 at 01:20:19PM -0800, Elliot Sowadsky wrote:
> Delete key is held down.

I see.  Whatever this cut/paste action is supposed to do, it does
absulutely nothing for me.

> During this time (key held down), a mouse click should not cause
> a change in focus.  2.5.3 and prior didnt not cause change in
> focus. 2.5.4 does.

Finally, I think I understand what your problem is.  How am I
supposed to know that you have configured your paste key as a
*modifier* key?  The behaviour you describe is 100% correct, exect
for modifier key.  I can take care of this.

[snip]

With that patch:

   If the window that is supposed to receive focus is an xview
   window.

AND

   No window has the focus yet.

THEN

  The window will not get focused.

That is just plain wrong.  You will be unable to focus any
xview window unless you focus another findow first.  In order to
fix a problem, I have to see it first.

Sigh!  You cut out all the relevant parts from the config.  With
the one you sent, icons are *supposed* to appear in the top left
corner.

[snip]

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Wed, 13 Nov 2002 07:32:32 -0500

> the one you sent, icons are *supposed* to appear in the top left

A few days ago, I tried to duplicate the textedit icon restart
problem.  I couldn't get the icon to go to the upper left corner,
but on a restart, fvwm put the textedit icon into the area of the
screen that I use as an iconbox, and then put another icon right
on top of it.

Your recent icon placement patch fixed that.

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 13 Nov 2002 13:47:33 +0100

> screen that I use as an iconbox, and then put another icon right

It was a really weird problem.  Textedit windows have a leading
space in their window name:

  " Text Editor ..."

When you restart fvwm with "Restart", this is saved as

  "[WM_NAME]  Text Editor ..."

in the session restart file.  When it is read back, the leading
space is stripped from the name.  Hence, fvwm does not find the
window in the restart file, can not read the old icon position and
kicks off the normal icon placement code.  I fixed the leading
space problem, but fvwm still trusts the window title blindly when
parsing the session restart file.  I guess that can be exploited
to cause a lot of funny problems.

And a second problem was that when a window provided its own icon
window, it was just dumped at 0 0 upon a restart and not moved to
the position that was stored in the window structure.

> Your recent icon placement patch fixed that.

I hope so.

Bye

Dominik ^_^  ^_^