Subject: I18N_MB patch for fvwm 2.2

From: Makoto MATSUSHITA (まつしたまこと) <[email-masked]>
Date: Thu, 22 Apr 1999 19:50:11 +0900

I've reorganized an X i18n-patch (previously, for fvwm 2.0.46) to fvwm
2.2. It adds (partially) multibyte support to fvwm. Maybe have some
dirty codes, but it works 5 years before (yes, FIVE years before. This
patch was born when the fvwm version was 1.20).

Interesting? Try:

ftp://ftp.ics.es.osaka-u.ac.jp/pub/CFAN/fvwm-users-jp/I18N_MB/fvwm-2.2-I18N_MB-1999042001.patch

I've not sent to this list because it is about 162KB!. Instructions
are shown in the head of this patch.

If somebody wanna put into fvwm repository, do it in anyway. Since I
have very few time to keep this patch up-to-date, I do not want to get
the access rights to commit fvwm CVS repository.

***

Notes on users of FreeBSD: Fvwm in FreeBSD ports is quite OLD,
however, today (a few minites before:) the updated version (fvwm 2.2)
is send-pr'ed. Please wait until the greatest FreeBSD committers do
their jobs. If you don't wait, check PR database number 'ports/11277',
or fetch a package 'fvwm-2.2.tgz' for FreeBSD 3.x-STABLE/4.0-CURRENT
(check the same directory shown above).

-- -
Makoto `MAR' MATSUSHITA

I'll bet this patch will be silently ignored, 'cause there are no
needs of this patch in 'the World (aka the community of fvwm-workers,
living mostly in europe and north america'; it is already discussed
here in early February 1999.
--
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, 22 Apr 1999 13:38:42 +0200

> ftp://ftp.ics.es.osaka-u.ac.jp/pub/CFAN/fvwm-users-jp/I18N_MB/fvwm-2.2-I18N_MB-1999042001.patch

Yes, very interesting. It's almost embarassing to say that the current
2.3.x version is already very different from 2.2 so I have little hope
of applying it without lots of problems.

> the access rights to commit fvwm CVS repository.

Are you sure about this? Applying a patch is one thing, but keeping
it up to date when you don't even have a system than can use the patch
is a different story.

> here in early February 1999.

Nonsense. I'd love to have full internationalisation support for
fvwm, but it's *so much* work. I still have a real job and simply
can't spend anywhere enough time to make such changes. The other
developers have the same problem. Please do not understand this
as criticism but try to understand what our problem is:

We are making a lot of changes now in the development tree. None of
the developers fully undestands what your patch does and how it does it.
The chances of applying it without conflicts are close to zero. When
someone comes saying: "Hey, I have a patch that makes large changes
to fvwm, but sorry, I've got no time helping you to apply it," we
have a problem. I'm sure you put a lot of work into the update. But if
you had asked at the list we would have immediately asked you to do the
patch for the development version. Now we have a patch that most
likely won't apply, a frustrated committer (i.e. you) and a bad
conscience here. That doesn't help us much.

Well, I'll try to apply it, but without a way to test the patch I
can not do much. As you correctly noted: the fvwm developers live
mostly in Europe and America and do not have the slightest idea how
this works or how to test this.

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: [email-masked] (Paul D. Smith)
Date: 22 Apr 1999 09:48:34 -0400

Can you give some ideas as to what kinds of changes are included in this
patch?  What needs to be modified in fvwm2 to support i18n?  There're
obvious things like output strings in different locales, but fvwm
doesn't do much printing of anything except debugging messages; there
must be more to it than that.

Thx.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
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: Matthias Clasen <[email-masked]>
Date: Thu, 22 Apr 1999 16:04:21 +0200

>From a quick glance at the patch, it seems to be mostly concerned with
getting the various strings from hints using multibyte methods,
handing them to modules as mb strings, drawing icon and window
titles and menu entries as mb strings. All this is protected 
by #ifdef I18N_MB. 

The patch seems to be fairly large partly because it is not only
against fvwm, but also against numerous modules.

Matthias

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
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: Makoto MATSUSHITA (まつしたまこと) <[email-masked]>
Date: Fri, 23 Apr 1999 01:12:50 +0900

clasen> From a quick glance at the patch, it seems to be mostly
clasen> concerned with getting the various strings from hints using
clasen> multibyte methods, handing them to modules as mb strings,
clasen> drawing icon and window titles and menu entries as mb
clasen> strings. All this is protected by #ifdef I18N_MB.

Almost yes. Thank you.

Some dirty hack (replace XTextWidth() by C macro) also exists,
however, most of changes are protected in #ifdef I18N_MB. 'I18N_MB' is 
defined if and only if you do './configure --enable-kanji', you can
compile patched fvwm without --enable-kanji and you'll get usual fvwm.

Some of you say '--enable-kanji' is not a good name; I think so too, but 
that's the way of Window Maker, so I follow it.

clasen> The patch seems to be fairly large partly because it is not
clasen> only against fvwm, but also against numerous modules.

I've also write a patch for modules which may *display* multibyte
character. Only patching fvwm is not enough :-)

-- -
Makoto `MAR' MATSUSHITA

