[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Notifications on KMail
From:       Ingo =?utf-8?q?Kl=C3=B6cker?= <kloecker () kde ! org>
Date:       2010-07-15 17:56:43
Message-ID: 201007151956.48836 () thufir ! ingo-kloecker ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 14 July 2010, Artur Souza (MoRpHeUz) wrote:
> 2010/7/14 Ingo Klöcker <kloecker@kde.org>:
> > 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.
> 
> +1 for your solution on this use case!
> 
> > 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.
> 
> I think that now I understood the reason behind your suggestion,
> thanks for the explanation! For the use cases that you pointed out I
> agree that callbacks make more sense.
> 
> However, I was talking about just the "failed()" and "success()"
> signals that are already used everywhere in the composer window for
> example. This signals are mainly for reporting and usually just
> connected to one slot each.

Ah. Okay.


> I agree that when you need any kind of input from the user it's way
> better to use the callback mechanism that you just explained. At
> first I was just doing a comparison between the way that the
> failed() and success() signals are treated in the UI (KMessageBox vs
> KNotify) and tried to show the scenarios where one or another were
> already used.
> 
> Do you think that for this specific use case of reporting what
> happened (fail/success) we still need the callback? As there is no
> user interaction (it's just a mechanism to allow the user to know
> what happened) I tend to think that just KNotify would be good
> enough for the job and for more complex scenarios (like asking which
> OpenGPG key the user wants to use) we could go with the callback
> mechanism.

I'm not opposed to using signals for the simple cases, but please keep 
in mind that using two different mechanisms (signal/slot for simple 
things and a callback interface for the more complex things) will make 
the code more complex.


Regards,
Ingo

["signature.asc" (application/pgp-signature)]

_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[prev in list] [next in list] [prev in thread] [next in thread]