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.
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 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.
"William M. Perry" wrote:
Andy Piper <andy(a)xemacs.ORG> writes:
> At 07:22 PM 4/15/00 -0700, Ben Wing wrote:
> >hasn't andy already created a bunch of abstract interfaces onto widgets?
>
> Well, extended the glyph syntax is probably more accurate. But the syntax
> is abstract and does work, even if it is very simple.
I really don't like the thought of writing a complex gui as a bunch of
glyph instantiators either. For things that will be going in the gutter
this is doable, but writing something like the `customize' interface from
sawmill would be ... not fun.
I'm getting ready to start writing the detailed implementation plan, and
think that something like:
(setq gui
(make-gui
'(property-sheet
((name . "main sheet")
(background-color . "white")
(foreground-color . "black"))
(window
((name . "Tree Control Tab"))
(tree-control
((name . "first tree control")
(attribute-1 . "value-1")
(attribute-2 . "value-2")))))))
Will be the way to go. Basically a GUI would be a list similar to what the
Emacs/W3 HTML parser outputs (which would be similar to the theoretical XML
parser output for loading Glade output files). Basically each element is
(NAME ATTR-ASSOC CONTENT). The NAME can be used to pull the widget out of
the UI object later (to set/get properties of it - both Gtk and Qt provide
really easy ways to set properties based on text strings). The ATTR-ASSOC
is just an assoc list of attribute-value pairs.
If you wanted to change something about the widgets after creating the
initial UI, you could do:
(setq widget (gui-get-widget gui "main sheet")) ; perhaps 'main-sheet?
(put widget 'background-color "hotpink") ; just to sear the eyeballs
The main PITA here would be getting names for the widgets everyone can
agree upon. :) Andy has already done a lot of that though. I don't think
there are any major widgets implemented by Gtk not implemented by Qt and
vice versa. Motif and Athena are completely different stories though.
Callbacks would be Gtk/Qt-ish and have 'signals' that are emitted. You
would set the handlers for the signals either thru special attribute names
(signal-map or something like that) or 'widget-add-signal'.
I want to try and avoid conflicting with the current "^widget-.*" namespace
if at all possible. What do people think the namespace should be? UI?
GUI? SBH (stupid bill hack :)
-Bill P.
--
Ben
In order to save my hands, I am cutting back on my mail. I also write
as succinctly as possible -- please don't be offended. If you send me
mail, you _will_ get a response, but please be patient, especially for
XEmacs-related mail. If you need an immediate response and it is not
apparent in your message, please say so. Thanks for your understanding.
See also
http://www.666.com/ben/typing.html.