[Kde-pim] Notifications on KMail

[Ingo Klöcker]

On Wednesday 14 July 2010, Artur Souza (MoRpHeUz) wrote:
> Hi Ingo!
> 
> 2010/7/14 Ingo Klöcker <kloecker at kde.org>:
> > I would prefer callbacks over signals because callbacks would also
> > allow the UI components to return something to the composer.
> 
> Why is that needed? If the UI component needs to return something to
> the composer couldn't the composer export what is needed and the UI
> would just deal with it?

Let's say the composer needs to ask the user which OpenPGP keys shall be 
used for encrypting the message. If there was a callback then the 
composer would simply call this callback. The UI component would then 
show the dialog and return the list of OpenPGP keys as return value of 
the callback. After the callback returns the composer can continue its 
work.

Sure, you could also use a signal with a pointer to some struct and let 
the receiver of the signal fill the struct as needed.


> > Alternatively, do it more C++-like and pass a NotificationInterface
> > (or UserInteractionInterface?) to the composer and write two
> > different implementations, one for KMail-mobile and one for KMail
> > desktop. This interface would provide all needed methods, e.g.
> > void showWarning( const QString& message ), AnswerType question(
> > const QString& question, const QString& button1, const QString&
> > button2 ), etc. Use a factory for the instantiation of the correct
> > implementation.
> 
> Ok, I *think* I technically understood your suggestion but I couldn't
> see the benefit over having the signal and letting the UI itself take
> care of how it wants to handle that information. I see that in the
> end it's the UI that is taking care of the situation in your
> suggestion too, but maybe that would imply in more imperative code
> on QML side (mobile) where it was supposed to be more declarative
> (and signals help on this matter) ?

The big problem of using signals is that you need to connect to a ton of 
signals (one signal per needed interaction). Of course, you could also 
create a single generic signal were you pass an id of the needed 
interaction and a void* which needs to be cast to the correct type by 
the receiver of the signal. But that's like super ugly.

With the interface you need at most one line of code which sets the 
interface. If a factory and some kind of registry is used then even this 
line of code will be superfluous because the composer will be able to 
get the interface from the registry if needed. This allows for very good 
modularization because the composer only needs to know the interface 
and, even more importantly, (and that's the huge difference to using 
signals), the UI components used by the composer do not need to know 
anything about the composer. All they need to know is that they can be 
called via some interface.

In the signal/slot scenario at least that component that connects the 
signals with the slots needs to know the provider of the signals and the 
provider of the slots.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100714/cd406d72/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/