Subject: Newmenus (the version that doesn't broke old MenuStyle)

From: German Jose Gomez Garcia <[email-masked]>
Date: Fri, 13 Nov 1998 00:56:59 +0100 (MET)

Well, I can code really fast :-)

<>-------------------------------------+-----------------------------------<>
   One O.S. to rule them all,          |  German Gomez Garcia
      One O.S. to find them.           |  [email-masked]
   One O.S. to bring them all          |
      and in the darkness bind them.   |  "Wur Qanar Wur Stilor Wur Kas"
<>-------------------------------------+-----------------------------------<>

---

From: Dan Espen <[email-masked]>
Date: Thu, 12 Nov 1998 23:34:08 -0500

> 	Well, I can code really fast :-)

I think I believe you.

I like this patch.  It seems like a logical extension.

Here are some opinions:

"changemenusytle"  should probably  accept  wildcards.   As  it is  it
accepts multiple file names, so wildcards would seem logical.

"destroymenusytle"   should take   the   same kind   of  arguments  as
"changemenustyle".

When you use the "NEXT" menustyle,  you get popups  but the docs don't
say so.

The Titles aren't centering in the menus correctly.

When you  use "next (solid  red)" that overrides the background color,
making me  wonder  why the command  has a  background color it doesn't
use.  I think I know why this is, but there is a problem there.

You've let a little of your native language creep in, which is OK with
me, but what does "etiqueta_final" mean?

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: German Jose Gomez Garcia <[email-masked]>
Date: Fri, 13 Nov 1998 12:26:11 +0100 (MET)

> I like this patch.  It seems like a logical extension.
	Thanks

> "destroymenusytle"   should take   the   same kind   of  arguments  as
	You are right, I'll add this tonight, I posted this although it 
isn't finished, becasue I want it in the CVS, I don't like to apply 
patches by hand every time I upgrade my CVS tree. That is the reason I 
would like to get a commit account in the CVS.

> When you use the "NEXT" menustyle,  you get popups  but the docs don't
	Docs aren't finished yet, think of it as an undocumented feature :)

> The Titles aren't centering in the menus correctly.
	Uhmm, I don't use titles, I'll look at it.

> use.  I think I know why this is, but there is a problem there.
	Yeah, you are right again, the question is, should I remove the
solid option? or should I extend the menustyle to always use MenuFace 
command?, I mean I think I could make a MWM FVWM or even WIN gradients and
pixmaps background face, in that case you expecify the style to choose 
between diferent popup and selector types, and Solid would be necesary.
I hope to receive more opinions on the subject, mainly because what looks 
nice for me may be look horrible for others...

> me, but what does "etiqueta_final" mean?

	In the begining (where no fvwm development were undergo, about a 
year ago) I started the patch as a just-for-me patch, so things like that
keep there until you notice it, jeje, sorry about it, etiquete_final are
the spanish words for "last_label", about the use of a goto I think it is
the cleanest way in that case.

---

From: [email-masked]
Date: Fri, 13 Nov 1998 12:47:57 +0100

I didn't look at the new version of the patch, so please
correct me if I'm saying something stupid.

Long term I'd like to change the MenuStyle syntax to a format
similar to Style (comma-separated list of named opptions a la
MenyStyle Foreground black, Background steelblue, mwm, animated).

Comments?

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.hpc.uh.edu/fvwm/>.
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: [email-masked]
Date: Fri, 13 Nov 1998 12:52:03 +0100

> I like this patch.  It seems like a logical extension.

So, if there is an agreement that this patch goes into CVS
we should do it as fast as possible. Will anybody do this
over the weekend.

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Fri, 13 Nov 1998 07:47:45 -0500

> we should do it as fast as possible. Will anybody do this

In its current state I would only recommend it on a branch.
(I think we are trying to get to a stable release level.)  Given
that the command syntax is in question, the docs aren't ready,
I'm not sure we are talking about a 2.2 feature.

I could be proven wrong.

---

From: [email-masked]
Date: Fri, 13 Nov 1998 14:03:10 +0100

> I'm not sure we are talking about a 2.2 feature.

Well, that is exactly the question. I assumed we want it in 2.2,
so putting it in the main trunk will help finding the bugs
and problems. If we don't want it in 2.2 a branch is the right
place. Personally I vote for taking it into 2.2. What do you
think?

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Fri, 13 Nov 1998 08:04:02 -0500

> MenyStyle Foreground black, Background steelblue, mwm, animated).

Sounds OK, if that could be done without breaking the current
MenuStyle parsing.

Note that the new syntax is:

SetMenuStyle default foreground background shade active font anim type

type is fvwm, mwm, win, and now "next".

"next" takes a list of args in parens similar to titlestyle/borderstyle
including "solid", "pixmap", "tiledpixmap", various gradients.

I never liked the "type" concept, which is a collection of behaviors,
like "autopopup" and minor variances in appearance.

As German seems to be aware, tying all the new appearance stuff to
"next" is a mistake.

I don't think we have to do anything to MenuStyle, but "SetMenuStyle"
should not attempt to mimick the old "MenuStyle".

---

From: Dan Espen <[email-masked]>
Date: Fri, 13 Nov 1998 08:31:02 -0500

> place. Personally I vote for taking it into 2.2. What do you

If you feel that way, I'm not going to object.

If you want to go that way, I suggest you recommend that German get
update access now.  (Patches will slow this down.)

I don't think we want to include this in a release until the command
syntax is stable, or we will be stuck with the syntax.

---

From: [email-masked]
Date: Fri, 13 Nov 1998 15:17:49 +0100

> If you feel that way, I'm not going to object.

Although some of you might think that I am making (the) decisions
this is history already. In fact fvwm is maintained by the
workers list. Period. I'm one of many (and I'm very happy with
that).
 
> update access now.  (Patches will slow this down.)

That's up to others (I mentioned that I'd not recommend anyone
or object to anyone). Personally I don't fear that German does
something wrong.
 
> syntax is stable, or we will be stuck with the syntax.

Good point. I'm in no particular hurry with the release,
so there should be enough time to define the syntax before (?)

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Fri, 13 Nov 1998 09:46:37 -0500

> workers list. Period. I'm one of many (and I'm very happy with

I didn't mean  what I said that  way.  I am on  the fence.   If anyone
wanted it in, I wouldn't object.  If anyone  has an opinion against, I
could be convinced.

> or object to anyone). Personally I don't fear that German does

I think  I'm beyond that too.   If I remember  right, I'm the only one
recommending for update access.  Thats not right  either.  (If you and
I keep this up long enough, someone has to jump in.)

> so there should be enough time to define the syntax before (?)

My primary hesitation, is,  I'm not convinced  this is  as easy  as it
seems.

Has anyone else tried these patches?  Any opinions about including this
in the next release?

---

From: Austin Donnelly <[email-masked]>
Date: Fri, 13 Nov 1998 15:00:09 +0000

> wanted it in, I wouldn't object.  If anyone  has an opinion against, I

I'd vote for keeping it out.  I think more attention should be paid to
stability.

Take what we have now, stabilise it, and make a proper release.  Then
do another couple of stable releases to fix the bugs that will crawl
out as a result of the initial release.

Only _then_ should new stuff go in.

Stability isn't glamorous, but it in a window manager it is absolutely
vital.

Austin

---

From: Tim Phipps <[email-masked]>
Date: Fri, 13 Nov 1998 15:13:32 +0000

> I'd vote for keeping it out.  I think more attention should be paid to
I'd vote for putting it in.  If it all goes pear shaped then we can
easily go back, that's what the V in CVS is for.  It's a chicken & egg
situation: if it isn't in the CVS tree then it won't get tested.

Cheers,
Tim.

---

From: Brad Giaccio <[email-masked]>
Date: Fri, 13 Nov 1998 10:41:20 -0500 (EST)

> situation: if it isn't in the CVS tree then it won't get tested.

Lets make that 2 votes for putting it in.  We had said we wanted it for
quite a while now so lets get it in and see what happens.  True it would
be nice if we can use MenuStyle the way it used to be.  But if we need to
break the command it shouldn't be too much of a problem.  Users who
upgrade are going to see that their menus are broken immediatelly even if
they aren't whatching the log.

