Summary of gtk implementation discussion...

Just wanted to make sure that I have everything straight with all the discussions going on. - Items in the UI should me modified with a 'path' to the object, derived from the names of the widgets. This is similar to ben's proposal at http://www.666.com/xemacs/lisp-interface.html (look for 'Toolbar Interface Changes'. I would propose using a full path instead of just a caption, because then names do not have to be _globally_ unique. - The path used would be a new data type so that the 'get' and 'put' methods for it could be overriden easily. All property modifications done after the gui was instantiated will be made with these calls. - Instead of an assoc list, a property list would be the representation of the widget properties. - Should use real faces to specify the 'look' of a widget - Allows us to have color names based on window systems, etc. - Should we allow inline face definitions? What would they look like? Customize-like property lists? How to specify the name? - Should we automagically update the widget properties when a face changes, or do we require a property change as well? Andy does automatic updating for the toolbars, but how expensive is it? Will it be prohibitively expensive when we get large user interfaces? - There has been some dissension on whether this is simply another 'glyph' representation or not. I don't think so. I think the overall layout of UIs should be the same across windowing systems, and these won't be embedded in a buffer or an emacs frame, so those types of conditionals in a glyph wouldn't be useful. Using faces takes care of colors/etc. Does that about sum it up? I think the main sticking point is the automatic updating of faces (perhaps not in the first release?) and whether to use a glyph representation. -Bill P.