plasma workspace integration for akonadi

Heena Mahour heena393 at gmail.com
Sat Feb 8 05:38:40 UTC 2014


Re implementation of lion mail is required in any case .
It is currently using data engine which is not the required tool as it
should use models throughout and all is based on QGraphicsView .
It is architecturally broken and not yet finished as was suggested by Sebas
.
So , it would be a nice idea for that I think .
@Marco what are your opinions about it ?




On Fri, Feb 7, 2014 at 11:55 PM, Kevin Krammer <krammer at kde.org> wrote:

> On Friday, 2014-02-07, 18:26:20, Marco Martin wrote:
> > On Friday 07 February 2014 16:28:20 Kevin Krammer wrote:
> > > The GSOC idea referenced below is not about data at all, it is about
> > > state.
> > >
> > > Akonadi state information and control works via D-Bus, so it would be
> > > possible to do a client for that without linking to libakonadi-kde.
> > >
> > > This was just brought up as an option, since Plasma/workspace
> development
> > > and KDEPIM libs development are currently not using the same Qt version
> > > and
> > > potentially will not during the GSOC period.
> >
> > my concern is:
> > * is this worth, as opposed to waiting for kdepimlibs?
>
> I mostly brought this up as an options, it might or might not be
> worthwhile.
> Using D-Bus directly might allow to only transfer information that is
> needed,
> on the other hand making a QML adaptor for things like
> Akonadi::AgentInstanceModel will be faster and easier to code.
>
> Obviously also a difference in dependencies if that matters.
>
> > * is accessing those dbus functions something that kdepimlibs doesn't
> > provide?
>
> No. But kdepimlibs obviously involves more C++ classes.
>
> > * *if* a Qt5 kdepimlibs was available, would this way be
> > preferrable anyways?
>
> My understanding is that there is a frameworks branch in kdepimlibs which
> at
> some point was fully build-able.  No idea what the current status is.
>
> I've repeated that specific GSOC idea for a couple of years now, either
> there
> were no takers or they didn't convince us that they could successfully do
> it.
>
> I didn't re-add the idea again, mostly because of the lack of interest but
> also because of the bad timing for this year (focus on different Qt
> versions).
>
> Since it is a "old" idea it might also have to be reevaluated, e.g.
> whether it
> fits into the current or future concepts of our workspace offerings, etc.
>
> The only reason this was listed as  KDEPIM idea was that Plasma was
> consistently filling all the GSOC slots it could get while KDE PIM usually
> had
> some to spare.
> This is almost 100% user interface and user interaction work.
>
> Cheers,
> Kevin
>
> --
> Kevin Krammer, KDE developer, xdg-utils developer
> KDE user support, developer mentoring
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>


-- 
-Heena
Season of kde'12 participant
Google Summer of Code 2013
Delhi College of Engineering(COE),India
http://about.me/heena.mahour
http://heenamahour.blogspot.in
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140208/c2c10c82/attachment.html>


More information about the Plasma-devel mailing list