Subject: Off by 1 in FvwmPager

From: Dan Espen <[email-masked]>
Date: Sun, 11 Feb 2001 18:16:29 -0500

Using this:

DestroyModuleConfig FvwmPagerSubPanel: *
*FvwmPagerSubPanel: Rows 5
*FvwmPagerSubPanel: Columns 1
Module FvwmPager FvwmPagerSubPanel 1 5

Produces a 5 pixel area at the bottom of the pager
thats drawn on once, but not refreshed.

-- 
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: Dominik Vogt <[email-masked]>
Date: Mon, 12 Feb 2001 13:07:16 +0100

> thats drawn on once, but not refreshed.

I believe that's the same problem as with FvwmPager as a panel.
ConfigureNotify handling was broken (when a bunch of CNs arrived,
the pager used the first one and threw away all others instead of
using the last one).

That's already fixed.

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: Dan Espen <[email-masked]>
Date: Mon, 12 Feb 2001 07:20:43 -0500

> the pager used the first one and threw away all others instead of

No, I did that after the fix.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 12 Feb 2001 13:35:54 +0100

> No, I did that after the fix.

Then I don't know what the problem is.  I don't see this.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 12 Feb 2001 12:44:45 -0600

> thats drawn on once, but not refreshed.

This is one of the FvwmPager problems that bugs me a lot.
To reproduce, specify any Columns and try random start and end desks.
FvwmPager geometry of the window, as compared to geometries of pages
inside it, is incorect for almost any Rows/Columns/number-of-desks.
The geometry of the window is usually greater than the sum pages+labels.

Seems like this bug was always (at least in 2.0.x), but I am not sure.

If we already speak about incorrect pager pixelings (I didn't want to do
this before 2.4), I think that the latest Dominik's patch "cvs diff -D
08-Oct-2000 -D 09-Oct-2000 modules/FvwmPager/x_pager.c" was not correct.
With it windows enterily on left pages occupy the separator (1 pixel),
which belong to the next page. I think the previous positions of mini
windows inside pages are very good. I guess the problem was not positions
of mini windows inside pages, but the positions of pages inside the pager
window. I would disable this patch and implement the real fix for the
pager geometries.

This is an old problem not trivial to fix correctly, so we may postpone it.
There are a lot of cases for desk numbers/page numbers/separators/labels.
I am not a volunteer to do the mentioned geometry fix before 2.4, but if
someone feels like it, I will test as many cases as I can.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Mon, 12 Feb 2001 07:57:46 -0500

> Then I don't know what the problem is.  I don't see this.

OK, I'll take a look.  BTW, it looks like this:

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 13 Feb 2001 18:01:02 +0100

> OK, I'll take a look.  BTW, it looks like this:

BTW, you attached only the config lines ;-)

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Tue, 13 Feb 2001 13:23:56 -0500

> BTW, you attached only the config lines ;-)

Sorry, mixed up pager and pager.gif.
I'll try again.

I see that the pager sets size hints for its increments.
In this case like this:

Program supplied x resize increment: 2
Program supplied y resize increment: 10

The geometry seems to be 40x31 which should be 80x310,
but the actual dimension is 81x394.

The subwindows seem to be:

81x77 (Desk including title)
81x62 (Just the desk)

The width seems to be one too high?

The heights don't seem to add up.  77x5=385.

Does the  Pager try to   enforce its overall  size so  that the  desks
divide evenly into the size?  I don't see it doing anything that looks
like it expects a remainder after the divide.

I spent some time trying to fix this.  I see all the numbers that don't
add up, but I wasn't sure which approach to take, trying to account for
the remainders, or trying to enforce the overall size.

I think to reproduce this you would need to use the same font I do.
The font effects the size.  Heres the latest config I used:

DestroyModuleConfig FvwmPagerSubPanel: *
*FvwmPagerSubPanel: Rows 5
*FvwmPagerSubPanel: Columns 1
*FvwmPagerSubPanel: Font 9x15bold
*FvwmPagerSubPanel: SmallFont 5x8bold
Module FvwmPager FvwmPagerSubPanel 1 5

and the image:

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 14 Feb 2001 13:23:57 +0100

On Tue, Feb 13, 2001 at 01:23:56PM -0500, Dan Espen wrote:
> divide evenly into the size?

Yes, but the calculations are a mystery to me.

> I don't see it doing anything that looks like it expects a
> remainder after the divide.
> 

Neither.  The bug must be where the remainders show up in the first
place.  I'd like to help, but for me your config works perfectly.

> *FvwmPagerSubPanel: Columns 1

Hm, for me this generates a pager that has 5 columns and 1 row.
Something in the calculations seems to be screwed up seriously.

> Module FvwmPager FvwmPagerSubPanel 1 5

If the font is involved, the error may be in the font height or
title height calculations.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 15 Feb 2001 16:25:03 +0100

> Seems like this bug was always (at least in 2.0.x), but I am not sure.

I never saw this, but then I never use desk titles either.

> window. I would disable this patch and implement the real fix for the

