[Kde-pim] Project: Active Mail

[Kevin Krammer]

On Tuesday, 2014-03-04, 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?

The API itself will probably mostly be C++.

> 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.

The main goal is to be able to write all UI parts using a QML component set, 
e.g. QtQuick, Plasma Components, etc.

Features more suitable for touch interfaces would be a usage of said API.

> 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?

The current main composer is in kdepim/messagecomposer, but there might be 
declarative/QML specific stuff in kdepim/mobile/mail.
Michael might know more if he has had a look at that during his GSoC last 
year.

> 1. What is expected in the API? Where should I give a basic start for it?

A very basic composer UI needs to be able to get input for recipient, subject 
and actual message content, so a very basic composer API would need to be able 
to handle these information. Probably as a QML instantiatable type with 
respective properties.

A slighlty more advanced composer will probably want to be able to specify 
multiple recipients, maybe of different type (To, CC, BCC).

And so on.

> 2. For the composer : Do we need to completely write the source code
> for sending the mail

No, most of that is all handled by our libraries already.

> support for the MIME standard and other protocols in mails

We have libraries for that too :-)

> HTML and plain mail support

I would say yes. But this could potentially be a bit too much for a GSoC 
scope, at least the UI parts of it.

>converting HTML to plain text

No, if we can do that right now, we probably have code for that which can be 
reused.

> including the emoticons support plus other things with the
> basic features as attachments, cc, bcc etc?

Nut sure about emoticon support or the priority of it, but the other things 
here sound pretty much like we do want that.

> 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?

I would assume mostly reuse, but some of that code is rather old and might be 
difficult to break into suitably independent portions, in which case writing 
something new might be more viable.
Impossible to answer this generally.

> 4. The existing composer looks filled with lots functionalities,will
> it involve recreating them in the new composer which we aim to create?

Ideally, the long term goal should be to be able to implement a fully featured 
composer using the same code or sharing as much code as possible.

However, I don't think the full feature set is a reachable goal in the limited 
timeframe. 

A viable approach might be to see which usage we expect primarily from the 
Kontact Active (tablet) interface or what kind of things we would like to have 
their but currently can't.
Michael and Thomas will most likely have a couple of ideas in that regard.

> 5. How about also creating a basic small chat box for faster text exchanges?

I don't think that is necessarily something related or not closely enough. A 
chat UI and its underlying API are usually more "channel" oriented than 
message oriented. I.e. the channel determines the sender identity, in a lot of 
cases also the recipient(s), while a email composer is usually the source for 
both.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20140304/79cbe7b8/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/