9:55 p.m.
Some time ago, Ben Wing wrote...
|+
| I think you should implement this using the standard property mechanism for Lisp
| objects.
|
| There are a million strange properties for a device under X, such as "does
| backing store" (Aren't there some other weird hacks that exist for this?).
| Unfortunately, most of the properties that you implemented for Windows exist
| under X only in the context of an add-on package such as Motif or CDE. Anyone
| want to implement a CDE interface for XEmacs?
I have been thinking about using properties for that, and my opinion is that
a separate function would do better. These properties are different that
"regular" object properties in so that
- they are never settable;
- we cannot allow a window system not to have one of these. They are
numerous, and if someone sets any of these under a window system
which treats this property as "just a symbol", this code will fail
under another window system which treats a property by the same name
specially. This will likely be a source of bugs.
- Getting "device-properties" may be costly. We cannot disallow getting
a list of all properties. For "metrics" which are different than
properties this is ok though when they are not availble wholesale.
The properties I listed are not specific for Windows, I think there
are only 75% of these are obtainable from Windows. I tried to compile
a list of properties useful as XEmacs fallbacks for different geometrical
metrics, so "does backing store" perhaps not worthy listing here.
Kirill
|
| Kirill M. Katsnelson wrote:
|
| > I implemented a single lisp function, which returns many information
| > aspects about the window system. There were six such functions already:
| > device-{pixel,mm}-{height,width}, device-bitplanes, device-color-cells.
| > Recently I added a Windows specific function which obtain default
| > scrollbar sizes. If this continues, there will be a flood of device
| > specific functions.
| >
| > You pass this function a device and a symbol for the capability you
| > want, and it returns metric's value. May I please ask everyone to
| > review the current list of capabilities, and to add what I missed?
| > Maybe not restricted to X and MS Windows, anything which fits into a
| > window system model and applies to XEmacs.
| >
| > Another question is which of these metrics are supported by X.
| > I implmented only 6 old metrics, maybe an X server can be asked
| > for more information?
| >
| > Here's a docstring, to avoid snarfing the patch file:
| >
| > DEFUN ("device-system-metrics", Fdevice_system_metrics, 2, 2, 0, /*
| > Get metrics for DEVICE as provided by the system.
| >
| > METRIC must be a symbol specifying requested metric. Note that
| > the metrics returned are these provided by the system internally,
| > not read from resources, so obtained from the mostly internal level.
| >
| > If a metric is not provided by the system, return value is nil.
| > Boolean values are returned as zero and non-zero integers.
| >
| > Metrics, by group, are:
| >
| > COLORS. Colors are returned as valid color instantiators. No other
| > assumption on the returned valie should be made (i.e. it can be a
| > string on one system but a color instance on another). For colors,
| > returned value is a cons of foreground and background colors. Note
| > that if the system provides only one color of the pair, the second
| > one may be nil.
| >
| > 'color-default Standard window text foreground and background.
| > 'color-select Selection highligh text and backgroun colors.
| > 'color-balloon Ballon popup text and background colors.
| > 'color-3d-face 3-D object (button, modeline) text and surface colors.
| > 'color-3d-light Fore and back colors for 3-D edges facing light source.
| > 'color-3d-dark Fore and back colors for 3-D edges facing away from
| > light source.
| > 'color-menu Text and background for menus
| > 'color-menu-high Selected menu item colors
| > 'color-menu-button Menu button colors
| > 'color-menu-unsel Unselectable menu item colors
| > 'color-toolbar Toolbar foreground and background colors
| > 'color-scrollbar Scrollbar foreground and background colors
| > 'color-desktop Desktop window colors
| > 'color-workspace Workspace window colors
| >
| > FONTS. Fonts are returned as valid font instantiators. No other
| > assumption on the returned value should be made (i.e. it can be a
| > string on one system but font instance on another).
| >
| > 'font-default Default fixed width font.
| > 'font-menubar Menubar font
| > 'font-dialog Dialog boxes font
| >
| > GEOMETRY. These metrics are returned as conses of (X . Y). As with colors,
| > either car or cdr of the cons may be nil if the system does not provide one
| > of corresponding dimensions.
| > 'size-cursor Mouse cursor size.
| > 'size-scrollbar Scrollbars (WIDTH . HEIGHT)
| > 'size-menu Menubar height, as (nil . HEIGHT)
| > 'size-toolbar Toolbar width and height.
| > 'size-tbbutton Toolbar button size.
| > 'size-tbborder Toolbar border width and height.
| > 'size-icon Icon dimensions.
| > 'size-icon-small Small icon dimensions.
| > 'size-device Device screen size in pixels.
| > 'size-workspace Workspace size in pixels. This can be less than the above
| > if window manager has decorations which effectively shrink
| > the area remaining for application windows.
| > 'size-device-mm Device screen size in millimeters.
| > 'device-dpi Device resolution, in dots per inch.
| >
| > 'num-bit-planes Integer, number of deive bit planes.
| > 'num-color-cells Integer, number of device color cells.
| >
| > FEATURES. This group reports various device features. Boolean values retuned
| > as integer 1 for true and zero for false, or nil if the feature is unknown
| > for the system.
| >
| > 'mouse-buttons Number of mouse buttons, or zero if no mouse (integer).
| > 'swap-buttons Non-zero if left and right mouse buttons are swapped
| > 'show-sounds User preference for visual over audible bell (boolean).
| > 'slow-device Device is slow, avoid animation (boolean).
| > 'security Non-zero if user environment is secure.
| > 'dbcs Window system supports DBCS (boolean).
| > 'ime Device embeds an input method editor (boolean).
| > 'mid-east Non-zero if the window system is enabled for Hebrew
| > and Arabic (left-to-right reading) languages.
| > */
| > (device, metric))
| >
| > Steve, I haven't built with tty and X, only compiled for syntax check
| > (build with X still fails on NT, and I'm far away from solaris). Could
| > you please ensure that the 6 (2 on ttys) moved lisp functions return
| > correct values? I C-x C-e'ed them right in ChangeLog :) TIA.
| >
|-
8:51 a.m.
New subject: [PATCH] Generalization of system metrics
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.
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.
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.
Kirill M. Katsnelson wrote:
Some time ago, Ben Wing wrote...
|+
| I think you should implement this using the standard property mechanism for Lisp
| objects.
|
| There are a million strange properties for a device under X, such as "does
| backing store" (Aren't there some other weird hacks that exist for this?).
| Unfortunately, most of the properties that you implemented for Windows exist
| under X only in the context of an add-on package such as Motif or CDE. Anyone
| want to implement a CDE interface for XEmacs?
I have been thinking about using properties for that, and my opinion is that
a separate function would do better. These properties are different that
"regular" object properties in so that
- they are never settable;
- we cannot allow a window system not to have one of these. They are
numerous, and if someone sets any of these under a window system
which treats this property as "just a symbol", this code will fail
under another window system which treats a property by the same name
specially. This will likely be a source of bugs.
- Getting "device-properties" may be costly. We cannot disallow getting
a list of all properties. For "metrics" which are different than
properties this is ok though when they are not availble wholesale.
The properties I listed are not specific for Windows, I think there
are only 75% of these are obtainable from Windows. I tried to compile
a list of properties useful as XEmacs fallbacks for different geometrical
metrics, so "does backing store" perhaps not worthy listing here.
Kirill
|
| Kirill M. Katsnelson wrote:
|
| > I implemented a single lisp function, which returns many information
| > aspects about the window system. There were six such functions already:
| > device-{pixel,mm}-{height,width}, device-bitplanes, device-color-cells.
| > Recently I added a Windows specific function which obtain default
| > scrollbar sizes. If this continues, there will be a flood of device
| > specific functions.
| >
| > You pass this function a device and a symbol for the capability you
| > want, and it returns metric's value. May I please ask everyone to
| > review the current list of capabilities, and to add what I missed?
| > Maybe not restricted to X and MS Windows, anything which fits into a
| > window system model and applies to XEmacs.
| >
| > Another question is which of these metrics are supported by X.
| > I implmented only 6 old metrics, maybe an X server can be asked
| > for more information?
| >
| > Here's a docstring, to avoid snarfing the patch file:
| >
| > DEFUN ("device-system-metrics", Fdevice_system_metrics, 2, 2, 0, /*
| > Get metrics for DEVICE as provided by the system.
| >
| > METRIC must be a symbol specifying requested metric. Note that
| > the metrics returned are these provided by the system internally,
| > not read from resources, so obtained from the mostly internal level.
| >
| > If a metric is not provided by the system, return value is nil.
| > Boolean values are returned as zero and non-zero integers.
| >
| > Metrics, by group, are:
| >
| > COLORS. Colors are returned as valid color instantiators. No other
| > assumption on the returned valie should be made (i.e. it can be a
| > string on one system but a color instance on another). For colors,
| > returned value is a cons of foreground and background colors. Note
| > that if the system provides only one color of the pair, the second
| > one may be nil.
| >
| > 'color-default Standard window text foreground and background.
| > 'color-select Selection highligh text and backgroun colors.
| > 'color-balloon Ballon popup text and background colors.
| > 'color-3d-face 3-D object (button, modeline) text and surface colors.
| > 'color-3d-light Fore and back colors for 3-D edges facing light source.
| > 'color-3d-dark Fore and back colors for 3-D edges facing away from
| > light source.
| > 'color-menu Text and background for menus
| > 'color-menu-high Selected menu item colors
| > 'color-menu-button Menu button colors
| > 'color-menu-unsel Unselectable menu item colors
| > 'color-toolbar Toolbar foreground and background colors
| > 'color-scrollbar Scrollbar foreground and background colors
| > 'color-desktop Desktop window colors
| > 'color-workspace Workspace window colors
| >
| > FONTS. Fonts are returned as valid font instantiators. No other
| > assumption on the returned value should be made (i.e. it can be a
| > string on one system but font instance on another).
| >
| > 'font-default Default fixed width font.
| > 'font-menubar Menubar font
| > 'font-dialog Dialog boxes font
| >
| > GEOMETRY. These metrics are returned as conses of (X . Y). As with colors,
| > either car or cdr of the cons may be nil if the system does not provide one
| > of corresponding dimensions.
| > 'size-cursor Mouse cursor size.
| > 'size-scrollbar Scrollbars (WIDTH . HEIGHT)
| > 'size-menu Menubar height, as (nil . HEIGHT)
| > 'size-toolbar Toolbar width and height.
| > 'size-tbbutton Toolbar button size.
| > 'size-tbborder Toolbar border width and height.
| > 'size-icon Icon dimensions.
| > 'size-icon-small Small icon dimensions.
| > 'size-device Device screen size in pixels.
| > 'size-workspace Workspace size in pixels. This can be less than the above
| > if window manager has decorations which effectively shrink
| > the area remaining for application windows.
| > 'size-device-mm Device screen size in millimeters.
| > 'device-dpi Device resolution, in dots per inch.
| >
| > 'num-bit-planes Integer, number of deive bit planes.
| > 'num-color-cells Integer, number of device color cells.
| >
| > FEATURES. This group reports various device features. Boolean values retuned
| > as integer 1 for true and zero for false, or nil if the feature is unknown
| > for the system.
| >
| > 'mouse-buttons Number of mouse buttons, or zero if no mouse (integer).
| > 'swap-buttons Non-zero if left and right mouse buttons are swapped
| > 'show-sounds User preference for visual over audible bell (boolean).
| > 'slow-device Device is slow, avoid animation (boolean).
| > 'security Non-zero if user environment is secure.
| > 'dbcs Window system supports DBCS (boolean).
| > 'ime Device embeds an input method editor (boolean).
| > 'mid-east Non-zero if the window system is enabled for Hebrew
| > and Arabic (left-to-right reading) languages.
| > */
| > (device, metric))
| >
| > Steve, I haven't built with tty and X, only compiled for syntax check
| > (build with X still fails on NT, and I'm far away from solaris). Could
| > you please ensure that the 6 (2 on ttys) moved lisp functions return
| > correct values? I C-x C-e'ed them right in ChangeLog :) TIA.
| >
|-
--
This message composed using voice recognition software and foot pedals.
(No keyboards were harmed while composing this message.)
9:55 p.m.
New subject: [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
9:17 p.m.
New subject: [PATCH] Generalization of system metrics
Some time ago, I wrote...
|+
| Some time ago, Ben Wing wrote...
| | 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.
|-
Ok, a silly idea. What if we decide that if a property symbol name begins with some
character,
this property is stuffed into a plist by XEmacs itself. A property starting with that
character
can never be added to an object by lisp code. ~!＠$%^& are candidates... Actually,
I've been
thinking about keywords which are distinguishable by their first letter ':'.
I do not think whether it is good or ugly, but it does solve namespace problem.
Kirill
9492
days inactive
9497
days old
3 comments
2 participants
participants (2)
-
Ben Wing -
Kirill M. Katsnelson