Next Previous Contents

3. Frames

We will be supporting multiple main windows or LyXViews in all future LyX versions. The GUI specific code for implementing a LyXView is hidden by the Frame class. It is similar to the Popups class used for dialogs but it has a few differences. We should be able to handle all the mouse and keyboard events with the GUI backend and not have to pass them through to the rest of LyX -- except in a processed form. Most of these events involve some form of cursor movement, selection, deletion or insertion. The GUI backend for Frame includes LyXView, BufferView, LyXScreen and ToolbarBackend among others.

Frame Overview

3.1 Communications

Some of the toolbars may need to use the get methods of the Communicator class. The combined character and paragraph toolbar is the main one I'm thinking of here. It needs to update its state everytime the cursor moves so should be connected to the updateCharacterPos signal from Popups (not yet implemented) or have its own equivalent in the Frame class. Then the current settings would need to retrieved using the Communicator get methods and the toggle button states set. When a user operates the bold toggle button for instance the Communicator method isn't needed because the bold LyXFunc is used instead (this is as a result of JMarc and Asger's toolbar design).

Any events that need to be passed outside the GUI (frontend or backend) should probably do so via a FrameEvents class. Other operations should be done via a FrameComms class. The few methods from Communicator that are likely to be used by toolbars could be duplicated in FrameComms instead.

Rather than pass events from the GUI I'd rather see, if possible, the backend process a selection for example and then pass via FrameComms a selection consisting of two BufferIterators.

3.2 Custom toolbars

We can define customisable toolbars supported by all toolkits with a generic toolbar definition but it isn't necessary for LyX to know anything other than a signal interface. The backend provides the ToolbarItem class JMarc and Asger have been developing. The frontend implements the drawing of these toolbars. The frontends should also be allowed to use the desktop-provided icons if there are any appropriate ones -- such as those provided by KDE or Gnome for example.

We can display one toolbar at a time and allow the user to flip through them to get to a different toolbar by using toolbar-next or toolbar-prev for example. If we have a few standard names like MATH or TABLE for example we could provide context sensitive toolbars via a very simple signal interface (the same style of interface used in Popups).

If you want to get fancier and allow a user to have multiple toolbars visible at once then we could modify the signal interface. The most I can see being necessary is one fixed toolbar the user can select from a list, and a second toolbar that changes automatically in a context-sensitive manner. The second toolbar should of course check what type the first toolbar is so that we don't have two identical toolbars. This of course means that the default toolbar definitions must have names and that for a user to get correct context-sensitive behaviour they have to use those names also (or we provide a mechanism to map user toolbar names to contexts).

An example of the sorts of signals needed are shown below:


enum ToolbarFlip {PREV, CURRENT, NEXT}; 
enum ContextSensitiveToolbar {TABLE, CHARACTER, PARAGRAPH};
...
Signal1<const ToolbarFlip &> showFixedToolbar;
Signal1<const LString &> showCustomToolbar;
Signal1<const ContextSensitiveToolbar &> showCustomToolbar;
 

Thus we have two ways of allowing the LyX core to decide which context sensitive toolbar to display. The single method of flipping through the fixed toolbar isn't as restrictive as you might think. The toolbars could have a button that offers a menu of toolbar choices. This could be by way of a menu or a scheme like that used by Blender (hold the left mouse button down and move the mouse up or right to advance through toolbar options, middle mouse gives previous toolbar, right mouse next toolbar. The toolbar button's icon changes to reflect which toolbar will be shown when the mouse button is released).

3.3 BufferViews

How many BufferViews can fit into a LyXView and still be usable? This would depend on the font sizes and the screen resolution. Should we hardcode a limit? If we don't what happens when some loony decides to try and open ten or twenty BufferViews? We need some sort of limit and ideally we need to calculate it at runtime using a formula like:


max_BufferViews = LyXView_height / min_BufferView_height
 

Of course everytime the user resized LyX we'd have to recalculate this value and drop some of the BufferViews if need be. I'm inclined to set a hard limit of four BufferViews per LyXView with some sort of dynamic resizing adjustment thrown in.

The other thing with BufferViews is that if multiple BufferViews are showing the same document, updates in one should be reflected in the other. This should happen irrespective of which LyXView the two buffers are shown in. Signals should be able to help us out here -- a Buffer can provide a bufferModified signal that each BufferView showing that buffer connects its update method to. Thus we'd end up with a slightly different way of modifying buffers to what we have now: a buffer is modified by whatever means and whichever BufferViews are showing this buffer must take appropriate action to ensure their display is up-to-date. The function doing the modification, possibly within LyXFunc, doesn't force the update explicitly that is handled by the buffer's signal.

3.4 LyXView

So each LyXView would then have: a Frame with at most two visible customisable ToolBars (one context sensitive the other chosen by the user) and at most four BufferViews (with their own scrollbars) (and status bar?) and one menu and one set of popups in the Popups class *all* of which utilise signals in a manner similar to that already in use in the Popups class. The toolbar, menu and bufferview signals being accessed via the Frame class.


Next Previous Contents