Preferred use of define-grob-properties.scm

[Han-Wen Nienhuys]

address@hidden 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 a given
> grob.

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 impacts performance negatively.

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 another property.


(oh, btw, good work - but applying patches is starting to get
tedious. Are you willing to look into getting CVS access?)

-- 

 Han-Wen Nienhuys   |   address@hidden   |   http://www.xs4all.nl/~hanwen