On Tue, 2004-07-06 at 13:16, Han-Wen Nienhuys wrote:
> Our thoughts on this matter aren't entirely set in stone. Since you've
> already added a lot of properties, we can't save precious development
> time by not using properties :-) Maybe you could review all of them,
> and prune the ones which a
On Tue, Jul 06, 2004 at 08:59:03AM +0200, Han-Wen Nienhuys wrote:
> looking through your patch, I have the impression that you have a lot
> of properties. Having everything tweakable seems nice at first, but it
> makes the program more difficult to understand (as it pollutes the
> namespace for pr
[EMAIL PROTECTED] writes:
> > Since not every tuning property is useful, our current strategy is to
> > hard-code most constants, except for paddings and thicknesses (and
> > other parameters that we imagine to be changed frequently), and
> > respond to any request for more tunability by adding an
On Tue, 2004-07-06 at 05:50, Carl Sorensen wrote:
> I'd be very happy to get CVS access. How do I proceed?
>
I believe I can now answer my own question. I went to the savannah
website (http://savannah.gnu.org), clicked on "New User via SSL",
answered the questions, created a public GPG key, cr
On Tue, 2004-07-06 at 02:51, Han-Wen Nienhuys wrote:
> in particular, the thickness for fret-diagrams should not be renamed
> fret-thickness, but it should work like thickness works for other
> grobs.
>
OK. I can easily fix that one. That's in fact how it was originally
written.
Carl
On Tue, 2004-07-06 at 02:59, Han-Wen Nienhuys wrote:
> looking through your patch, I have the impression that you have a lot
> of properties. Having everything tweakable seems nice at first, but it
> makes the program more difficult to understand (as it pollutes the
> namespace for properties) and
[EMAIL PROTECTED] writes:
> Currently, define-grob-properties.scm is (almost) alphabetical by
> property. This makes it nice for avoiding the collisions that occur
> when two different grobs have a property with the same name, but makes
> it very difficult to see all the properties associated with
[EMAIL PROTECTED] writes:
> > I've just added the properties for fret-diagrams, and they're scattered
> > throughout define-grob-properties.scm. I'd be happy to collect them in
> > one section if it's preferred.
>
> the problem is that we try to minimise the number of properties, and
> reuse them
[EMAIL PROTECTED] writes:
> Currently, define-grob-properties.scm is (almost) alphabetical by
> property. This makes it nice for avoiding the collisions that occur
> when two different grobs have a property with the same name, but makes
> it very difficult to see all the properties associated with
Currently, define-grob-properties.scm is (almost) alphabetical by
property. This makes it nice for avoiding the collisions that occur
when two different grobs have a property with the same name, but makes
it very difficult to see all the properties associated with a given
grob.
Would it make sens
10 matches
Mail list logo
