Re: Milestone 1 submission...

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.

> >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.

> 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.

> 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. Because so much is changing in the 21.2 stuff, I am going to initially be working off of 21.1.9. When I get back to the 'free time' hacking I want to move it up to 21.2 and maybe even do the 'real' port to use Gtk canvas and friends to do the redisplay. That would get you anti-aliased text, MS-Windows, MacOS, and BeOS ports trivially. Part of this 'upgrade' would be doing the widgets in buffers stuff. The first thing on the agenda is getting XEmacs to use the gtk/gnome widgets for its decorations, then comes the language bindings. > 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 definitely agree with the look-and-feel. This is one of the reasons I _hate_ 'themes' in modern toolkits like Qt and Gtk. The whole point of having a 'standard' toolkit is that things LOOK THE SAME. Even if two people are running the exact same version of GNOME and Gtk, the widget layouts and looks can vary far too much. This is why I am reworking my plans after you and ben argued for !gtk widget sets being used. I have no idea how difficult it would be to use motif, but win32 shouldn't be _terribly_ difficult. Not real high on my priority list, but I think the stuff I've outlined is generic enough to let it be done. > 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. All feedback is good feedback. I really appreciate all the time you took making the X stuff work. I unfortunately don't have the time or expertise to implement this under Windows at the same time. That's why I think exploring the native Gtk port would be interesting. But then you lose the 'looks like windows to me' aspect. Qt gets around this better than Gtk, since their windows theme is much more complete. But it is still only 99% there. I don't really notice because I never use windows any more, but daily windows users notice the little annoyances much more. > 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. And the Gtk GUI stuff will be completely separate from the Gtk language bindings. If one gets into the core XEmacs before the other, so be it. The one thing I _really_ hate is that Gtk and Qt are not multi-display. If we could use motif or something else eventually, I'd be ecstatic. I use the multi-display stuff fairly often and will really miss it when I start using the gtk version. :( -Bill P.