---

From: Dan Espen <[email-masked]>
Date: Fri, 13 Nov 1998 10:58:59 -0500

> they aren't whatching the log.

The patch, as it now is, doesn't break existing config files.

Lets have some other testers actually install and test this before
we make a decision.

---

From: Michael C Tilstra <[email-masked]>
Date: Fri, 13 Nov 1998 10:11:13 -0600

> MenyStyle Foreground black, Background steelblue, mwm, animated).

I'd also have to vote for seeing this in. I got it back when it went into
2.0.46. I like the stuff that it lets you do with the menus.

Though I'm also going to agree with the above, that menu syntax needs
fixing.

just my opinions.

-- 
Mike Tilstra                                   Tadpol
[email-masked]  http://www.tc.umn.edu/~tils0007/
   Sanity is the playground for the unimaginative.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Brad Giaccio <[email-masked]>
Date: Fri, 13 Nov 1998 11:55:07 -0500 (EST)

> Lets have some other testers actually install and test this before

I would be glad to test.  I'll try anything twice.  But I seem to have
dropped the patch in the bit bucket.  And the archive is telling me
something about only being able to highlight html.  Jason????

Brad

---

From: Jason L Tibbitts III <[email-masked]>
Date: 13 Nov 1998 12:29:36 -0600

>>>>> "BG" == Brad Giaccio <[email-masked]> writes:

BG> I would be glad to test.  I'll try anything twice.  But I seem to have
BG> dropped the patch in the bit bucket.

http://www.hpc.uh.edu/fvwm/archive/9811/msg00515.html, grab the link for
the attachment underneath the message, gzip -d it and you have your diff.

BG> And the archive is telling me something about only being able to
BG> highlight html.  Jason????

I can't duplicate that, but I do have our new machine running (it's
fvwm.math.uh.edu, but it's not doing anything useful at the moment) so I'll
be working on properly dealing with the web pages over the weekend.

 - J<

---

From: Steve Robbins <[email-masked]>
Date: Fri, 13 Nov 1998 23:31:12 -0500 (EST)

> Has anyone else tried these patches?  Any opinions about including this

I haven't tried it.  My opinion is based solely on this comment from the

>>> would like to get a commit account in the CVS.

I worry about code produced with this attitude.

Further, there is no reason for applying patches by hand on every "cvs
update".  After the first implantation of automake, I spent a week
cleaning up old code.  I touched *nearly every file* in my local copy of
the sources, while others were busy committing things to the repository. 
I did very frequent updates to keep in synch with the sources, and had no
more than two or three trivial conflicts in all that! 

Nobody expects that the cvs sources are reliable or even that the sources
will compile.  I *do*, however, expect that developers take reasonable
steps to check in quality code.  Committing something because they "don't
like to apply patches by hand" after cvs update is not reasonable.  IMHO.

--
Steve Robbins                              <[email-masked]>

If I had a rocket launcher, some son of a bitch would die.

---

From: German Jose Gomez Garcia <[email-masked]>
Date: Sat, 14 Nov 1998 15:59:00 +0100 (MET)

> On Fri, 13 Nov 1998, Dan Espen wrote:
...
> I worry about code produced with this attitude.

	Sorry if you undertand it in that way, I meaned (?) that I want it in 
the CVS because if we don't put it there I would have to apply patches by 
hand, The reason I would like a commit account it that I think that post 
here a patch everyday so people could test it would be a bad attitude :), 
but if you think that way is better, no problem...
 
> Steve Robbins                              <[email-masked]>

	Uhmm, newmenus are reliable, and anyway, what do you think CVS 
was designed for?, Concurrent means more than one person at the same 
time, if Dominic is going to do all the work (I said it to you Dominic, 
you will regret your decission :), we wouldn't need a CVS server, with a 
ftp site it will be more than enough.

	Anyway if you think I would better keep my hands out of the CVS 
well, I'll post patches here, but I repeat, that is contrary to the idea 
of a CVS server.

PS: After rereading the email it seems to me that it may seem as if I 
were angry, and I'm not, I'm very happy with the new development scheme 
fvwm2 has go into, so don't misunderstand me please.

---

