On Monday, 2014-02-10, 13:47:45, Sebastian Kügler wrote: > On Friday, February 07, 2014 19:25:55 Kevin Krammer wrote: > > On Friday, 2014-02-07, 18:26:20, Marco Martin wrote:
> > > * *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.) You are right and Akonadi itself is already buildable with Qt5. > 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. Good point! > Otherwise, basic status information is something that should be done using > Statusnotifier items. Is that something like the device notifier? I always get confused which is which since I have battery and network in a separate panel but other things like devices and mixer in the "tray". > > 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. The "workspace integration" idea was/is mostly about monitoring and control, i.e. seeing which resources you have, what their state is, being able to "put them on hold", etc. I.e. a replacement and more advanced successor for AkonadiTray. Search folders would be for data, but yes, hopefully Baloo will make that work extremely well. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
