Ben Wing <ben(a)666.com> writes:
bill, please please let's not implement another incompatible gui
interface.
i really don't see how your example below is that different from creating a
glyph with an instantiator, except that you've replaced plists with alists,
etc.
None of this is (currently) expected to go into a buffer, so I don't think
glyphs are the right way to do them. plists, alists, I don't really care
which. In the lisp structure, I just think alists are easier to read, and
are similar to what the HTML and XML parsers would spit out (based on
current work in Emacs/W3 and PSGML).
somewhere in architecting-xemacs i also proposed an api for modifying
the
properties of instantiators (e.g. to add context menus to particular
toolbar/menubar/etc. items), which is similar to what you mention below.
I can't seem to find this... unless you mean 'General Lisp interface
changes (keyword arguments, generalized property interface, toolbar and
menubar changes, etc.)'. Hmmm... let me digest it for a minute...
The URL of that page is:
http://www.666.com/xemacs/lisp-interface.html
So the 'name' of the widget that I proposed would equate to one of your
'toolbar-path' types? And you could just do something like:
(put (gui-get-widget-by-name gui 'flubber) :text-alignment 'center)
(if "flubber" were some sort of multi-line text field or label). How to
extract a path would need specifying. You could just make this a list so
it is easily manipulated. So (top my-tab-control tab-number-one flubber)
given something like:
(make-gui (window
:name 'top
:children (tab-control
:name 'my-tab-control
:children (tab-item
:name 'tab-number-one
:children (label
:name 'flubber
:face 'widget-documentation-face
:text "This is a test\nCenter
Me")))))
get-widget-by-name could be implemented in lisp easily as long as the main
description was still around (perhaps as an automatically generated
property of the gui created?). Or you could just force the user to provide
the full path.
I would prefer to use put instead of something like set-gui-property,
especially after reading your plans outlined under 'property interface
changes', which I think make perfect sense. After hacking some of the
source and creating new objects, I was always surprised that more pieces of
XEmacs didn't use the object-specific get/put callbacks.
i also am still getting the feeling that you are thinking too
specifically in terms of gtk/qt in your interface. for example, i have
no idea what gtk signals are, but it sounds like a particular
implementation of what should probably be a more general interface.
I'd actually look at it the other way. Event filters and callbacks are the
lower level implementation and signals are the generalized interface. This
is exactly how gtk is implemented (and Qt as well) on top of X11. The
signals are abstractions of the events, and you don't have to worry about
the guts.
-bp