I am looking for a way to solve the "controller problem". Actually I really would like to solve that based on gut feelings but as this is an academical audience I thought we might as well have on of those mock-up arguments we all enjoy.
So: The "controller problem" as defined by me is "having to wait for compiling stuff that I consider useless." Part of the "controller problem" is also that our controllers are more or less _only_ an interface between core and dialog. When one browses a bit at http://en.wikipedia.org/wiki/Model-view-controller there are two observations to be made: (1) "Controller: Processes and responds to events, typically user actions, and may invoke changes on the model." Alternative definition _all_ mention that "input" aspect. Note: _Our_ "controllers" are _not_ handling input. At all. Input is handled in the views, and in the core. _Not_ in the dialog related controllers (I am not talking about the ButtonController which might be the only real controller after all.) (2) Only a few (one?) frameworks explicitly mention controller _classes_, for the rest the "controller" is a concept which is implemented in various places. The closest ting to what we think we have is Apple's definition on http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/WhatAreBindings.html#//apple_ref/doc/uid/20002372-175802. Even this does not match our implementation very well as the "binding" of data in the actual UI (e.g. in a combobox) to the data in the model (say the unit of the width of a figure) is done in e.g. GuiWrapDialog to an intermediate format which in turn is translated by ControlWrap plus InsetWrapMailer to the actual core data. Note also that out implementation actually _fits_ in the Apple scheme by simply refering to GuiWrapDialog as WrapController. Now suddenly it sort of makes sense: The view is the generated stuff from the ui file. GuiWrapDialog _is_ the controller binding the content of ui elements to core data. It also fits into the "controller receive and handle input" as the current dialogs (and soon-to-be controllers) _do_ receive inputs (have an "event()" methid for instance) and even handle them. Now with the current Gui*Dialog being the controllers, what is the current controllers/Control* ? Right. An intermediate layer of cruft. Together with the mailers actually two intermediate layers of cruft. In MVC there's no layer between controller and model, is there? And it is not "just" cruft, it is the finest cruft we ever had: >From the "some numbers" mail a few days ago we know that LyX has an abysmal high noise/contents ratio of roughly 110 lines of compiled code per line of our code. I.e. for each line _we_ implemented, the compiler currently compiles 109 lines of included stuff. (22.5mio/200.000, down from 24.something mio) For controllers/* we have 2.03 mio compiled lines for 8.600 lines of our code, i.e. a noise/signal ratio of - fasten seatbelts - 236. I want to do _something_ about it. Merging ControlFoo into GuiFooDialog sounds like a sensible first step. Andre'
