[Kde-pim] Project: Active Mail

[Abhijeet Nikam]

Thanks a lot, Thomas and Kevin for your much needed guidance.

I too have spotted some errors in the anchors of tool-bar layout  and
I think I can fix them. But when I  build only mail in the mobile by
opening: mail -> CMakeLists.txt in QtCreator, and run it (compile it),
I am getting this error:

Akonadi/Item no such file or declarativeakonadiitem.h directory.


I am definitely missing some links to the required libraries or
something else. Can someone please help me rectify this so that I can
start working on the patch?

Thanks and regards,
Abhijeet

On Wed, Mar 5, 2014 at 3:47 AM, Thomas Pfeiffer <colomar at autistici.org> wrote:
> 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/
_______________________________________________
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/