Subject: Don't touch menus.[ch] for now, please

From: Dominik Vogt <[email-masked]>
Date: Wed, 2 Jun 1999 12:42:35 -0600

Again I'm rewriting large parts of the menu code right now, so please
don't touch that code for a while (not that I think anybody will).
This time it's the drawing code.

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: Tim Phipps <[email-masked]>
Date: Wed, 02 Jun 1999 13:37:48 +0100

> This time it's the drawing code.

Can I suggest that you use the code in fvwm/colors.c for creating
gradient pixmaps and the code in libs/Graphics.c:SetWindowBackground()
for using the gradient pixmap as the menu background.  It would simplify
the menu drawing if all menus had a background pixmap maintained by the
server rather than have fvwm draw DGradients on every expose event.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 2 Jun 1999 15:01:36 -0600

> server rather than have fvwm draw DGradients on every expose event.

I was hoping that you would make these changes :) I'll see what
I can do. Where is the functionality for C/S gradients you coded
lataly?

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Wed, 02 Jun 1999 14:13:34 +0100

> I can do. Where is the functionality for C/S gradients you coded

It in fvwm/colors.c:CreateGradientPixmap() which returns a pixmap with
the gradient in it.  You can then stretch this to fit the menu with
CreateStretchPixmap() from libs/Graphics.c (have a look at
Graphics.c:SetWindowBacground()). 
fvwm/builtins.c:SetDefaultBackground() it where this is all called from.

Cheers,
Tim.

---

From: Brad Giaccio <[email-masked]>
Date: Wed, 2 Jun 1999 09:27:56 -0400

> fvwm/builtins.c:SetDefaultBackground() it where this is all called from.

Tim, since the stuff to strech the pixmaps in libs, would it be rigth to
put the stuff from colors.c there as well, maybe with a better filename.
That way modules if they wanted to could use the gradients as well.

Brad
 
-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
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, 2 Jun 1999 15:34:53 -0600

On Wed, Jun 02, 1999 at 02:13:34PM +0100, Tim Phipps wrote:
> the gradient in it.

I can't quite remember why the menu code saves the selected item before
hilighting it. Was there some performance bottleneck? Does anybody remember
this better than I do?

> You can then stretch this to fit the menu with

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Wed, 02 Jun 1999 14:41:17 +0100

> That way modules if they wanted to could use the gradients as well.

This is probably the right way to go but CreateGradientPixmap() uses
some things from the Scr structure (which the modules don't have) so it
would need rewriting, and it uses fvwm_msg().

Cheers,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Wed, 02 Jun 1999 15:07:06 +0100

> hilighting it. Was there some performance bottleneck? Does anybody remember

I think this was because D and BGradient menus didn't have a background
pixmap and unhilighting an item would have meant redrawing the whole
menu (very flickery).  If all menu styles had a background pixmap
unhiliting would just involve an XClearArea() followed by drawing the
mini-icon and text.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 2 Jun 1999 16:10:40 -0600

> unhiliting would just involve an XClearArea() followed by drawing the

Hmm, but why didn't B/D gradients have a background pixmap in the first
place? It's even unnecessary code to distinguish between the different
gradients.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 2 Jun 1999 16:13:21 -0600

> place? It's even unnecessary code to distinguish between the different

It's the size. A screen filling gradient pixmap may use several
megabytes.

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Wed, 02 Jun 1999 15:19:41 +0100

> place? It's even unnecessary code to distinguish between the different

I don't know but it might have been a concern over the space required by
the server for the background pixmaps. H gradients are very thin and
tiled vertically, V gradients are very narrow and tiled horizontally. D
gradients would be the same size as the menu. I think for the sake of
code simplicity we should make all gradients use a pixmap and put a
warning in the man page to say that gradients other than V and H may
cause problems on servers with very little memory (e.g X-terminals).

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 2 Jun 1999 16:25:35 -0600

> cause problems on servers with very little memory (e.g X-terminals).

Well, if you have a 1280x964 screen size with 32 bit depth a single
screen-filling pixmap uses about 5MB. You won't get very far with this
approach (same with C/S gradients I assume).

Bye

Dominik ^_^