No, you are totally wrong ;)  I made these patches to have
consistent placement of the mini windows.  It's absolutely
intended that the miniwindows occupy the separator.  The
separators can not be ignored for sizing the windows because they
would distort windows that overlap page boundaries.  The current
logic evenly divides the space occupied by the separators between
both pages.

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: Thu, 15 Feb 2001 21:35:47 +0100

> Module FvwmPager FvwmPagerSubPanel 1 5

I could fix these problems after I was able to reproduce the
problem.  Several calculations in Reconfigure() and
initialize_pager() were more or less screwed up.  However, I don't
get any pager desk labels whith multibyte support enabled.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Thu, 15 Feb 2001 16:25:07 -0500

Dominik Vogt <[email-masked]> writes:
> initialize_pager() were more or less screwed up.

I'm curious about what you had to do to reproduce the problem.

With this fix, theres still  a little area at the  bottom of the pager
that seems to be outside of any desk but at least its not transparent.
I did a mod where I took the remainder from the goemetry divided by the
rows and applied it to the desks, but it threw off the highlighting.

Right  now, I'm   not  seeing the    problem  I had with   FvwmIconMan
redisplaying itself over and over.   This is the  first test I've done
at work.  Maybe my slow home connection just can't keep up.

I notice that when I click on the  up arrow, I first  see the pager at
+0+0 (first empty screen area) and then it appears where it should be.

I guess thats typical for everything the FvwmButtons tries to control.

The next issue I  have is the delay.  I  tried a few different delays,
and they don't seem to be right.  The attached config  uses a delay of
5000  ms and 5 steps.  It  looks like it waits   the entire 25 seconds
before it does anything.  Maybe it needs to XSync?

---

From: Dan Espen <[email-masked]>
Date: Thu, 15 Feb 2001 17:43:38 -0500

> rows and applied it to the desks, but it threw off the highlighting.

Sorry, please ignore this part, my recompile never finished.

> at work.  Maybe my slow home connection just can't keep up.

I did get this problem again.

> before it does anything.  Maybe it needs to XSync?

I think this is real, but its with the code before the latest change.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 16 Feb 2001 02:10:33 +0100

> I think this is real, but its with the code before the latest change.

Well I guess the man page schould mention that specifying a delay
does not really make sense without the "smooth" option.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 16 Feb 2001 02:08:55 +0100

> I'm curious about what you had to do to reproduce the problem.

This happened only when Desk titles were displayed.  Since the
multibyte code was broken, I didn't get desk titles until I
recompiled without mb support.

> at work.  Maybe my slow home connection just can't keep up.

With the config you posted my FvwmIconMan shows the same symptoms,
but I did not make any progress yet.  The only thing I found out
is that FvwmIconMan gets ConfigureNotify events of the same size
it already has again and again, but oviously the size is icorrect
because it ovvupies the padding area of the button.

> I guess thats typical for everything the FvwmButtons tries to control.

Yes.  To prvent the flashing you can give FvwmPager an off screen
geometry, e.g. -30000-30000.

> before it does anything.  Maybe it needs to XSync?

That depends on the "smooth" option of the panel.  With it, the
queue is flushed after each step, without it it is only flushed
once after all commands have been queued.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Thu, 15 Feb 2001 23:44:21 -0500

> does not really make sense without the "smooth" option.

I added the "smooth" option and increased the delay:

*FvwmButtons: (1x2, Panel(up, indicator, delay 10000, steps 5, smooth, position Root 46 -108p) FvwmPagerSubPanel "Module FvwmPager FvwmPagerSubPanel 1 5")

Now I don't see any delay.

Now that I've recompiled, the pager fixes work great.

The smooth option seems to be misnamed in the case of the Pager.
I think the man page should describe this as:

  The smooth option causes the panel  to  redraw  between
  the steps of the animation.  The sliding animation
  may be smoother this way, it depends on the application,
  and display speed.  The application may appear to grow
  instead of sliding out.  The animation may be slower.

Another thing to fix in the man page is that tip you gave me
about using negative geometries (which work great).  It is
in the man page but its too well hidden.

I'll change the man page unless you are already working on it.
I was the one to fix the English,
but I admit its not clear.  (It might be even clearer if
I test it a little too.)

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 16 Feb 2001 09:50:24 +0100

On Thu, Feb 15, 2001 at 11:44:21PM -0500, Dan Espen wrote:
> I was the one to fix the English, but I admit its not clear. 

Feel free to do any changes you deem appropriate.  I'm not really
able to explain complex problems well (I'm a mathmatician :) ).

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 17 Feb 2001 03:50:34 -0600

> logic evenly divides the space occupied by the separators between

Now, after you fixed the pager sizes, and the separator is between pages
not at the first pixel of the next page, your previous patch makes sense.

I have tested many pager configurations and they work correctly,
except that FvwmPager configuration option Geometry is ignored now.
I can reproduce this with any configuration, just define Geometry.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 17 Feb 2001 13:28:41 +0100

> I can reproduce this with any configuration, just define Geometry.

Ah, yes! I was over eager when cleaning up the code.  I did not
find a reason why the window_w/window_h variables could already be
set in initialize_pager(), so I deleted that code.  Will be fixed
in a moment.

Bye

Dominik ^_^  ^_^