Re: Customize bug?

Per Abrahamsen writes: Per> I'm not sure that is conceptually right. X resources gives the ability to Per> make "per display" customizations, while customize only support Per> customizations based on some broad display categories. The most specific Per> should win. E.g. you may want to select different font sizes for Per> different sized monitors , something customize cannot know about. When faced with an existing specifier-like mechanism[1] we often forget that the problems they solve is not really restricted to their domain. What's interesting in the X resources mechanism is not that you can specify on a per-display basis, but that for such or such display, you actually know that you'll get a BW or color, big or small screen etc. However, even if X provides a mechanism to cope with this variety of displays, those problems are not specific to X. For instance, some terminals support colors, some don't. We could also support the background pixmap resource in Eterm. But now, there's Xt and we're tempted to use it. It's a shame because it's limited, and it makes it harder for us to think of the design of a more generic specification model. What's missing now is a generic way of saying "I want this size, this look and this color. If I happen to work on BW, let's do this..." In other words, IMHO, if with X you can manage to get the size you want on all screens, but not with Custom, let's not conclude that X should override Custom. Let's conclude that the user needs a higher way of setting the font size, and X resources will be a "backend" for this model when running under X. I'm not saying this can be done in a few days :-) Footnotes: [1] The X resources mechanism is such, in the sense that you can "specify" on a per-display, per-langage, per-screen ... basis. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19