[Kde-pim] Project: Active Mail

[Thomas Pfeiffer]

On Tuesday 04 March 2014 21:34:26 Abhijeet Nikam wrote:
> Hi Mike,
> 
> The email composer API's are presently written in QT/C++. So do we
> need to re-write the API's in QML or QT/C++ keeping the present one as
> reference? What I have understood is we have to write the API's in
> Qt-quick (QML) to enhance the functionality and include new features
> so that it is suitable for the touch interface.
> 
> I searched a lot, I found some QML related mail clients too. I am also
> presently going through the way an email works and its functionality,
> protocols to get a better understanding.
> 
> But I really need some help regarding the composer API. I am not
> really clear about it. Could you please answer some of my questions or
> give me a references or sources to go through to start with?
> 
> 1. What is expected in the API? Where should I give a basic start for it?
> 2. For the composer : Do we need to completely write the source code
> for sending the mail, support for the MIME standard and other
> protocols in mails, HTML and plain mail support, converting HTML to
> plain text, including the emoticons support plus other things with the
>  basic features as attachments, cc, bcc etc?
> 
> 3. Will we be using the existing libraries and features in kdepim
> present like the message composer, message viewer etc for the composer
> API or creating our own ones?
> 
> 4. The existing composer looks filled with lots functionalities,will
> it involve recreating them in the new composer which we aim to create?
> And could you give me a rough basic idea or blueprint how you aim or
> expect the modules for the API to be develpoed?

For Mike's GSoC last year, we wrote a requirements document which can be found 
here: http://community.kde.org/Plasma/Active/mail
It contains requirements and user actions for all of KMail Active, so for you 
only the requirements and usecases that have to do with composing and sending 
email are  relevant.
The user actions are categorized by assumed frequency, this is relevant for 
deciding how easy they should be to access / how prominently they should be 
integrated into the UI.
For the requirements, Core (C) features are must-haves, Performance (P) 
features should be there at some point (not necessarily in the first release), 
Buzz (Z) features are cool, but should only be implemented after the C and P 
features are done, and exotic (E) features probably don't need to be 
implemented at all.

I hope this list helps to communicate what we think the Composer should be 
able to do.

Cheers,
Thomas
_______________________________________________
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/