Subject: Re: bug list #2 - pager bugs

From: Dominik Vogt <[email-masked]>
Date: Sun, 7 May 2000 06:54:37 +0200

Mikhael,

I'd like to look through this old pager bug list you reported
and find out what to do with each of the items:

> 1) FvwmPager without parameters should default to * not 0.
 
Dominik Vogt wrote:

> Please hack this as an enhancement request into Jitterbug.

I just had a look at the code.  It *does not* default to
desk 0 but to the currently active desk number (but unlike
'*' the shown desk remains the same if you switch desks.
If we removed this functionality we would need a syntax
change.  I'm unwilling to do that for the sake of simplicity.

--

> 2) *FvwmPagerBalloonYOffset must be fixed in -1 for positive values.

I think that one was fixed afterwards, right?

--

> 3) 3d borders in the pager do not work without colorsets.
> 	[this is documented, but I think it is not difficult to fix]

Dominik Vogt wrote:

> I think that was a conscious decision.  Now that colour sets can 
> give you all the looks you want there is no reason to further
> enhance the old syntax.  I won't spend a single minute in
> reimplementing features that are available via colour sets.
> Tim Phipps wrote:

> Possibly not difficult but would require a color lookup from the server
> and would probably leak colors. Bite the bullet and use colorsets.

I suggest to leave it this way.

--

> 4) In a small pager, windows fully in the page can cross the border,
>    because the minimal size of mini window is at least 3x3 (default).
> 	[Tim, can something be done about this?]
 
Tim Phipps wrote:

> Yes it could be fixed but I don't have the time. The place to fix it is
> in the tests on the variable MinSize.  There are 7 places to fix.

Put on to-do list.

--

> 5) The pager should not set input field to false. Why should it be
>    special? One can set NeverFocus if he likes the old behaviour.

Dominik Vogt wrote:

> I don't understand where the problem is.  In X, windows that
> don't take keyboard input should set the InputHint to False.

I'd not make any change unless pager starts taking keyboard input.

--

> 6) ESC does not work for move in a pager. At least, pressing on the
>    first or third mouse buttons should cancel moving (like in Move).

Enhancement request (post 2.4).

--

> 7) Moving a mini window out of the pager has several serious problems:
> 
>    * Esc for canceling a move works unexpected (see also (6)).

Dominik Vogt wrote:

> Can't be fixed.  You can't cancel moves in the pager because
> fvwm can't know where the pager started to move the window.

No fix (hack into Jitterbug).

--

8)

>    * Drag xterm (tested with XFree-3.3.6 xterm) outside the pager,
>    this has an effect of scrolling in xterm to the very top while moving.

Dominik Vogt wrote:

> Shrug.  Why do you think that it's fvwm's fault?  It seems that xterm
> doesn't handle some events right when it doesn't have the keyboard
> focus.  xev shows that the difference between a normal and a move
> from the pager is that xterm doesn't have the focus in the latter
> case.  It seems to handle one of the events it gets in this state
> incorrectly.  I don't know which, but probably either KeymapNotify
> or ConfigureNotify.

xterm bug.

--

9)

>    * Seems like always opaque move is used regardless of OpaqueMoveSize.
> 
>    * Sometimes the pager enters the interesting mode (I can't reproduce
>    this consistently, but I reproduced this 4 times today).
>    When a window is dragged from the opaque move can become something
>    visually similar to outline move. Restart helps to stop this mode.
> 
>    * When not in the mode above, i.e. opaque move is used, sometimes
>    weird things happen, FvwmConsole (and sometimes others too) when moved
>    from outside the pager allocate a lot of memory or quit without core.

Dominik Vogt wrote:

> All three se same problem.  Because of a bug in the move logic windows
> were sent ConfigureNotify events with random width and height (because
> some internal variables were uninitialised).  Fixed.

Fixed.

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

Summary:
--------

Fixed:
 2, 9

Do nothing about:
 1, 3, 5 (not a bug), 8 (xterm bug)

Put on to-do list:
 4

Enhancement requests (hack into Jitterbug):
 6

Document in Jitterbug/FAQ/...:
 7

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

We need to reach an agreement on these items asap so that I can
finalise the to-do list.

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: Mikhael Goikhman <[email-masked]>
Date: Sun, 7 May 2000 16:34:40 +0300

> change.  I'm unwilling to do that for the sake of simplicity.

No problem, it was more a suggestion than a bug report.

> I think that one was fixed afterwards, right?

Yes and no. The original suggestion was to handle BalloonYOffset as offset
from window borders, currenty it is handled as gap height. I have a
trivial patch (adding -1 and +1 in two places), which does this. I.e. if
you specify offset 1 or -1 there is no gap.

I can apply it if you agree. Otherwise we leave this as it is.

> I suggest to leave it this way.

OK.

> > in the tests on the variable MinSize.  There are 7 places to fix.

I am not sure when, but seems like Tim fixed this.
This one is fixed.

> I'd not make any change unless pager starts taking keyboard input.

OK.

> Enhancement request (post 2.4).

No. This one was autofixed after fixing (9).

Summary:
--------

Fixed:
 2 (or apply a patch reducing a gap), 4, 8, 9

Do nothing about:
 1, 3, 5 (not a bug)

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 8 May 2000 08:30:45 +0200

> I can apply it if you agree. Otherwise we leave this as it is.

I don't know if this works.  There was something about a
race condition when you move directly from the mini window
into the balloon window without moving over another window.
I'm not against applying it, but double check if the race
condition shows up (the balloon window will start to flicker).

> No. This one was autofixed after fixing (9).

Well, then consider it a workaround.

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-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]