Next Previous Contents

1. Introduction

Since version 0.13 the external Graphical User Interface (GUI) is independent of the core of the code. It has to use a standard mechanism to call the LyX kernel. For each specific GUI library you should use their style rules. For example if you want to write either a Gnome or a KDE frontend to LyX, follow their respective styles. We still support Xforms.

An external GUI is all those elements that makes more friendly the environment for most users: menus, toolbar, minibuffer, tip boxes, etc.

The way a GUI toolkit will connect with LyX is described in this document. The major area as yet undecided is how the workarea will interact with the rest of LyX. Interaction may be via a LyX library that provides a window or canvas (a buffer view) to be inserted into a toolkit's widget and be able to receive directly all its events and events from the scrollbars.

Currently the best way to test a new toolkit port is making it completely separate from the LyX sources and test it with a running instance of LyX via the LyX server.

A very good description of the reasons for GUI independence and a very elaborate scheme to achieve it is provided in the Mozilla project's cross-platform frontend, XPFE, design document. This scheme is perhaps the ultimate in GUI independence but will also be considerably larger and slower than the scheme we describe here.

Our aim is to achieve GUI independence in a manner that keeps the frontend as black as possible when viewed from the core of LyX. It should also support multi-toolkit development so that a partially ported GUI implementation is still fully functional. Ideally, the design should be sufficiently capable that no future rewrite will be necessary. If the first aim is met then we will have a considerably easier job of source maintenance and the possibility of specialist support for the GUI's without them needing to know about the rest of LyX as well.

LyX can be considered to have three parts:

LyX core

a.k.a. "the rest of LyX," this is all the functionality that gets the job done but doesn't involve the GUI directly. Essentially, all the functionality that would be needed for batch processing without a frontend. Ideally, every file except for those in frontends/ is used by such a batch processing LyX.

GUI frontend

an actual implementation of the GUI using a particular toolkit.

GUI backend

GUI independent support libraries or classes that are only needed by a GUI frontend. These components are not needed by the LyX core. Components such as toolbar item containers or icon loaders. Thus everything in the frontends/ subdirectory should be able to be left out of a batch processing or command-line LyX.

As you can see I'd like to get absolutely everything frontend-related into the frontends/ subdirectory. I see no good reason why LyXView or LyXGui for example should be in src/. Perhaps a src/backends/ subdirectory might be appropriate but I'd rather see frontends/support/ used for that purpose or a subdirectory of frontends/ instead.

1.1 Elements expected to be found in all GUI frontends


(required) This is the actual buffer view and editting area.


with several levels of menu entries.


A button array (Toolbar) to insert buttons, comboboxes,


A small edit line.


Used to navigate the document inside the workarea. Both horizontal and vertical are preferable but at least a vertical scrollbar must exist.


(a.k.a. popups) Preferably with tabbed dialog capabilities.

1.2 A quick overview by Asger

We have a LyXView class, which corresponds to the main window or frame. This LyXView class hosts a menu-bar, a toolbar, a minibuffer and several BufferViews. We can have several instances of the LyXView class to signify several open windows. Each LyXView also has its own complete set of dialogs which are shared between each of the BufferViews to avoid screen clutter and user confusion.

The BufferView is a display of a buffer. It is associated with a specific buffer, and is supposed to be general enough to be incorporated in practically anything: i.e. inside a LyXView, but also inside a Dialog. For instance, in the future we'd like to have a mini-BufferView in the Find/Replace dialog, where the user can search for formatting and all other kinds of stuff, just by typing a mini-document into a BufferView. The BufferView hosts a visible cursor. Behind the scenes, it also hosts a Painter. This Painter is an abstract class which implements drawing of the document. Have a look at the interface of the PainterBase. Each port should implement this interface. At the moment we have the X11 painter in Painter.C and Painter.h. This painter is specific to XForms at the moment, so it should probably be renamed to XFormsPainter.C. Anyway, the painter interface is pretty fixed, so a start would be to implement the painter for the Mac.

The BufferView uses a LyXScreen class to hold a cached pixmap of the work-area display. This LyXScreen class should be rewritten to be GUI-independent. This job includes adding a "copyFromPainter" method to the Painter, which will allow copying a rectangle from one painter to another. When that is implemented, the LyXScreen class will be GUI independent. The LyXScreen class also handles the displaying of the cursor.

1.3 Paper Organisation

There are two major areas of the user-interface: dialogs (or popups) and the main window (LyXView). Each of these areas of the GUI is described separately along with the current plan or options for achieving GUI independence for that area. This is followed by a section about the Painter which handles the rendering of the text and tables etc. on screen. A description of how to port LyX to another GUI toolkit using a multi-toolkit method is then described. There are a few concerns for specific GUI toolkits which are then covered before the credits are listed.

Next Previous Contents