> On Oct. 28, 2015, 9:15 a.m., Marco Martin wrote: > > not much a fan of adding a public library there, but i guess there aren't > > many other ways. Could it be put into plasma-workspace instead? > > Daniel Vrátil wrote: > Please don't, unless you want to have Akonadi dependency in > plasma-workspace. This way we in KDE PIM can provide our own plugin, because > having a dependency on plasma-framework is not a big problem for us (unlike > having a PIM dependency in plasma-workspace I imagine). > > Luca Beltrame wrote: > +1 to what Dan said. As a contributor and a packager: plase *don't* have > things depend on workspace. It was a mess already in 4.x times, and caused > all sorts of headaches down the way. > > Marco Martin wrote: > the idea was that akonadi plugin would have resided in workspace as well > (i think an akonadi dependency in plasma-workspace is fine, like an > akonadi-integration under workspace/) > If that can't be done, ok for adding it in plasma-framework(i would > already prefer a separed framework on its own tough), I'm just very very > stingy in adding new and forever frozen symbols, especially frozen since its > first release > > Daniel Vrátil wrote: > Note that we don't have any PIM frameworks yet, so you would create > Plasma -> Applications dependency. At this point it's easier for PIM team to > maintain PIM integration stuff in PIM repositories. > > Since the only two users at the beginning will be the Holiday plugin and > PIM, I think that marking the library as "experimental" without and ABI/API > guarantees is perfectly fine for the first X releases, and once we see that > it works well for both, it can be moved to "stable". > > Martin Gräßlin wrote: > Overall that sounds like we need a weird repo somewhere in between which > can depend on both the workspace and the applications. > > I totally see Marco's point of it's not optimal to have a new always > frozen lib in Plasma Frameworks and I also see that it's a no-go to have > Workspace depend on Apps and also Apps depend on Workspace. We have three > possible ways and all are kind of broken ;-) Interesting things can happen. > > Martin Klapetek wrote: > I wasn't sure where to put it, but unless we put it in its own repo, > plasma-framework seems like the best-of-the-bad place, so I went with that.
exactly what will depend from it? -workspace and -applications ? - Marco ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125817/#review87564 ----------------------------------------------------------- On Oct. 27, 2015, 9:10 p.m., Martin Klapetek wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125817/ > ----------------------------------------------------------- > > (Updated Oct. 27, 2015, 9:10 p.m.) > > > Review request for Plasma and Daniel Vrátil. > > > Repository: plasma-framework > > > Description > ------- > > This adds a simple plugin interface that can be subclassed > and provide events integration with Plasma Calendar applet. > > It's asynchronous and I've kept it deliberately simple. > For now the Calendar tells the plugins which date range > is being displayed, the plugins load the data and then > emit the dataReady() signal containing the events. > > The events are stored in a multihash for quick access > by the Calendar's agenda part but also for overall > easy-to-use (eg. in teh model data()). > > The event data is stored in EventData class, which has > a pretty self-explanatory members, except perhaps the > "isMinor" one. The intention with this is to support > namedays, where in some countries the calendars have > different name every day. This is just a minor holiday > and as such should not mark the calendar grid, otherwise > the whole grid would be in a different color. > > Putting the interface here might raise the question of > depending on plasma-framework, but plugins provided by > KDE can go to plasma-workspace and other 3rd party ones > would just have to live with it. I don't think it will > be a problem but if it turns out it is, we can rethink > the placement. > > > Diffs > ----- > > src/declarativeimports/calendar/CMakeLists.txt 40ead91 > src/declarativeimports/calendar/calendarplugin.cpp bafe80c > src/declarativeimports/calendar/daysmodel.h a5bdac9 > src/declarativeimports/calendar/daysmodel.cpp 2d059a8 > src/declarativeimports/calendar/eventdatadecorator.h PRE-CREATION > src/declarativeimports/calendar/eventdatadecorator.cpp PRE-CREATION > src/declarativeimports/calendar/plasmacalendarintegration/CMakeLists.txt > PRE-CREATION > > src/declarativeimports/calendar/plasmacalendarintegration/PlasmaCalendarIntegrationConfig.cmake.in > PRE-CREATION > > src/declarativeimports/calendar/plasmacalendarintegration/calendareventsplugin.h > PRE-CREATION > > src/declarativeimports/calendar/plasmacalendarintegration/calendareventsplugin.cpp > PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/125817/diff/ > > > Testing > ------- > > I have a simple KHolidays based plugin written (patch should be up later > today) > and patches in the Calendar applet. > > Everything works as expected: > * the days are marked as containing an event > * the agenda part displays details of that event (name) > > > Thanks, > > Martin Klapetek > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
