Re: Summary of gtk implementation discussion...
At 10:00 AM 4/19/00 -0500, William M. Perry wrote:
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.
Sounds cool. I could really do with this.
- Instead of an assoc list, a property list would be the
representation of
the widget properties.
I think whatever you prefer you should go with what is currently in XEmacs.
So yes, use plists.
- Should use real faces to specify the 'look' of a widget
Yes.
- 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?
Depends how often faces change I guess.
- 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.
I think if you get the abstraction right then you shouldn't have to care
too much about the internal implementation. i.e. if you provide sufficient
higher-level APIs. For instance ben's new dialog API should support
what we have now and what you are proposing relatively transparently.
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.
Do you mean internally or externally? Externally, I'm not sure how much you
would notice. Internally it would probably be worth having some sort of
unified data structure that can cope with both. Some discussion would
probably be useful :)
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd