[Kde-pim] GSOC Kontact Touch

[Anders Lund]

Tirsdag den 26. februar 2013 18:23:29 skrev Aaron J. Seigo:
> On Tuesday, February 26, 2013 17:12:43 Michael Bohlender wrote:
> > polish everything" so Kontact Touch seems to be a good candidate in my
> > eyes.
> 
> +1

+1

> > Now I am looking for a mentor and the right scope for my project. I want
> > to
> > do mostly UI work. Would porting things over to plasma-qml components  be
> > a
> > good project?
> 
> from the perspective of Plasma Active, yes :) at the very least, a number of
> the UI concepts in Kontact Touch are a bit dated and could use some
> updating.
> > I am not sure how much work that will be and if I can manage to port every
> > application of the suite in the given time. So maybe just focus on one or
> > two?
> 
> there is a lot of possible work in Kontact Touch, so limiting the scope is
> absolutely going to be required.
> 
> some are small things like getting rid of the odd little "show apps" button
> in the top left that is a legacy from Nokia N900 days. the side drawers
> could be harmonized with the Plasma Active look 'n feel.
> 
> there are bigger issues as well such as the extensive use of
> QGraphicsProxyWidget which will become a really uncomfortable thing when
> moving to QML2.
> 
> all the search and config widgets, for instance, are QWidgets imported into
> the scene via QGraphicsProxyWidget (which is horrible for performance) ..
> thse should be replaced with pure QML.
> 
> the Calendar widget is another, but imho that is going to be too large for a
> realistic GSoC project for someone who is not already intimately familiar
> with the calendar widget.

Somebody is or was working on a QML implementation, which can be used, I believe.

For me as a user, the main issue with the kontact touch calendar is that it can show 
only one resource at a time. It's pratically useless for me. (using kde 4.9 kontact 
touch on nexus 7)

> there is the multi-window workflow that is honestly pretty awkward and
> performance problem on device.
> 
> so there are lots of possible targets there. picking one class of issue in
> Kontact Touch is probably good for a GSoC project.

Consider the list that is used for mail folders, calendars and addressbooks, which is 
really a pain to use, because it is so difficult to navigate, always hiding everything but 
the active object.

On a tablet, there is room enough to have a list along side a mail or contact, allowing 
for better navigation. The android mail client does that nicely.

Date selection widgets badly needs an update, more modern ones exist.

The way dialogs are implemented with slide-in pages instead of tabs is not working 
very well, it is confusing and unintuitive to use in my experience.

> > The UI seems to be designed with a smaller form factor in mind. Is it 
> > supposed to stay this way or am I free to experiment and make it more
> > suitable for tablet use?
> 
> preferably the UI should scale, within reason, to higher and lower
> resolutions. the current design is pretty limited, but then it was written
> in another time when QML itself was more l imited and was targetting a very
> specific device ...

I believe we need some guidelines for how to support that, like other multiinterface 
systems have (android, ubuntu touch). In android, there is an organized way of 
having different definitions for different form factors, making it quite easy to realize.

Anders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/active/attachments/20130226/4e99a3a8/attachment.html>