Brian Hulley wrote:
Thinking about this a bit more, and just so this thought is recorded for posterity (!) and for the benefit of anyone now or in a few hundred years time, trying to solve "Fermat's last GUI", the object oriented solution allows the buffer object to do anything it wants, so that it could negotiate a network connection and implement the interface based on a shared network buffer for example, without needing any changes to the client code above, so a functional gui would need to have the same flexibility to compete with the OO solution.
Probably it would be parametric in the input mechanism, somehow. (A Haskell approach might use type classes, slightly obscuring the parametricity..)
Another thing that would be interesting would be to have a formal treatment of what is supposed to happen in a gui. For example, when you move the mouse over a control which has become dirty (ie needs to be re-rendered because its state is now inconsistent), what should the control do? Should it respond as if the new state were already visible to the user, or should it interpret the mouse position according to the last state that was rendered, or should it just ignore all mouse events until the next time it gets rendered? This is not a trivial question because you could imagine an animated control where the user might naturally be following the movement, whereas when the user clicks on a cell in a spreadsheet when the cells to the left have now expanded due to a change in data thus moving the cell along (but where this updated model has not yet been re-rendered) the user might be irritated at the wrong cell being selected... It's tricky little issues like this that I haven't found any documentation for anywhere, and which would make a proper mathematical treatment of interaction with a gui very useful, regardless of whether it is implemented in OOP or functional style.
Jef Raskin (late interface designer, author of _The Humane Interface_) would probably say that anything with such importance to user decisions, should be rendered within a tenth of a second. Computers fifteen years ago could sometimes do it! Fancy details can be filled in later if it takes that long.
Of course that completely dodges the mathematical question... in which human response time should really be taken into account too! Humans really are not like machines and are not all alike either! Oh no, do we need psychological formalisms?
Firefox suffers the above problems badly, alas - the "Stop" button is half useless because it doesn't even noticed you pressed it for such a long time, etc...
Reading up on user interface design principles as well as thinking functionally, is probably a useful approach - although not everything that you read will agree or be right. The whole concept of GUIs - they are very complicated - it is quite arguable that they are just a wrong interface - however, some of the world's people are fortunate enough to be accustomed to them already, which complicates matters considerably.
Isaac _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
