Re: Milestone 1 submission...
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