[Kde-pim] Kontact Touch GSOC Project - mentor needed

[Volker Krause]

On Thursday 11 April 2013 15:30:51 Kevin Krammer wrote:
> On Thursday, 2013-04-11, Michael Bohlender wrote:
> > Just "ok" is not good enough for me. So lets see what I can improve.
> > Is the project idea itself not exciting enough for you or is this just
> > about the technical approach?
> 
> It is a bit thin on scope and implementation details.
> E.g. does this include folder specific settings UI, composer, attachment
> handling, address book integration/recipient editor, filter/search UI, etc.
> 
> Maybe list a couple of example workflows that should be possible with the
> improved UI.
> 
> > > That will most likely only work for rough prototyping, learning to use
> > > Plasma
> > > Components and so on,
> > 
> > I did some minor things for PA with PlasmaComponets already and feel
> > relatively comfortable using it.
> > The reason I suggested this approach is, that it allows me to got through
> > a
> > lot of design ideas with my Co Mentor.
> 
> Right, I agree with that.
> 
> > Otherwise testing if the UI works on Tablet will be hard and I have no
> > Idea
> > how to compile stuff for my ARM based Nexus 7.
> > Waiting for our merproject build servers to compile stuff would also be
> > quiet time consuming.
> 
> I would expect that Plasma UI does also work on the desktop or inside a
> viewer application. AFAIK it is possible to build and run Kontact touch
> like its normal version, just using QtQuick as the UI layer.
> 
> > I consider the UX design/rework the main part of my project and like to
> > experiment a lot during the mockup phase.
> 
> Would it then not be better to have someone from PA be the primary mentor
> for this?
> 
> > > E.g. standard Qt Quick (no idea about Plasma Components) is seriously
> > > limited
> > > when it comes to usage of Qt item models (no support for table models,
> > > yet alone tree models), so often extra effort is needed to overcome
> > > those.
> > 
> > I asked on active at kde.org a while ago and was told that this approach is
> > used "fairly often" in plasma active.
> > But maybe I got it wrong or this just does not work well for KDE PIM
> > related things?
> > If someone suggests a more sensible approach I have no problem with
> > adapting it.
> 
> I am just worried that we will end up with lots of QML files that work
> really well on demo data but do not fit onto the actual data objects, etc.

Indeed a risk, but OTOH asking for a full rewrite of a mail application UI 
within a single GSOC is asking for a bit much as well ;)

Kontact Touch was started when QML was still in its beginnings (Qt 4.6), and 
with the objective to be feature equivalent to the real Kontact (on an N900-
like phone), which explains some of the "interesting" solutions you find in 
there, especially all the embedded widgets.

Redoing the UI entirely in QML would mean:
- heavily compromise on features, at least for the first iteration during GSoC
- reuse the existing models from Kontact Touch for the message and folder 
lists
- refactor the remaining required bits of widget based code for model/view 
separation. IIRC this will mainly affect the composer, which is still an 
embedded widget.

The first two seem implicitly already present in the proposal, the last one 
might be a bit underestimated.

Considering the implementation, it sounds it might be easier to start from 
scratch and just take some inspiration from the C++ integration from the old 
Kontact Touch, the required code on the C++ side is largely shared with 
desktop KMail and thus in libraries in kdepim already (apart from some of the 
adapter models maybe, but these should be easy enough to move as well). 
Otherwise you might spend quite some time fighting against widgets creeping 
into the application again.

Also adding Björn Balazs to Cc, he did the original UX design of Kontact 
Touch.

regards,
Volker
-------------- 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/active/attachments/20130412/2318c768/attachment.sig>