[Konsole-devel] KDE 4 - Refactoring the Konsole user interface

[Robert Knight]

Hello,

Something I would like to do for KDE 4 is to revisit the structure of
Konsole's front-end as this will make it much easier to implement many
of the feature requests, fix some long standing gripes and make the
embedded Konsole part more useful.
This post discusses the problems with the current evolution of the
Konsole front-end code, a proposal for a new structure and details on
work that has already been done.
Feedback would be greatly appreciated.

The user-interface code for Konsole is placed almost entirely in one
class, the "Konsole" class.  This has obvious consequences.  The
Konsole class has become very large ( > 4000 lines for the
implementation ) and performs many unrelated tasks, including:

- Creating and managing running sessions
- Creating and managing terminal displays
- Provides the menus to manipulate the display container (ie. the tab
bar) and executes the changes
- Creating the bookmark menu
- Applying settings changes in colour schemes, keyboard layouts,
fonts, system notifications to active terminal sessions
- Loading and applying global settings
- Loading the menus for colour schemes, keyboard layouts, fonts,
system notifications
- Provides the context menu for terminal displays and executes the
actions the user chooses from them.
- Creates histories and executes searches through the history

The result of all this is unwieldy code which lends itself to hacks
and is already pretty complicated to manage.  There are a number of
wishlist items on bugs.kde.org which relate to making it easier to
work with many open sessions.  More flexible handling of views is a
prerequisite to implementing these wishes.  Another disadvantage of
the code in the Konsole class is that the provided features are not
available in the embedded Konsole part or the code for them has to be
duplicated in the Konsole part.

To deal with this, I propose refactoring the UI into more of a
model-view-controller setup.  I have already done some work of this in
the separate konsole-split-view branch, but I would like to see the
opinions of others before I continue development and merge back into
trunk:

- Creation and management of running sessions will be done using a new
singleton class called SessionManager.  It is responsible for:
   - Discovering the available session types, and exposing that
information as a list of SessionInfo objects
   - Creating new sessions and owning the TESession instances which are created
   - Performing any cleanup operations when the session exits

- Creation and management of the widget which holds the terminal
displays will be done by classes inheriting from a new ViewContainer
class.  ViewContainer provides functionality which is common to all
types of contains for multiple displays.  The ViewContainer also
provides the menus for manipulating the current view.  That is, the
"View" menu in the Konsole user interface.

- The "Edit" menu in Konsole and the context menu which is shown when
right-clicking on the terminal display, will be moved into a new
SessionController class.  This class is also responsible for
manipulating the session to change the display size, monitoring modes,
changing the character encoding and keyboard layout.
The settings menu items which relate to the active session could
either be put in the SessionController class or

The edit menu currently contains one menu item ( Clear All Histories )
which relates to more than one session.  Users have also requested a
"Save All History" option.  I am not sure how best to handle this.
Suggestions welcomed.

- The ViewContainer needs to know certain information about the view
which it is displaying, such as title, icon etc.  Rather than exposing
the entire interface of the terminal display (TEWidget) to the
ViewContainer, I think a much more limited interface ( TerminalView
perhaps ) could be created from which the actual display widget (
TEWidget ) would inherit.

- The colour schemes and fonts used are a property of the view, and I
think the object representing the terminal session should no nothing
about them.

Ultimately I would like to slim down the Konsole class so that it
performs two basic functions:

- Containing views
- Providing the basic menu layout and a place to plug in session and
view specific menu entries.

The application initialisation code which is in main.cpp could then be
moved into its own class ( KonsoleApp ), although that will probably
be done as the last step and can be done after merging with trunk.

So far, the following has been done:

- ViewContainer class
- ViewSplitter class
- SessionManager class is work-in-progress
- SessionInfo class ( which provides access to a description of a
session for use elsewhere in the UI )
- Modifications to the backend to allow addition and removal of an
arbitrary number of views

The work as it progresses can be found in
branches/work/konsole-split-view in KDE's Subversion repository.
Merging with trunk would be done once the new structure is in place
and Konsole is stable enough for basic use.

Regards,
Robert.