Subject: Using vector-buttons/testbed.fvwmrc

From: Dan Espen <[email-masked]>
Date: Fri, 19 Jan 2001 20:02:29 -0500

Regarding fvwm-web vector-buttons/testbed.fvwmrc.

Mikhael, a while ago you did this:

1999-12-07  Mikhael Goikhman  <[email-masked]>
	* vector-buttons/testbed.fvwmrc:
	Added missing 'Read'; commented out 'Mouse' lines (these global
	binding changes are superfluous);

and I'm sure I used that after you changed it.
However, I just tried to use it again, and I have the same problem,
unless I bind something to the button, no button appears.

Help, what am I forgetting?

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214             E-mail: [email-masked]
Piscataway, NJ 08854                       Phone: (732) 699-5570
--
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: Mikhael Goikhman <[email-masked]>
Date: Sat, 20 Jan 2001 18:27:17 -0600

> Help, what am I forgetting?

-- features follow --

I don't think we are both forgetting something. It more seems like Dominik
changed the behaviour of when titlebar button should be shown.

If you noticed, there was one more change. You can't now get a window
without a title (title size x = 0), instead, titlebar buttons are shrunk.
You may compare old DecorDemo1.gif and DecorDemo4.gif, but before my
latest commit, because I did some improvements. I hope you like them.

-- bugs follow --

Another problem is that xv window jumps now after being shaded.
I can reproduce a jump also when pressing 'n' in any xv shaded window.
The effect in both cases is like Move keep -WINDOW_WIDTH.
Or even when pressing 'n' in unshaded xv window in this button_demo, but
the effect is different: Move w-2p w-2p.

There is also a weird visual effect when you reread the same or different
DecorDemoN.fvwmrc or another one when button_demo_style window is on the
screen shaded.

I suggest Dominik to take a look at vector-buttons/testbed.fvwmrc.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Sat, 20 Jan 2001 22:16:41 -0500

> changed the behaviour of when titlebar button should be shown.

Thanks, its hard to keep track.

> latest commit, because I did some improvements. I hope you like them.

I did notice.  I do like your changes. Windowshading is a good idea,
rather than trying to get the goemetry exactly right.  I added the
unshading step to the instructions.

I think it looks a little better with hidden handles, hope you agree.

> DecorDemoN.fvwmrc or another one when button_demo_style window is on the

I noticed that, but I was so intent on getting the buttons
done, I didn't realize something might be wrong.  It is weird isn't it.

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 21 Jan 2001 15:02:33 +0100

> I can reproduce a jump also when pressing 'n' in any xv shaded window.

I can make it jump by shading the window and pressing 'n'.  What
exactly is the second way you mention?  How can I reproduce it?

> The effect in both cases is like Move keep -WINDOW_WIDTH.

Yes.

> the effect is different: Move w-2p w-2p.

What do I have to do?

> DecorDemoN.fvwmrc or another one when button_demo_style window is on the

With xv again or also with other windows?

> I suggest Dominik to take a look at vector-buttons/testbed.fvwmrc.

I will.  And before anybody else reports it: there are two more
problems with xv.  One is that xv windows jump to 0 0 during a
recapture or restart.  I did my best to get them back to the
original position, but sometimes that does not work.  That's
because xv moves its window to this place on the screen when
reparented to the root window (ddd is another application that
tries to be its own window manager) :(  There was another problem
that caused xv windows to slowly travel over the screen.  It was
triggered simply by using some xv function, but I can't remember
why.  This can't be fixed other than by inventing an xv specific
new style because xv calculates its geometry in move/resize
requests differently than virtually all other applications.

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: Sun, 21 Jan 2001 15:33:38 +0100

> > I suggest Dominik to take a look at vector-buttons/testbed.fvwmrc.

Well, just as I suspected, this is an xv bug.  When you press 'n'
on a shaded xv window, xv *explicitly asks* for this new, wrong
position.  I tested this with four other wms.  Two suffer from
the same problem and two others simply do not give focus to shaded
windows.

The only thing I can think of is forbidding applications to move
their windows while they are shaded (like with maximized windows).

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 21 Jan 2001 12:31:01 -0600

> > the effect is different: Move w-2p w-2p.

Execute instructions in testbed.fvwmrc, unshade demo window and press 'n'.
Interesting, when you do RecaptureWindow, it does not move -2 -2 anymore.

> With xv again or also with other windows?

With any window having button_demo_style name. Try to reread decors when
there is button_demo_style window on the screen, shaded and not shaded.
It is ok by me if you decide this is not worth fixing, but I want to let
you know that the problem exists.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 22 Jan 2001 11:20:29 +0100

> Interesting, when you do RecaptureWindow, it does not move -2 -2 anymore.

Actually, I debugged through xv a bit and noticed at least two
bugs.  The first is that xv calculates its position in the frame
window when it is reparented but never recalculates it.  This
leads to wrong positions if the height of the title changes or
bottom titles are turned on or off or if the border width changes.
Second, xv assumes that it will always have a border width of two
(I mean the border of the client window, not the wm border).  If
it detects that the border width is zero (as it will be after the
window is captured) it tries to set the borderwidth to 2 again
each time it is moved or resized.  Of course fvwm does not allow
this, but xv continues to make its calculations with a borderwidth
of 2 pixels.  This is most likely the cause for the displacement
you see.  There is even a hard coded title height in xv, but that
code is not used for me.

> you know that the problem exists.

So what *is* the weird visual effect you speak of?  Do you mean
the fact that a changed decor is only applied partially without a
recapture or when the corresponding style is changed?

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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: Mikhael Goikhman <[email-masked]>
Date: Mon, 22 Jan 2001 11:17:37 -0600

> recapture or when the corresponding style is changed?

Yes, the recreated decor is applied partially (I would say incorrectly).
Button styles are taken from default; title Height stays as it was
(30), but it seems that in calculations of the frame, the default title
Height is assumed (20 in my case). So the size of the window is now 10
pixels less by Y, and the client window is resized(!).

When window is shaded before rereading its decor this is a bit different,
frame size is 40 (10+20+10), while title is 30, so the bottom border
is overdrawn by title. In this case the client window is not resized.

If you don't trust xv, you may do 'xterm -name button_demo_style'.
RecaptureWindows after "Read vb/DecorDemo1.fvwmrc" solves the problem,
except that non-shaded xterm now has 23 lines (in my case) instead of 24.
It is easier to see than to explain, just test 2 cases:

  Read vb/testbed.fvwmrc
  Read vb/DecorDemo1.fvwmrc
  button_demo
  Exec xterm -name button_demo_style
  # shade xterm/xv for the first test, leave unshaded for the second
  Read vb/DecorDemo1.fvwmrc
  # stty -a | grep rows

As I already said, it is ok by me if you decide this is not worth fixing.

Regards,
Mikhael.