---

From: Makoto MATSUSHITA (まつしたまこと) <[email-masked]>
Date: Fri, 23 Apr 1999 02:03:28 +0900

dominik.vogt> Yes, very interesting. It's almost embarassing to say
dominik.vogt> that the current 2.3.x version is already very different
dominik.vogt> from 2.2 so I have little hope of applying it without
dominik.vogt> lots of problems.

Converting a patch from 2.0.46 to 2.2 eats my weekend, but maybe 10 or 
20 hours (including test running and make a FreeBSD package).

The only thing I want to say in previous mail is that I don't have
enough time to commit this change (iff it is allowed), so if anybody
interested in this patch, do it without my approval. Sorry if you
misunderstand my message; it's my fault, I'm too nervous yesterday...

I'm also in doubt that this patch is maybe only for asian
people. However, other window managers, Window Maker and AfterStep, 
already have a code of multibyte support (Note that Window Maker also
does catalog file support by gettext library; maybe gettext is not a
good implementation (hehe, it's just a runtime string replacement),
but practical solution).

Fvwm forks does not consider obiously such a situation for many many
years. You say it's a hard work, however, you'll soon find that my
I18N_MB hack is ONLY a typical code conversion from *font* to *fontset*. 
Yes, of course more and more hacking for multibyte support is needed,
including error/infomation message handling. I hope I18N_MB patch will 
be the first step for it...

Applying I18N_MB patch to fvwm 2.3.1 needs some work, maybe. If much
of workers are interested in, I'll try to rearrange this patch against 
to 2.3.1 (or whatever latest beta version).

dominik.vogt> Well, I'll try to apply it, but without a way to test
dominik.vogt> the patch I can not do much. As you correctly noted: the
dominik.vogt> fvwm developers live mostly in Europe and America and do
dominik.vogt> not have the slightest idea how this works or how to
dominik.vogt> test this.

Hmm, does fvwm need multibyte support which is not debuggable for most
of workers? Should we really need a code of multibyte support such
does in AfterStep, twm (not R6/xc, but you can find R5/contrib), olwm,
olvwm, mlvwm, (your rival name here:), and Window Maker? Anyway,
what's multibyte handling ? Is it happy for us ?

We first do a decision about these issue, and applying this patch into
core fvwm code is the next issue, doesn't it?

-- -
Makoto `MAR' MATSUSHITA

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 22 Apr 1999 19:12:27 +0200

> core fvwm code is the next issue, doesn't it?

I'd start with applying the patch and then rework large parts.
Having #ifdef's in dozens of places is no solution. I hope we
can shift all multibyte code in a separate .c file and have no
ifdef's in the code anywhere else.

Bye

Dominik ^_^

---

From: Makoto MATSUSHITA (まつしたまこと) <[email-masked]>
Date: Fri, 23 Apr 1999 10:07:11 +0900

dominik.vogt> Having #ifdef's in dozens of places is no solution. I hope we
dominik.vogt> can shift all multibyte code in a separate .c file and have no
dominik.vogt> ifdef's in the code anywhere else.

Yet another patch of I18N_MB is already written which introduces *wrapper*
to some X functions. However, it lacks some error handling and memory
leaks which is done of my previous patch. If you want, fetch this:

<URL:http://www.on.cs.keio.ac.jp/~yasu/jp_fvwm.html/fvwm-2.2-I18N-mb.patch>

I have a plan to merge my patch and this patch into the one but...

-- -
Makoto `MAR' MATSUSHITA

---

From: Matthias Clasen <[email-masked]>
Date: Fri, 23 Apr 1999 19:18:27 +0200

> ifdef's in the code anywhere else.

I have spent some hours today with this patch... I have tried to
resolve the rejects in libs/ and fvwm/, ignoring modules/ for now.

The biggest part was builtins.rej, due to the fact that some menu
code went to menu.c. I do have a 2.3 binary built with -enable-kanji
which seems to work reasonably well (for my single-byte locale, don't
know how much that proves). I could produce a patch for libs/ and fvwm/
if you want, but I don't think that it should be put in CVS in its
current version. The patch contains *tons* of changes 

isspace(*p) --> isspace((unsigned char)*p)

If this is really needed, it should definitively be handled differently.  
Other than that, I wouldn't like to see hundreds of #ifdef I18N_MB
littered all over the code. We really should abstract font handling in
in one .c file. 

Matthias

---

From: Makoto MATSUSHITA (まつしたまこと) <[email-masked]>
Date: Sat, 24 Apr 1999 02:32:50 +0900

clasen> isspace(*p) --> isspace((unsigned char)*p)

I'm not sure about this changes, but I've heard that some system
(sorry I do not know) requires this change.

Maybe isspace() was implemented as a macro (not a function), and the
argument is used as an index of array, and maybe *p was treated as
'minus' value. Maybe the 7bit-character world does not need to fix
such a change ('cause MSB is always zero).

-- -
Makoto `MAR' MATSUSHITA

---

From: Steve Robbins <[email-masked]>
Date: Fri, 23 Apr 1999 13:36:27 -0400 (EDT)

> resolve the rejects in libs/ and fvwm/, ignoring modules/ for now.

Just a thought: rather than trying to apply a patch to fvwm-2.2 to current
sources, there is the alternative approach of 

	cvs checkout -r version-2.2 fvwm
	[apply patch]
	cvs update -A

Now resolve all the conflicts.  

I dunno which approach is easier, mind you.
 
> isspace(*p) --> isspace((unsigned char)*p)

Ick, no!  My POSIX book says isspace() takes an "int" argument.  Ditto for
all the other is*() functions from ctype.h.  

If any cast is necessary, it should be isspace((int)*p).

But is a cast necessary?  A sytstem with prototyped headers wouldn't need
a cast.  And in the absence of a prototype, don't C compilers promote
'char' arguments to 'int' anyway?

> littered all over the code. We really should abstract font handling in

Absolutely.

---

From: Matthias Clasen <[email-masked]>
Date: Fri, 23 Apr 1999 19:40:00 +0200

> such a change ('cause MSB is always zero).

The proper fix would be to use unsigned char throughout, I guess.

Matthias

---

From: Matthias Clasen <[email-masked]>
Date: Fri, 23 Apr 1999 20:30:12 +0200

> I dunno which approach is easier, mind you.

Nice idea, but since I have already done most of it manually...

> all the other is*() functions from ctype.h.  

Yes, but the standard says:

The header <ctype.h> declares several functions useful for testing and 
mapping characters.  In all cases the argument is an int, the value of
which shall be representable as an unsigned char or shall equal the value
of the macro EOF.  If the argument has any other value, the behaviour
is undefined.

I don't know if "representable as" means that you have to do the cast.

> If any cast is necessary, it should be isspace((int)*p).

Now that would be truly redundant, wouldn't it ?

> 'char' arguments to 'int' anyway?

Well, this could be the problem, no ? If I have a character with the high bit
set, it would be negative as a char, so would be promoted to a negative int
and thus not be "representable" as an unsigned char.

Matthias

---

From: [email-masked] (Paul D. Smith)
Date: 23 Apr 1999 14:31:47 -0400

%% Steve Robbins <[email-masked]> writes:

  >> isspace(*p) --> isspace((unsigned char)*p)

  sr> Ick, no!  My POSIX book says isspace() takes an "int" argument.
  sr> Ditto for all the other is*() functions from ctype.h.

Precisely.

  sr> But is a cast necessary?  A sytstem with prototyped headers wouldn't need
  sr> a cast.  And in the absence of a prototype, don't C compilers promote
  sr> 'char' arguments to 'int' anyway?

However, is*() functions are almost always implemented via macros, not
functions.  This means that no promotion is done.

I know that newer GCC's, for example, often complain about "char array
subscripts" when you use these without a cast because isspace() etc. are
really macros that resolve to array lookups with the argument as the
array subscript.

Nevertheless, I do _NOT_ recomment adding (int) casts all over the
place, just to shut up these warnings.  The compiler really ought to
handle this correctly.

Maybe the author of the patch can give the reason for applying the
(unsigned char) cast?

---

From: [email-masked] (Paul D. Smith)
Date: 23 Apr 1999 14:58:21 -0400

>> 'char' arguments to 'int' anyway?

  mc> Well, this could be the problem, no ? If I have a character with
  mc> the high bit set, it would be negative as a char, so would be
  mc> promoted to a negative int and thus not be "representable" as an
  mc> unsigned char.

Ouch... you're right.

Kind of a PITA, since most functions, even standard ones, take char*
arguments (for example), not unsigned char*.

Maybe we should create ISSPACE(), etc. macros that invoke isspace(),
etc. but cast the argument to unsigned char.

---

From: Dan Espen <[email-masked]>
Date: Fri, 23 Apr 1999 15:01:57 -0400

> and thus not be "representable" as an unsigned char.

Since the "isspace"  works without a cast,  outside  the I18N locales,
this must  have something  to do  with forcing double  byte characters
into 256 byte range?

The first time I saw this patch there were cases where I saw:

isspace(*p & 0xFF).

At the time, I favored dealing with it as a macro.

#ifdef I18N
#define ISSPACE(X) isspace(X & 0xFF)
#else
#define ISSPACE(X) isspace(X)
#endif

(Caution, untested code.)  The macro might accomodate a cast also.
It would seem to me that compilers on machines with signed characters
would have to build their isspace arrays accordingly.

--
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: Matthias Clasen <[email-masked]>
Date: Fri, 23 Apr 1999 21:29:15 +0200

> this must  have something  to do  with forcing double  byte characters

That wouldn't make any sense. You really can't use isspace and friends
on multibyte or wide characters, thats why the standard says the int
argument has to be representable as an unsigned char.

The standard mentions an additonal header wctype.h with "isw" analoga
of the "is" functions from ctype.h. These operate on wchar_t. Thus
i guess the correct way to do character classification on multibyte
strings is to first convert them to wide chars (using mbtowcs)
and then use iswspace and friends. Not that I think any of this is
needed for the uses of isspace in fvwm. We should just make sure
we parse the rc file in the "C" locale and then use 
isspace((unsigned char*)*p) or a macro for this.

Matthias

---

From: [email-masked]
Date: 24 Apr 1999 12:49:15 +0200

Matthias Clasen <[email-masked]> writes:

  > [...] We should just make sure we parse the rc file in the "C"
  > locale and then use isspace((unsigned char*)*p) or a macro for
  > this. [...]

Naive question: does this work if people use Chinese (say) menu
entries or have windows with Chinese (say) window titles (and use
window titles in Next [...] constructions)?

kai
-- 
Abort this operation?   [Abort]  [Cancel]

---

From: Matthias Clasen <[email-masked]>
Date: Sun, 25 Apr 1999 00:58:55 +0200

> From: [email-masked]
> Date: 24 Apr 1999 12:49:15 +0200
> User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) Emacs/20.3.8
> Content-Type: text/plain; charset=us-ascii
> Sender: [email-masked]
> Precedence: list
> X-Majordomo: 1.94.jlt7
> 

Ah, I noticed this problem too, after sending the comment above.
I guess it won't work unless you are lucky and your mb locale
uses the same single byte characters for spaces as latin-1. These
issues really should be resolved by someone with first-hand 
experience with mb locales. 

I have taken a closer look at the I18N patch and have written
up what I think we need to get away without an #ifdef mess:

#ifndef MB_H
#define MB_H

#include "config.h"

/* return a text property, doing locale specific conversions,
 use this for WM_NAME and WM_ICON_NAME, this has to be defined
using XGetTextProperty and mbTextPropertyToStringList, probably
discarding all but the first returned strings */
char *GetTextProperty(Display *, Window, Atom);

#ifdef I18N_MB

#include <X11/Xlocale.h>

/* Font should be used as the type of MyFont.font 
   and as the return value of GetFontOrFixed */
typedef XFontSet Font;

/* use DrawString where we currently use XDrawString,
   note that DrawString has an additional font parameter */
#define DrawString(dpy,win,font,gc,x,y,text,len) \
        XmbDrawString(dpy,win,font,gc,x,y,text,len)

/* use this instead of directly setting the MyFont.height variable,
   this has to be implemented using XExtentsOfFontSet */
void SetFontHeight(MyFont *myfont); 

/* use FreeFont wehere we currently use XFreeFont */
#define FreeFont(dpy,font) XFreeFontSet(dpy,font)

#else /* !I18N_MB */

typedef XFontStruct *Font; 

#define DrawString(dpy,win,font,gc,x,y,text,len) \
	XDrawString(dpy,win,gc,x,y,text,len)

#define SetFontHeight(myfont) \
  (myfont)->height = (myfont)->font->ascent + (myfont)->font->descent

#define FreeFont(dpy,font) XFreeFont(dpy,font)

#endif /* !I18N_MB */

#endif /* MB_H */

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 25 Apr 1999 21:55:41 +0200

> Now resolve all the conflicts.  

BTW, as a first step, shouldn't we simply realease 2.2 with this
patch (or better: 2.2.1)? Can someone who fiddled with the patch
do this?

Apropos 2.2.1, although there has been a bit of work in the 2.2
branch we still did not release 2.2.1. I'd be grateful if someone
would take the responsibility of making this release out of my
hands (I'm not comfortable enough with CVS to try it).

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: Steve Robbins <[email-masked]>
Date: Wed, 28 Apr 1999 20:35:58 -0400 (EDT)

> hands (I'm not comfortable enough with CVS to try it).

I'll do it.  

Making a 2.2.1 with what we have is easy enough, BUT we should put some
effort into fixing the most egregious bugs -- those that crash FVWM. 

I went through the bug-tracker database, and found a number of crash
reports.  

HOWEVER, many, many, of these reports have been moved into the file
"fixed" without a note to indicate how or when it was fixed.  This makes
it more than a little difficult to track down and apply to the 2.2 branch. 

May I suggest the following:

  1. add a note to the report *every time* you move it to another folder

  2. if you commit anything to CVS to fix it, stick the PR# in the
     ChangeLog

  3. if a report comes in that has *already* been fixed in CVS, 
     attach a note to the report giving the changelog entries of the
     fix (or at least note the commit date so that one can track down the
     fix later)

Of course, that's for the future.

For the present, can I ask you to scan the "fixed" folder for crash
reports that *you* moved in there, and figure out what the fix was?  Feel
free to backport the fix to the 2.2 branch if you like.  If not, email me
all the details: what caused the bug, how it was fixed, and the commit
times, and I'll dig through CVS to find the patch.

If we release a 2.2.1 without doing this, we're liable to get:

    (a) a whole bunch of reports for bugs that have already been fixed
and
    (b) a reputation for not fixing bugs!

Thanks in advance.

---

From: Jason L Tibbitts III <[email-masked]>
Date: 28 Apr 1999 20:10:24 -0500

>>>>> "SR" == Steve Robbins <[email-masked]> writes:

SR> For the present, can I ask you to scan the "fixed" folder for crash
SR> reports that *you* moved in there, and figure out what the fix was?

To aid in this:

150    Wed Mar 17 14:31:59 1999      clasen  moved from enhancements to fixed
196    Sun Feb 28 14:18:19 1999      clasen  moved from incoming to fixed
197    Sun Feb 28 14:18:20 1999      clasen  moved from incoming to fixed
198    Sun Feb 28 14:18:21 1999      clasen  moved from incoming to fixed
214    Tue Mar  9 06:27:15 1999      clasen  moved from incoming to fixed
215    Tue Mar 16 18:52:24 1999      clasen  moved from enhancements to fixed
292    Mon Apr 12 10:44:41 1999      clasen  moved from incoming to fixed
293    Mon Apr 12 10:54:22 1999      clasen  moved from incoming to fixed
299    Mon Apr 12 10:48:09 1999      clasen  moved from incoming to fixed
307    Mon Apr 19 11:21:58 1999      clasen  moved from incoming to fixed

85     Tue Dec 15 14:47:19 1998      dane    moved from incoming to fixed
179    Sun Feb 28 12:22:51 1999      dane    moved from incoming to fixed
228    Mon Mar  8 12:53:56 1999      dane    moved from incoming to fixed

8      Mon Dec 14 03:32:51 1998      domivogt        moved from confirmed to fixed
10     Mon Mar  8 06:57:45 1999      domivogt        moved from postponed to fixed
12     Thu Mar 11 04:06:20 1999      domivogt        moved from enhancements to fixed
17     Mon Nov 30 06:06:52 1998      domivogt        moved from in progress to fixed
24     Wed Nov 25 04:45:55 1998      domivogt        moved from dominik to fixed
26     Thu Dec 10 06:23:23 1998      domivogt        moved from in progress to fixed
28     Mon Dec  7 20:03:34 1998      domivogt        moved from in progress to fixed
28     Tue Jan 19 04:14:33 1999      domivogt        moved from verify fix to fixed
29     Wed Dec  2 06:48:06 1998      domivogt        moved from incoming to fixed
31     Mon Jan 11 12:32:14 1999      domivogt        moved from verify fix to fixed
32     Wed Dec  9 12:57:57 1998      domivogt        moved from unreproducible to fixed
34     Mon Mar  8 06:57:45 1999      domivogt        moved from postponed to fixed
37     Mon Mar  8 06:52:31 1999      domivogt        moved from enhancements to fixed
40     Mon Jan 11 12:32:14 1999      domivogt        moved from verify fix to fixed
45     Tue Mar 23 07:03:51 1999      domivogt        moved from enhancements to fixed
46     Sat Dec  5 21:34:00 1998      domivogt        moved from dominik to fixed
48     Fri Dec 11 12:26:38 1998      domivogt        moved from incoming to fixed
49     Wed Dec  9 07:33:49 1998      domivogt        moved from incoming to fixed
50     Wed Dec  9 04:01:21 1998      domivogt        moved from dominik to fixed
51     Wed Dec  9 04:00:28 1998      domivogt        moved from incoming to fixed
57     Wed Dec  9 03:59:26 1998      domivogt        moved from incoming to fixed
62     Wed Dec  9 04:05:11 1998      domivogt        moved from incoming to fixed
64     Mon Dec 14 12:30:57 1998      domivogt        moved from incoming to fixed
65     Tue Dec 22 05:46:59 1998      domivogt        moved from incoming to fixed
67     Wed Dec  9 04:45:06 1998      domivogt        moved from incoming to fixed
74     Mon Dec 14 12:41:50 1998      domivogt        moved from incoming to fixed
75     Mon Mar  8 06:52:31 1999      domivogt        moved from enhancements to fixed
77     Wed Dec 16 05:02:38 1998      domivogt        moved from in progress to fixed
77     Wed Jan 13 19:56:28 1999      domivogt        moved from confirmed to fixed
79     Fri Dec 18 05:48:37 1998      domivogt        moved from confirmed to fixed
80     Fri Dec 18 05:48:38 1998      domivogt        moved from confirmed to fixed
82     Wed Dec 16 04:59:37 1998      domivogt        moved from incoming to fixed
83     Wed Dec 16 04:57:24 1998      domivogt        moved from incoming to fixed
84     Wed Dec 23 19:28:09 1998      domivogt        moved from incoming to fixed
86     Wed Dec 16 04:57:25 1998      domivogt        moved from incoming to fixed
87     Fri Dec 18 05:48:38 1998      domivogt        moved from confirmed to fixed
91     Thu Dec 17 04:33:57 1998      domivogt        moved from incoming to fixed
92     Thu Dec 17 04:33:58 1998      domivogt        moved from incoming to fixed
95     Mon Jan 11 12:32:14 1999      domivogt        moved from verify fix to fixed
97     Mon Dec 28 13:15:20 1998      domivogt        moved from incoming to fixed
98     Tue Dec 22 05:46:05 1998      domivogt        moved from dominik to fixed
101    Tue Apr 13 10:17:11 1999      domivogt        moved from dominik to fixed
104    Tue Apr 27 10:01:07 1999      domivogt        moved from in progress to fixed
109    Tue Jan 19 04:12:50 1999      domivogt        moved from unreproducible to fixed
110    Sat Jan  2 00:46:48 1999      domivogt        moved from incoming to fixed
112    Tue Jan 19 04:12:50 1999      domivogt        moved from unreproducible to fixed
114    Sun Mar 21 12:36:48 1999      domivogt        moved from in progress to fixed
118    Wed Jan 13 06:29:54 1999      domivogt        moved from incoming to fixed
119    Tue Jan 19 04:14:33 1999      domivogt        moved from verify fix to fixed
123    Tue Jan 26 05:11:01 1999      domivogt        moved from verify fix to fixed
127    Wed Jan 13 19:57:19 1999      domivogt        moved from incoming to fixed
128    Tue Feb  2 12:47:16 1999      domivogt        moved from incoming to fixed
145    Tue Feb  2 12:32:02 1999      domivogt        moved from dominik to fixed
147    Tue Feb  2 12:32:02 1999      domivogt        moved from dominik to fixed
149    Tue Feb  2 12:26:11 1999      domivogt        moved from incoming to fixed
151    Sun Mar 21 12:35:50 1999      domivogt        moved from dominik to fixed
152    Fri Jan 29 10:48:11 1999      domivogt        moved from incoming to fixed
154    Tue Feb  2 12:45:45 1999      domivogt        moved from incoming to fixed
163    Fri Feb 12 04:25:54 1999      domivogt        moved from confirmed to fixed
164    Tue Feb 16 08:21:04 1999      domivogt        moved from incoming to fixed
166    Fri Feb 12 04:25:54 1999      domivogt        moved from confirmed to fixed
167    Mon Mar  8 06:54:22 1999      domivogt        moved from verify fix to fixed
168    Sun Mar 21 15:33:20 1999      domivogt        moved from confirmed to fixed
170    Tue Mar 16 04:52:51 1999      domivogt        moved from enhancements to fixed
173    Mon Mar  8 06:53:36 1999      domivogt        moved from enhancements to fixed
178    Wed Mar 10 03:48:44 1999      domivogt        moved from dominik to fixed
181    Sun Mar 21 12:38:02 1999      domivogt        moved from incoming to fixed
185    Tue Mar 16 04:47:52 1999      domivogt        moved from confirmed to fixed
186    Thu Mar 11 13:07:08 1999      domivogt        moved from incoming to fixed
187    Mon Mar  8 06:36:56 1999      domivogt        moved from incoming to fixed
189    Sun Mar 21 12:36:29 1999      domivogt        moved from dominik to fixed
203    Sun Mar 21 15:35:12 1999      domivogt        moved from dominik to fixed
204    Mon Mar  8 06:40:54 1999      domivogt        moved from incoming to fixed
205    Wed Mar 10 03:52:30 1999      domivogt        moved from incoming to fixed
206    Sun Mar 28 22:50:01 1999      domivogt        moved from verify fix to fixed
213    Mon Mar  8 06:39:35 1999      domivogt        moved from incoming to fixed
216    Mon Mar  8 06:42:02 1999      domivogt        moved from incoming to fixed
225    Thu Mar 11 04:01:54 1999      domivogt        moved from incoming to fixed
227    Sun Mar 28 22:50:01 1999      domivogt        moved from verify fix to fixed
234    Tue Mar 16 04:53:35 1999      domivogt        moved from enhancements to fixed
237    Thu Mar 11 04:02:34 1999      domivogt        moved from incoming to fixed
239    Tue Mar 16 04:49:45 1999      domivogt        moved from in progress to fixed
241    Fri Mar 12 07:42:54 1999      domivogt        moved from incoming to fixed
245    Sun Mar 21 12:39:20 1999      domivogt        moved from incoming to fixed
254    Sun Mar 21 12:39:52 1999      domivogt        moved from incoming to fixed
255    Sun Mar 28 22:50:01 1999      domivogt        moved from verify fix to fixed
269    Tue Mar 23 07:01:34 1999      domivogt        moved from incoming to fixed
273    Wed Mar 24 12:21:01 1999      domivogt        moved from incoming to fixed
274    Tue Apr 13 04:29:54 1999      domivogt        moved from incoming to fixed
278    Fri Apr  2 17:42:06 1999      domivogt        moved from incoming to fixed
279    Fri Apr  2 17:38:55 1999      domivogt        moved from incoming to fixed
283    Fri Apr  2 17:38:57 1999      domivogt        moved from incoming to fixed
286    Fri Apr  2 17:38:59 1999      domivogt        moved from incoming to fixed
288    Fri Apr  2 17:39:01 1999      domivogt        moved from incoming to fixed

71     Sun Jan 10 18:43:20 1999      drbob   moved from confirmed to fixed
96     Sat Dec 19 08:02:26 1998      drbob   moved from confirmed to fixed
131    Wed Jan 13 23:19:06 1999      drbob   moved from incoming to fixed
140    Thu Jan 28 14:46:00 1999      drbob   moved from confirmed to fixed
162    Fri Feb  5 07:41:57 1999      drbob   moved from incoming to fixed
175    Wed Feb 17 23:14:49 1999      drbob   moved from incoming to fixed
177    Tue Feb 16 21:51:36 1999      drbob   moved from incoming to fixed

13     Tue Mar 16 05:36:27 1999      hippo   moved from enhancements to fixed
63     Fri Dec 11 09:53:02 1998      hippo   moved from incoming to fixed
117    Tue Feb 23 09:24:43 1999      hippo   moved from confirmed to fixed
132    Tue Feb 23 08:12:34 1999      hippo   moved from confirmed to fixed
133    Tue Mar 16 05:34:09 1999      hippo   moved from confirmed to fixed
148    Tue Feb 23 08:15:38 1999      hippo   moved from confirmed to fixed
161    Tue Mar 16 06:45:08 1999      hippo   moved from confirmed to fixed
171    Tue Feb 16 06:58:01 1999      hippo   moved from incoming to fixed
219    Tue Mar 16 05:39:55 1999      hippo   moved from enhancements to fixed

22     Wed Nov 25 00:20:19 1998      psmith  moved from incoming to fixed
41     Wed Dec  2 20:50:58 1998      psmith  moved from in progress to fixed
43     Wed Dec  2 23:06:01 1998      psmith  moved from enhancements to fixed
137    Tue Feb  2 12:47:01 1999      psmith  moved from incoming to fixed
144    Tue Feb  2 12:48:48 1999      psmith  moved from incoming to fixed
212    Fri Mar 12 09:23:31 1999      psmith  moved from incoming to fixed

201    Sat Mar 13 09:25:06 1999      steve   moved from incoming to fixed
309    Tue Apr 27 09:21:41 1999      steve   moved from incoming to fixed
--
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: Bob Woodside <[email-masked]>
Date: Wed, 28 Apr 1999 22:06:02 -0400

Jason L Tibbitts III wrote:
> To aid in this:  ...

	All of these are in the 2.2 release.

- Bob

---

From: Tim Phipps <[email-masked]>
Date: Thu, 29 Apr 1999 09:11:10 +0100

> 161    Tue Mar 16 06:45:08 1999      hippo   moved from confirmed to fixed
Not important
> 171    Tue Feb 16 06:58:01 1999      hippo   moved from incoming to fixed
Fixed in 2.2
> 219    Tue Mar 16 05:39:55 1999      hippo   moved from enhancements to fixed
Not important

Cheers,
Tim.

---

From: Dan Espen <[email-masked]>
Date: Thu, 29 Apr 1999 16:19:11 -0400

> 228    Mon Mar  8 12:53:56 1999      dane    moved from incoming to fixed

In order to apply a fix for 2.2.1, I looked at the tags:

        version-2_3_1                   (revision: 1.5)
        version-2_3_0                   (revision: 1.5)
        branch-2_2                      (branch: 1.5.2)
        version-2_2                     (revision: 1.5)
        version-2_2_0                   (revision: 1.5)
        version-2_1_13                  (revision: 1.5)

Seeing this, I assume that "branch_2_2" is the right thing to checkout.
I did that, but as I went to update the NEWS file, I see that there is
no post-2.2 news.

I know bug fixes don't normally appear as NEWS, but I have 2 questions.

1. Was this the right branch to check out?

2. Don't we need a little more than the ChangeLog to explain whats
in the 2.2.1 release?

---

From: [email-masked] (Paul D. Smith)
Date: 29 Apr 1999 16:46:06 -0400

%% Dan Espen <[email-masked]> writes:

  de> 1. Was this the right branch to check out?

Yes.  Note I greatly expanded the stuff in cvs.html and in DEVELOPERS
a while back describing how this works and the naming conventions we
(appear to be :) using.

  de> 2. Don't we need a little more than the ChangeLog to explain whats
  de> in the 2.2.1 release?

If, at the time of release, there's nothing NEWS-worthy then typically I
put a note in the NEWS file that says something like "Bug fixes--see the
ChangeLog entries".

I think that's sufficient, myself.

---

From: Matthias Clasen <[email-masked]>
Date: Thu, 29 Apr 1999 23:54:49 +0200

196 off-by-1 shading - fix in 2.2
197 button-or-keypress assumption in InteractiveMove - fix in 2.2
198 quote vs GetArgument - fix in 2.2
214 raising missed by pager - no fix for 2.2, correct behavior in 2.3
150 cursor color  - enhancement in 2.3
215, 299 popuponbottom - enhancement in 2.3
292, 293 grab transient - enhancement in 2.3
307 neverfocus - enhancement in 2.3

Matthias

---

From: Dan Espen <[email-masked]>
Date: Thu, 29 Apr 1999 21:12:32 -0400

> a while back describing how this works and the naming conventions we

Believe it or not, I read cvs.html.  You've added a lot of great stuff.
Whats confusing is that you check out 2.2, but you really have 2.2.1.

> I think that's sufficient, myself.

Agreed.  I added one entry.

Wish I had remembered about the automake/autoconf version difference...

> -- 
>  Paul D. Smith <[email-masked]>         Network Management Developmen

---

From: [email-masked] (Paul D. Smith)
Date: 29 Apr 1999 21:44:22 -0400

de> Believe it or not, I read cvs.html.  You've added a lot of great stuff.
  de> Whats confusing is that you check out 2.2, but you really have 2.2.1.

Yes, that's because the _branch_ is 2.2, but the tagged points on the
branch are 2.2.1, 2.2.2, 2.2.3, etc.

If you check out a version like 2.2.1 (if it existed), then you'd get
exactly that version and update would do nothing (just like if you
checked out 2.3.1 on the main branch).

But if you check out a _branch_ like 2.2, then you always get the latest
code in the 2.2.x series and can update to later code in the 2.2.x
series, just like if you check out the main branch.

Does this make sense?