On 15 Feb 2000, Lars Clausen wrote:
> On Wed, 16 Feb 2000, [EMAIL PROTECTED] wrote:
>
> > I am going over your patch at the moment. I am making a few
> > modifications at the moment (eg. use offset interface to simplify get/set
> > props functions further).
>
> Goodie. I should have known the properties were a moving target:) Do you
> agree with my suggestion to make a common namespace for properties such as
> line color, line width etc, BTW?
Yes that is a good idea (the whole idea of setting props on a group
requires that :) To make that easier, I am including a number of macros
in properties.h, so defining the properties for the arc looks like this:
static PropDescription arc_props[] = {
OBJECT_COMMON_PROPERTIES,
PROP_STD_LINE_WIDTH,
PROP_STD_LINE_COLOUR,
PROP_STD_LINE_STYLE,
PROP_STD_START_ARROW,
PROP_STD_END_ARROW,
PROP_DESC_END
};
This makes it even easier to make sure you use the same property
names/types (and means there is less likely to be multiple versions of the
translatable strings, which helps translators).
>
> > In general, if the patch is not too big, posting it to the list should be
> > OK. If it is fairly large, you might want to post a URL to the patch
> > instead. As far as the types of diffs, my favourite is unified (diff
> > -u), followed by context (diff -c). The reason for this is so I can read
> > the patch before applying it and without any context, this is almost
> > impossible.
>
> I'll try and remember (unified over context, unified over context, unifext
> over contied, unitext over confied,... whoops).
Not a big problem. Both are easy to read -- unified is just a little
easier :)
>
> > Also, I think most people are using mime mail readers these days, so it
> > should not be a problem to include them as attachments.
>
> Well, people with modems would still have to download them. But giving a
> URL is a good solution to that.
>
The list also has people who may not be interested in the patch, or people
who have timed phone charging who want to have the choice over downloading
the patch. For small patches though, it is not much of a problem. This
is similar to the rules for most development mailing lists.
> -Lars
>
James.
