apart from re-implementation of lion mail , what about the other tasks I mentioned , these are fine? these will also require akonadi client library of kdepimlibs .
On Mon, Feb 10, 2014 at 6:17 PM, Sebastian Kügler <se...@kde.org> wrote: > On Friday, February 07, 2014 19:25:55 Kevin Krammer 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. > > That's my status as well. I hope the upcoming PIM sprint will shed some > light > on this. I'm pretty sure though that we're looking at at least another two > workspace releases until PIM has been ported to KF5. > > (Note, that still doesn't mean that Akonadi has to have been ported, if I > understand the architecture well, it should be entirely possible to have > Akonadi(Qt4) used by kdepimlibs/5 (and even KMail4) at the same time. > (Please > correct me if I'm wrong.) > > That leads me to a migration path which involves kdepimlibs as the first > step, > so we can actually get at the data in akonadi. Which also means that a > custom > pim-status-lib will be replaced very quickly, making it quite a waste to > implement it at high-enough quality. > > Otherwise, basic status information is something that should be done using > Statusnotifier items. > > > 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. > > Hoping that the stuff in kdepimlibs is now up to the job (searchfolders > working well enough, for example), yes. > -- > sebas > > http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 > _______________________________________________ > 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
