Architecture and code organisation

[quicklizard99]

inselect is currently a single python package but it really should be (at least) two:

1. logic for segmenting images;
2. a gui application that depends upon 1.

The current architecture means that when we come to segment images on servers (to be expected, when one considers mass-digitisation) we are forced to install a large GUI library - QT - an unnecessary dependency. Some work has done towards this by structuring most of the source files into the gui and lib directories.

[aliceh75]

Note that the split in gui and lib was not done to separate the segmenting logic from the GUI application, but to separate the GUI handling logic from the application logic. Much of the structure even in lib only make sense in the context of a GUI application.

For example the point of having a SegmentScene is so that components of the application (ie. GUI components) can get notified when a new segment is added. SegmentScene is in lib because in itself it doesn't use or manipulate GUI elements - yet it only makes sense in the context of a GUI application (A CLI version of inselect would not need this, as users wouldn't manipulate the segments).

The segmenting logic is actually already pretty much separate: the module lib/segment.py is where the segmenting is done, and it is pretty much stand alone - it could easily be replaced with an external executable that returns a JSON string without having to do much refactoring of inselect.

[quicklizard99]

As a result of closing #102 , inselect/lib no longer depends on QT