From: Steve Robbins <[email-masked]>
Date: Sat, 14 Nov 1998 13:27:04 -0500 (EST)

On Sat, 14 Nov 1998, German Jose Gomez Garcia wrote:

> hand,

This is not correct.

If you have changes in your copy of the repository, you can certainly
track other's changes to the repository without "reapplying the patches by
hand every time".  That's what cvs update is for. 

> time,

Precisely.  You can keep abreast with others commits while you work on
yours.  You don't need to commit "unfinished" code (your word) in order
to get it in there first. 

                              *****

Unfortunately, my last message was poorly worded, and doesn't actually
focus on what concerned me.  I'm having a hard time phrasing this
properly.  I am using the word "you" in a generic sense in what follows,
as it is not aimed at anyone in particular.

It's not that I think German (or anyone) is a particularly bad coder per
se.  I'm not at all opposed to further widening commit access to the
repository. 

However, it seems that the power and purpose of cvs is often not well
understood.  Its purpose is NOT to publish code as fast as you can, and
ask everyone to do your alpha testing for you.  It is not a place to dump
untested code.

It IS a way for multiple developers to work concurrently and
cooperatively.  Cooperation requires that we all respect one another.  We
should keep in mind that others' time is as precious to them as your time
is to you.  I should not make a change to the code without testing it, and
assume others will test it for me.  If it is important enough to me, I
will spend the time to test it.  I require that the other developers show
the same respect for me and my time.

I should not make a change and fail to document it.  This attitude assumes
that the few minutes of time it takes to make a ChangeLog entry is more
valuable than all the other users' and developers' time spent in tracking
down an obscure bug, perhaps many months in the future. 

I know that terms like "test", "unfinished", and the like are nebulous
(and inflammatory!) in the context of software development.  We could
spend a lot of time trying to define them, but I am not interested in that
discussion.  I think the group can come to informal concensus.  I am NOT,
certainly, trying to argue that one should sit on their changes until they
have been in production use for six months!  I fully expect bugs and
alpha-quality code in the CVS tree. 

But there has to be some minimum standards for putting changes back into
the public repository.  I think the community expects things like: useful
entries in the NEWS and ChangeLog files, updating the manpages when you
change the corresponding code, and that the configure and build process
still works.  Nobody is asking that perfection be achieved always (I have
forgotten stuff on my own list at times) but pefection is what we should
strive for. 

With daily changes to the repository, fvwm is certainly a moving target. 
If the sources were only published in a complete tarball, it would be very
frustrating to try to work on them.  One would indeed be obliged to keep
re-patching the code by hand. 

But this is not the case!  We are using CVS, which keeps a *history* of
the changes made.  This allows you to merge others' changes into your copy
of the code semiautomatically.  In practice, the merging is *very* good. 
You can track many many repository changes while you work on your copy of
the code before the merge algorithm starts breaking.  The main exception
to this rule, ironically, seems to be with the ChangeLog files. 

The lesson here is that if you understand how cvs works, you should not
feel pressure from other's commits to publish your changes prematurely. 
That is how I interpreted German's statement.

Standing on the beach with a gun in my hand
staring at the sea, staring at the sand ...

---

From: German Jose Gomez Garcia <[email-masked]>
Date: Sat, 14 Nov 1998 19:58:52 +0100 (MET)

Sorry again, you are right, I'm being a bit childish, but 
understand me, I've waiting for a long time (a year or so) to see my code 
in the "official" fvwm2, and well, you know...,
	By other hand I would never put no tested code in the CVS, when I 
say testing I mean test it in the more configurations available, I know 
that although my .fvwm2rc is really large there are people with very 
"strange" config files, so I would like to know how my patch works there,
I repeat, I would never use you as "cobayas" (those little animals used in 
experiments, I can't remenber the english word).
	
	Well, thats all, and remember, things are going too fast... but 
not fast enough :)

---

From: Dan Espen <[email-masked]>
Date: Sat, 14 Nov 1998 15:18:55 -0500

...

Steve,

  Some of that was so well phrased, perhaps there is a place for it
in our docs/cvs.html file?

---

From: Dan Espen <[email-masked]>
Date: Sat, 14 Nov 1998 15:33:15 -0500

