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
