• Download
• XEmacs in GSoC
• FAQ
• Mailing lists
• Documentation
• People
• How to help
• Bugs
• Links

• Mailing lists
• Status of Services
• Near Future
• History of XEmacs
• XEmacs vs. GNU Emacs
• Screenshots
• Sites Created With XEmacs
• Year 2000 Statement
• Who Wrote XEmacs?
• XEmacs Contributors
• Website

• Download
• Optional Libraries
• Installation HOWTOs
• Quickstart Package Guide
• Documentation
• Installation resources
• Releases

• XEmacs Packages
• Other Interesting Sites
• Customization Links

• FAQ
• Reporting Bugs
• Troubleshooting resources
• Debugging

• How to help
• XEmacs in GSoC
• Open Issues
• Who Wrote XEmacs?
• XEmacs Contributors
• Dev team responsibilities
• Architecting XEmacs

Dialog Boxes

Owner: ???

Effort: ???

Dependencies: ???

1. The primary interface to creating dialog boxes should be a function something like popup-dialog-box that takes a tree that specifies the layout of the components and call-back functions and properties and such. What I mean by tree is a list of components, along with some layout properties, and the components can in turn recursively be lists of components and so on.

2. The layout mechanism needs to be general, similar to the way things are done under X and under the Java AWT toolkit, not hard-coded to specific positions like under Windows.

3. The layout mechanism should involve layout managers, which are functions that determine how components are to be laid out. I think it's possible to do this in a way that's sensible and not overly complicated but still works well, unlike the unwieldy and incomprehensible geometry management process in Xt.

4. We expose the current hard-coded layout mechanism in the redisplay engine as simply one layout manager that lays out its components in the expected fashion. Dialog boxes simply contain other layout managers laying things out in a different fashion. This way regular frames and dialog boxes are conceptually integrated.

5. The standard user interface elements of a frame are translated into components, which include a toolbar component, a scrollbar component, a menubar component, and an Emacs text area component, which includes a bare text area with a modeline optionally below it. Other components include buttons, list boxes, check boxes, radio boxes, grouping boxes, sliders, etc.

6. We should use the standard window-system-provided components for simple elements such as buttons, check boxes, etc. as much as possible. We should do the layout in a way that's compatible with the window system, which usually means using actual Windows controls or Xt/Motif widgets for many of the components. I think it would be a grave mistake to attempt to do all this simply by drawing things into a buffer as some have suggested for these reasons:

   • It would be extremely difficult to modify the existing redisplay mechanism to allow for many of the added features that we want.

   • It would never look as good as what could be done more simply with standard components and would certainly not look like what the user expects it to look like given other applications on the same window system.

   • It would seriously distort the current redisplay model to implement even a fraction of the things (for example, grouping components, which draw a box around their subcomponents) that could be done much more simply by creating a new layout mechanism and subsuming the existing layout of windows, buffers, toolbars and such into this mechanism. If we do this, then we keep the mechanism for drawing buffers clean and at least possible for somebody to understand and maintain.