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 <kram...@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@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
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
