[Kde-pim] Review Request 119461: Per attendee customization of email [3] - Add paramenter to ensure the composer to open

[Kevin Krammer]

> On Juli 25, 2014, 12:35 nachm., Kevin Krammer wrote:
> > I don't quite understand the description.
> > isn't that what the "hidden" argument is for?
> 
> Sandro Knauß wrote:
>     Nope the hidden argument is the opposit:
>     hidden == true -> the compose won't be open (automatic sending)
>     hidden == false -> the default value is used ( either MessageViewer::GlobalSettings::self()->automaticSending() or esspecially for itip invations will be always handled automatically) 
>     allowDefaultSend == true (like before)
>     allowDefaultSend == false  && hidden == false -> the composer window is open independently from MessageViewer::GlobalSettings::self()->automaticSending()
> 
> Kevin Krammer wrote:
>     Hmm, I am guessing here, but maybe this weird handling of "hidden" is a left over from times when applications could not send messages themselves but had to go through KMail?
>     I mean, if I call a method called openComposer, explicitly tell it not to be hidden, then I expect the message composer window to show. Anything else is not what the API says it does.
>     What is the use case of hidden == false if it is ignored?
> 
> Sandro Knauß wrote:
>     Well yes if i look into the comment for automaticSending "Get Automatic invitation sending" it really sounds like this is part from the old times :)
>     Actually the function isn't specific for creating invatations emails, so it should not depend on this...
>     I would say remove MessageViewer::GlobalSettings::self()->automaticSending() and show composer in anycase if hide != true, but this would change the behaviour of an dbus function...
> 
> Kevin Krammer wrote:
>     Right. This is Laurent's call. If he wants to keep the current behavior then I would suggest that the new method does not add yet another argument but instead removes "hidden" and always shows the composer
> 
> Laurent Montel wrote:
>     Change dbus interface function is not a good idea.
>     I prefere not change it. I don't know who uses it and I don't want to break it.

Ok. In this case, as suggested above, we might as well make a new method that works as expected, i.e. opens the composer.


- Kevin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119461/#review63139
-----------------------------------------------------------


On Aug. 7, 2014, 12:52 nachm., Sandro Knauß wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119461/
> -----------------------------------------------------------
> 
> (Updated Aug. 7, 2014, 12:52 nachm.)
> 
> 
> Review request for KDEPIM.
> 
> 
> Repository: kdepim
> 
> 
> Description
> -------
> 
> The actual openComposer method dosen't open an dialog if it is a itip invitation or the user wants automatic sending. 
> But for actually get individual mails for event attendees, we must to make sure that the composer is openend.
> + small bugfix setParameter( QLatin1String(attachParamAttr), attachParamValue ) has to be set to contentType and not to contentDisposition
> 
> 
> Diffs
> -----
> 
>   kmail/kmkernel.h bdad69fadfe1fdd0a7b3734b74673c34d5208977 
>   kmail/kmkernel.cpp f4cb34120c7273158d544a1ee3fa23a02ed815c3 
> 
> Diff: https://git.reviewboard.kde.org/r/119461/diff/
> 
> 
> Testing
> -------
> 
> sent some invations around to make sure they are corret.
> 
> 
> Thanks,
> 
> Sandro Knauß
> 
>

_______________________________________________
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/