> 	Well, thats all, and remember, things are going too fast... but 

There's no hurry.

Here are some thoughts on MenuStyle:

How about extending the existing "MenuStyle" as follows:

MenuStyle "*" ForeGround <color>, BackGround <color>, Pixmap <pixmap>, ...

Leave the existing parsing alone, use the new parsing, only when the
first arg is a double quoted string.

The double quoted string would be used to wildcard match the menu name.

This uses the existing "Style" command as a model.

> German Gomez Garcia

---

From: German Jose Gomez Garcia <[email-masked]>
Date: Sun, 15 Nov 1998 01:10:51 +0100 (MET)

On Sat, 14 Nov 1998, Dan Espen wrote:

> Dan Espen                              
	Well, it could be done this way, but I think there are many 
posibilities, I would like to here from more people before changing it,
the reason because I defined the ChangeMenuStyle was to be able to change 
menu style at runtime without having to redefine the complete style (I 
know we could have something like UseStyle, but this should imply 
more work :). Maybe I start it again, this time using a "Style"ish 
approach, it would be nice if you could  specify everything about 
menu's look in a similar way you specify apps' style.

	More opinions on it are welcome...

---

From: Dan Espen <[email-masked]>
Date: Sun, 15 Nov 1998 10:17:15 -0500

> 	More opinions on it are welcome...

By all means, think before coding.

The    current "Style" command effectively    "merges"  styles into  a
composite.  It currently lacks a way to "destroy"  a style except that
every subsequent command   argument overrides the    one before.  (Old
style commands are never freed.)

I thought with 'MenuStyle "*"'  it might be a good  idea to merge  the
styles and move them to the end of the list, rather than build an ever
growing    linklist.   With   this scheme  you    might    not need  a
ChangeMenuStyle, but DestroyMenuStyle would still apply.

It might get a little tricky, and I know what you  are really after is
colorful menus, not configuration elegance, but I think its worthwhile
to spend some time on this.

---

From: German Jose Gomez Garcia <[email-masked]>
Date: Sun, 15 Nov 1998 16:57:37 +0100 (MET)

> ChangeMenuStyle, but DestroyMenuStyle would still apply.

	Sorry, but I don't understand you, what do you mean with "to 
merge the styles and move them to the end of the list", 
^^^^^
I think it can be code in an easier way if we simply store the match 
string ("*" in you example) and then search the list backward for the
first matching style whenever a menu is popped, to enable redefinition we
just replace a style if the matching string is the same. I don't know
if it is what you were saying, but I think it is easier than "merging"???

---

From: Dan Espen <[email-masked]>
Date: Sun, 15 Nov 1998 12:42:00 -0500

> > Dan Espen                                Phone: (732) 699-5570

Sorry, once you've tried to modify the Style logic in fvwm2, this might
make more sense.

If you issue:

Style "*" icon x, Forecolor color
Style "*" icontitle, notitle

fvwm2 stores both commands.

When  it wants to create a  window, it creates  an empty "style area".
It  then goes thru  all the styles that match  the window and for each
one that matches  the style, it MERGES  the attributes  into the style
area.

For the menustyle command, similar logic might be appropriate.

MenuStyle "*" Foreground white, Background gray, AutoPop
MenuStyle "System*" Background blue

---

From: German Jose Gomez Garcia <[email-masked]>
Date: Sun, 15 Nov 1998 19:23:25 +0100 (MET)

> MenuStyle "System*" Background blue

	But in this way you need more memory, don't you?, because usally you
have less styles than menus, I know that with apps is different, you may 
have many styles defined but no window really active, but with menus you 
usually would have less than ten styles, but you can have many menus. The 
question is that if we want to follow the "fvwm2 style" we need to do it 
as you suggest, although I think it is not such a big change, and as I 
see it, fvwm2 is good because it is small, efficient and very configurable,
not because it has a consistent configuration language (take a look at 
scwm :). 
	I would even say that other style commands should work in a 
