janssens-geert at telenet.be
Sat Feb 16 08:25:21 EST 2013
On 16-02-13 14:06, Herbert Thoma wrote:
> forgot CC list ...
> Am 15.02.2013 21:06, schrieb John Ralls:
>>>> Why hard to say? MVC isn't exactly cutting-edge design. It's been
>>>> around since 1988 and 7 years later GoF thought it so well-understood
>>>> that it's the "how to use patterns" example in the introduction.
>>> Well, the point is that every time the user leaves a field you need to
>>> parse all the input fields and process them in the controller/model as
>>> part of the validation, even if the user hasn't asked to 'save' yet.
>>> I guess it all depends on your controller APIs. (In the RoR world this
>>> is harder to do, because the view is in the browser, but the model and
>>> controllers are on the server -- and there is no "verify this model" API
>>> in the controller. At least not directly. The client-side-validations
>>> gem adds some support for this).
>> We already do that for the account type listbox: We connect to a signal
>> (don't know offhand which one) in the parent accounts GtkTreeView that tells
>> us that the user has selected a parent account, retrieve that account, run
>> xaccAccountGetCompatibleTypes() on it, and populate the account type listbox
>> with the result.
>> That's a pretty standard way for UI View objects to communicate with their
>> controller objects, though there are others. Wx has a specific "Validator"
>> class that lets you register a callback to test control input as it happens.
>> It also has a signals mechanism (which they rather confusingly call Events)
>> to support other interactivity needs. Qt is well-known for its "signals and slots"
>> feature, which I imagine is used for this purpose much like Gtk's signals are, but
>> I've never written anything for Qt so I don't actually know.
> Yes, you can use signals and slots this way. I personally like Qt very much. For me
> it is the best GUI toolkit I have ever worked with (I worked with Motif, MFC,
> GTK and Qt, but always only small projects or patches to GnuCash).
> However, I would still be hesitant to use signals and slots in the engine. Earlier
> in this thread it was stated that the engine depends heavily on Glib and that this
> is bad for portability. Do we want to replace the Glib dependency with a Qt
I have been silently following this thread and made the same reservation
from the beginning for myself.
I don't have much experience with how this is done in general. It seems
to me though that's a matter of defining the API's well.
The GUI is supposed to know if some fields have to be validated. There's
no way around this. But the GUI code doesn't have to know what the
validation entails exactly. The core engine on the other hand does know
exactly what is allowed for a given object and what isn't. The key is
that the core engine should make some functions available for testing
this, returning in the most simple case a yes/no reply (value is valid
for object or not). In a more advanced set up it can also return a
message that can be displayed to the user to explain why the input isn't
These functions are part of the core engine API and don't need to use
any GUI framework related toolkit (like Qt, Glib, Gtk, WxWidgets stuff).
We could keep the signal and the slots both in the GUI code, with the
slots calling into the engine functions to do the real work.
Did I understand this correctly ?
More information about the gnucash-devel