Re: Milestone 1 submission...

"William M. Perry" wrote: > Andy Piper <andy(a)xemacs.org&gt; writes: > > > 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. > > You could possibly use a face, but I personally hate the idea of creating > an entire face just because you want to change the background color on > _one_ item. Emacs allows you to stick a special property on a region just > to specify the background/foreground color. My emacs 21.x beta is screwed > up right now and can't even check docstrings, so I can't verify what the > syntax is. > > Having to worry about unique names for faces, whether they are temporary or > permanent, etc, etc, etc. gets kind of annoying. Emacs/W3 goes to some > pain to use temporary faces so that people don't wonder what the > w3-nil-nil-red-green face is all about. i agree with kyle. as i said before, please please please don't start creating incompatible interfaces for already existing features just because you see a shortcoming in the feature. Instead, figure out what's missing in the existing feature and extend it!! for example, maybe you really just want a hierarchy of faces, with their names having a path-like syntax, so that all w3 faces are grouped together instead of having one gigantic list. maybe you want to be able to declare new faces in your declaration of a widget, instead of having to create them separately.

in any case, you should think of extending existing functionality instead of creating new functionality, unless it's really necessary.

> > >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). > > It just does it in a slightly different way. The 'signals' are really just > callbacks for well defined events. Creating a wrapper around MS-Windows > would not be that difficult. It has been far too long since I've done any > Motif programming (thank the gods) for me to speak about doing it there > though. i'd advise you to consider a general interface that can be implemented using signals, rather than trying to create "wrappers" to force other implementations to conform to one particular implementation.

> > 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. > > I'm not being sponsored generically to 'work on XEmacs'... I am essentially > contracting for BeOpen.com (thru SourceXchange) for this specific project. > The main goals are unix portability at first. This will be distributed as > a set of patches against the 'stable' XEmacs and (I guess) integrated into > the core infodock sources that they do builds off of. When I get some more > breathing room, I plan on maintaining the port and getting as much of it > into the 21.2 (or later) tree. just keep in mind that a little extra time spent in the beginning figuring out a good design will both save you a lot of frustration later on and make it much more likely that your code will get integrated into the main source tree.