similar way, that is with a linked list of styles, and windows or other 
things get a pointer to that style, in this way you could save some 
memory, and I think that assigning a pointer is faster than parsing a 
string, that could be very long. I know this is a drastic change, and 
many people wont' agree with me, but thinking in 2.3 (or even 2.5)...
	We could just postpone newmenus (I'm using them, but if somebody 
feels  not too good about it, no problemo :) until we decide this kind of 
things, well, but we are in a mailing list... what do other people think 
about it??, it seems than only Dan and me are interested in newmenus 
(although it is not so strange, who else should like that crappy patch? ;)

	That's all for now...

PS: Fear my next eamil, it would be even longer and even worse redacted XD

---

From: Michael C Tilstra <[email-masked]>
Date: Sun, 15 Nov 1998 13:16:05 -0600

> (although it is not so strange, who else should like that crappy patch? ;)

well, i like the new menus. The looks anyways, I'll agree though that I
think the config stuff needs work.  Though I've not had time to put any
real thought into it. (end of quarter coming up and I've too many final
projects)

---

From: Steve Robbins <[email-masked]>
Date: Sun, 15 Nov 1998 15:20:49 -0500 (EST)

On Sun, 15 Nov 1998, German Jose Gomez Garcia wrote:

> and as I 

Well, "small and efficient" is good.  But "consistent configuration" is
also good.  Is it really strictly one or the other?  Let's have both!

---

From: [email-masked]
Date: Mon, 16 Nov 1998 10:37:37 +0100

> > I'd vote for keeping it out.  I think more attention should be paid to

I'd like to have it in now. I tested it a few weeks ago (not very
thoroughly) and it worked ok. On the weekdend I got my menu titles
screwed up, but that mighy be caused of some other change I made.

I think we all agree that we want it in the long run. If we force
German to update his patch once and again it will slowly loose
stability while other code is being changed.

Furthermore there are some evil memory leaks in the MenuStyle
stuff and I won't bother to fix them until the patch is in.
Same with the syntax rewrite. Doesn't make sense to do this and
the redo it in the patch.

Bye

Dominik

---

From: [email-masked]
Date: Mon, 16 Nov 1998 11:23:58 +0100

> MenuStyle "*" ForeGround <color>, BackGround <color>, Pixmap <pixmap>, ...

Exactly what I'm thinking of.

> first arg is a double quoted string.

Why so complicated? MenyStyle doesn't work properly if not at least five
arguments are provided, so just count the words up to the first comma:

  >= 5 ==> old syntax
  <  5 ==> new syntax

Nothing strange done with quotes. Note that although the quotes are
always used in the examples for 'Style' they are not needed.

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Mon, 16 Nov 1998 09:10:58 -0500

Michael C Tilstra <[email-masked]> writes:
> German Jose Gomez Garcia writes:

I want to be clear.  I think I've already said it.  I like this patch.
Since fvwm can already paint pixmaps and gradients all over the place,
adding the same capability to  menus seems logical.  (Rob Nation might
not  have agreed, I seem  to recall some  specific comment about gaudy
menus, but  we've gone way beyond  that.)   I honestly don't  see much
bloat in this patch anyway.

The command parsing is a minor part of the patch.  I  know I have been
proposing progressively more and more complex syntaxes for the command
syntax.  Take my proposals for what they are, "proposals".

---

From: Tim Phipps <[email-masked]>
Date: Thu, 19 Nov 1998 13:30:54 +0000

Just tried this patch from today's CVS (19th Nov.).  I had a few fvwm
crashes when I type in the wrong SetMenuStyle command. e.g. SetMenuStyle
with no parameters.

I have another problem to do with menus that is not caused by this patch
but I've only noticed it while playing:

I tend to specify menus as

AddToMenu junk
+ "item1	$pixmap1%"	exec item1
+ "item2	%pixmap2%"	exec item2

I use TABs between the item name and the pixmap specifier.  If there are
two TABs I get an NL character on the menu item.  This happens when I
use the font "fixed".  It looks like the X call to draw the item name on
the menu is getting handed some trailing stuff or it's not handling
TABs.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 20 Nov 1998 13:54:10 +0100

> the menu is getting handed some trailing stuff or it's not handling

Both should be fixed, but please check the SetMenuStyle coredump
again if there are still problems.

Bye

Dominik