herbert.thoma at iis.fraunhofer.de
Sat Feb 16 08:06:48 EST 2013
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
> John Ralls
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel