Architecture Overview
From Yzis Wiki
Contents |
Source code tree
Here's a brief description of Yzis source tree :
yzis |-- apidoc # generated by doxygen, html API documentation |-- build # this directory is used to store compiled file. |-- cmake # files used by cmake |-- debian # files used for debian packaging |-- doc # doxygen files for generic documentation |-- kpart_yzis # KDE KPart component |-- kyzis # This is a very basic kde application meant to test the kpart |-- libyzis # Yzis core, static lib shared by all clients |-- libyzisrunner # This is a gui less yzis used for tests |-- nyzis # ncurses client |-- qyzis # Qt only client |-- scripts # (lua) scripts installed with yzis |-- syntax # syntax highlighting scripts |-- tests # unit testing framework \-- translations # translations files
So, code-wise, you basically have a common core, found in the dir libyzis, which is a static library. It contains all GUI independent code. Then, each front end has its own directory, with the GUI dependent code, which links against libyzis to create the executable.
As of december 2008, the purpose is to first make the ncurses client and the Qt only client available, then the KDE client and embeddable component, and then others.
Which part handles what ?
The libyzis core handles files (loading/modifying/saving), commands interpretation, scripts interpretation (lua, highlighting), and lot of common stuff for rendering. It has some abstract classes about GUI, which provide APIs and basic stuff. Most often client will inherit those classes. It also contains some generic code (debug).
An important point is the event loop handling. The client is responsible for handling the event loop. The client (translates and) sends events to libyzis which will possibly call some GUI dependant code to render some modification, and then returns to the GUI loop handling..
Core classes
We describe here the few most important classes in Yzis, and how they interact.
YBuffer
Being a file editor, Yzis code is centered around a class handling files. They are either empty file (like when you start "nyzis"), or a file on the filesystem ("nyzis foo.c"). This class is responsible for loading, saving, and modifying the file (YBuffer::insertChar() for example). It keeps track of all views on this file, if the file is modified or not, filesystem names, and so on.
Link to the YBuffer API documentation
YSession
A session is basically a client application instance, from the core point of view. A session can have one or more files opened, and one or more views, or "windows" opened. The session is responsible for creating and handling both views and buffers (see YSession::createView(), YSession::createBufferAndView(), YSession::createBuffer() ).
Link to the YSession API documentation
YView
A view is a GUI component displaying part of a file, within a session. As such, it depends on both: the constructor needs both a YSession and a YBuffer. This is the class where rendering is done, closely with the core.
Link to the YView API documentation
Data paths
In this section, we describe the paths followed by the data (file, keyboard) within Yzis architecture.
During initialisation of the program, an instance of YSession is created (or a subclass, most probably). This instance is unique, and is always present. Most of high level API is here (like creating/deleting other important objects). For example, if you want to open a file, and create an associated view, you can use:
session->createBufferAndView( myname );
At any given time, the session has a 'current view', which is the one receiving user input. For example in nyzis, if you haven't use the split feature, there's only one view displayed at any time, even if several files are opened. This is the current view. In Qyzis or Kyzis, on the other way, several views are displayed, but only one window has the focus: this is the current view from YSession's point of view.
The client handles the event loop. When a key event is received, it is sent to the libyzis core using the current view. For example in nyzis/nsession.cpp we can read:
currentView()->sendKey( QString( QChar( c ) ), modifiers ); currentView()->sendKey( "<CTRL>]" );
The core does all what is needed: store the character in appropriate buffer, update all views for this buffer, if the character is enter, then some action might be taken, such as executing a command or whatever, depending on the current mode.
Yzis core uses the API to call the upper GUI layer to display. (details are in section rendering).
Closing buffers and views
Vim has the notion of unseen buffer. If you quit with unseen buffer, you are prompted if you want to see them. Buffer are only seen with :next and :prev
With unnamed modified buffer, when you quit you are prompted to save the changes.
When the last view closes, you are prompted to save changes to all unmodified buffers.
If you delete a buffer with more than one view on it, and there are other buffer left, all views on the buffer are closed but one, and the one view is set an another buffer.
