| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
These never worked out as well as I intended, and all indications
were that they would be a maintenance burden...or just bitrot.
Fully parallel builds are nice, but my builds are pretty quick on
my 8-core box even with the artificial chokepoints that automake
induces.
|
|
As a side effect, this creates a "controllers" directory in the generic tree,
and removes the now-empty GTK+-specific controller and view directories.
The README files are moved over to the generic locations and tweaked to be
correct for their new home.
|
|
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.
|
