Re: Patch: Bug 50278

[Havoc Pennington <hp redhat com>]

Sven Neumann <sven gimp org> writes: 
> I guess I should have said this earlier, but I really wonder what
> benefits this API change is supposed to bring. GtkSpinButtons are 
> views on the GtkAdjustment model and I think this a very nice 
> concept that should stay and that should be exposed through the 
> API. GTK+-2.0 finally introduces a clean model-view concept for 
> trees. Why drop it for spinbuttons? IMHO the API enhancements you
> propose are neither convenient nor do they enhance GTK+ in any 
> way.
> 

In 99% of spinbutton uses, the model/view separation is just
inconvenient cruft, because the user already has their own model/view
split, and the spinbutton is just a view. So creating an additional
model/view layer by adding the adjustment model is not useful.

MVC is cool and all but it can definitely be overdone. A label widget
has no reason to be model/view, or if it is, certainly you should be
able to use it without having to know that.

Model/view as the basic mode of operation for a tree is very important
because keeping two trees in sync if you have to "stuff" data into
them is both nearly impossible and really inconvenient. This isn't
true for the spin button, where "stuffing" data involves setting one
floating point number.

Note that model/view can mean different things even in cases where we
have it, e.g. for the tree you can write a custom model so the
model/view split is to allow pluggable models, for the text widget
model/view is only a device to allow multiple views, you must use the
GtkTextBuffer model and can't plug your own.

"MVC is a useful pattern" doesn't mean that all designs must be
model/view; eventually you have objects that are just views or just
models. ;-) The spin button is normally used as just a view.

Havoc