Refactoring for 0.8.0 release
=============================

On Monday, 23 November we (Rickard and Roger) discussed how to refactor the
code for the 0.8.0 release. Here is a summary.

The purpose of these refactorings are to make the code easier to understand and
to enable us to more easily implement new features.

Event
-----

We want to clarify the responsibilities of the Event class: It should only
store event information that is stored in a file. Things such as if an event is
selected or not should therefore not be stored in this class.

Event runtime data
------------------

We need a new class to hold information about "runtime data" of events: such as
which events are selected and for which events to draw balloons.

We want to be able to query this object something like this:

    event_runtime_info.get_event_selected(an_event)
    event_runtime_info.set_event_selected(an_event, True/False)

It should be the responsibility of the view (the object that draws the
timeline) to keep an `event_runtime_info` object. This different views can have
different runtime information about events.

In order to be able to associate events with runtime data each `Event` object
must provide an `id` attribute that uniquely identifies that piece of event
data. We must do this since we don't want to rely on that a `Timeline` object
always return the same `Event` object for the same event data.

Drawing algorithm
-----------------

A better name for these set of classes might be `Drawer` and `DefaultDrawer`.
Or perhaps `Painter`. The idea being that the drawing object is seen as a
person that does the actual drawing.

We want to do the following changes to the `draw` method interface:

  * `event` changes to `timeline`: The drawer will thus be responsible itself
    for getting the events. This is useful if the drawer wishes to draw events
    not present within `time_period`.
  * Add `event_runtime_data` parameter.
  * `period_selection`, `legend`, `divider_line_slider` are put in a separate
    object called `DrawingSettings` or similar. Different drawers can query
    this object in different ways. The querying should work something like
    this: `drawing_settings.show_legend()`.
  * The `divider_line_slider` should also be changed from a GUI component to a
    number between 0 and 1.

So the new interface will look like this:

    def draw(self, dc, time_period, timeline, settings, event_runtime_data)

We could not agree whether to put time_period inside settings or not.

Furthermore, the `notify_events` method seems misplaced.

A new timeline view
-------------------

To help see how we should refactor the interfaces we decided to create a new
GUI component that shows a different view of the timeline (using a different
drawer).

The view might now be used in the release, but its main purpose is to verify
that our abstractions are working.

The view we discussed was a view that shows the whole timeline with bars
indicating just how many events are in a certain period. A red box shows which
period is currently displayed in the standard timeline view. Maybe you should
also be able to scroll the default view by dragging the red box.

Summary
-------

The following things should be done (in these steps maybe):

  * Add `id` attributes to events
  * Create a class that manages event runtime data
  * Create a class that hold drawing settings
  * TODO: plan for the rest
