Andy Piper <andy(a)xemacs.ORG&gt; 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.

At 12:38 PM 4/17/00 -0500, William M. Perry wrote: >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"))))))) Shouldn't you use XEmacs concepts like "face" rather than just simply colors? Shouldn't you use keywords rather than symbols here? It would be great if we could establish some sort of generic internal structure that could be used by both the gtk stuff and the existing widget stuff. >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'. This sounds cool. My concern is that whatever the interface is it is: a) Implementable in (Athena maybe), Motif and MS-Windows. b) Implemented in the above. Otherwise we just get people developing UI that only works on Linux and this is clearly unacceptable (from an XEmacs point-of-view, maybe not from a Infodock point-of-view). Customize and its widgets for all its faults does work on all platforms. Its not clear to me that (a) or (b) are true or ever will be with what you describe. I guess part of the problem is that gtk does a lot of the hard work for you that other windowing toolkits do not (correct me if I'm wrong). So my questions are: 1. Why is this suddenly top priority? I am assuming that there is some pressure from your sponsors to make this work so that rich GUI applications built off the XEmacs substrate can be built on Linux. I may or may not be correct - but it would be nice to know one way or the other. This is ok, but if support for all platforms is not on the agenda then I think we should sandbox the gtk specific stuff as a separate module or package or something. 2. The support you are talking about doesn't give you widgets in buffers or gutters. Do you have plans to implement this? If you do then a lot of my concerns vaporize. 3. When I first looked at the widget stuff I considered an integration with Tk since this would give you all the richness you describe + cross-platform support out of the box. I discounted this because I believe that UI's should have the same look-and-feel as their environment rather than one size fits all. If we are really seriously considering a generic UI environment for all platforms then maybe we should look again at this or something similar. I am sorry if this sounds very negative or defensive, but I have been through a lot of pain trying to support *everyone*, I could have just done everything for mswindows and decided to ignore everyone elses needs. Short-term gain, long-term pain IMHO. But please don't let me distract you from the major benefits we are going to see from any sort of gtk port in the first place. We are arguing over a small facet of this IMHO.

andy -------------------------------------------------------------- Dr Andy Piper Principal Consultant, BEA Systems Ltd