Re: [PATCH] Generalization of system metrics

Some time ago, Ben Wing wrote... |+ | First of all, I don't see why they can never be settable. It might be reasonable at | some point to allow the user to set them, which might cause changes to the registry or | something like that. What's the correct semantic for setting these then? I see the following behaviors, all of which look wrong to me. 1. Setting a metric immediately affects all programs runnnig on the same display. This is very wrong, and perhaps not implementable under X. 2. Setting a metric affects all frames of this XEmacs on a display. This is doable using specifiers in most cases. 3. Setting a metric affects all XEmacs frames on a display. Weird and hardly implementable. 4. Setting a metric just records a new value in the device object. This value is used when creating only new frames. In this case, lisp code may leave these metrics in arbitrary state, making XEmacs behavior undesired. My idea behind these was to get values provided by the very system. When some of these change, due to user's settings in control panel, XEmacs re-runs init lisp code, and re-reads the settings into ghost specifications. If xrdb notifies applications on resource changes (I still do not know if it does), then this approach is easily extendable on the X case. I was going to keep these pure and trustful, so lisp code can be sure that these properties reflect system defaults, not the values set by arbitrary lisp code. | Second of all, the name space problem that you mentioned is not specific to device | metrics or device properties -- the same sort of problem exists for all properties, as | well as for system calls, etc. Ok, suppose that under window system A property 'p is a device metric, so is supplied by the system and is read-only. Under window system B, this metric is not supplied by the system. Should setting of 'p be allowed under B? I have no answer. If yes, so 'p is a "usual" property, then this code may break under other window system. If no, we won't be able to extend the list of "reserved" properties without possibly affecting already existing lisp code. Could you please help solve that dilemma? This is basically why I intended to keep properties and metrics in separate namespaces. | Finally, I don't understand your point about obtaining the entire list of metrics being | expensive. This sort of operation is not something that is done on a regular basis for | other kinds of properties, either, but it is a potentially useful operation, so I don't | see why we should disallow this, as long as it is described the documentation. Ok. I just though that potentially this could involve a lot of client-server interaction. This is not the case on X, where most of these are not provided, neither on Windows, where there's no client and server. I'll do the list. Kirill