Experimentally start refactoring code into view/controller pairs for more modularity.

I'm particularly intrigued by the idea of using this to support partial
testing of the GUI components.  Even if that doesn't work, I think that
explicitly separating the code that twiddles the GUI from the underlying
program logic makes things a bit readable, although I am a bit worried
about the proliferation of tiny little classes that this could lead to.

The new scheme includes three new directories:

gtk/views/ -- holds interfaces that provide abstracted access to
              parts of the GUI.
gtk/view-impls/ -- holds implementations of interfaces from
                   gtk/views/.
gtk/controllers/ -- holds logic to drive views for various purposes.

The first view/impl/controller set is a refactoring of the search-entry
code.  Another thing that concerns me: it's not clear that there are
actually very many places in the existing code-base that can be
cleanly refactored to fit this mold.

The new search controller/view classes drop support for incremental
searches.  This is deliberate; I see two major problems with the
existing code.

  First, it requires an extra button in the UI to enable or disable it.
That bothers me; if incremental search is worthwhile, it should be
enabled all the time, at least by default (IMO).  Second, the existing
code was really ugly, partly because of the way the code used to be
designed (before searches ran in the background).  It should be
reimplemented from scratch anyway.

0 files changed, 0 insertions, 0 deletions