> On Oct. 26, 2015, 11:05 p.m., Daniel Vrátil wrote: > > src/declarativeimports/calendar/daysmodel.cpp, line 150 > > <https://git.reviewboard.kde.org/r/125817/diff/1/?file=412932#file412932line150> > > > > Is this iteration necessary just to print debug output? > > > > Once we have a PIM plugin with many events, this will get very very > > noisy.
Yeah, this shouldn't be there at all, I was just using it for debug purposes. > On Oct. 26, 2015, 11:05 p.m., Daniel Vrátil wrote: > > src/declarativeimports/calendar/plasmacalendarintegration/calendareventsplugin.h, > > line 40 > > <https://git.reviewboard.kde.org/r/125817/diff/1/?file=412937#file412937line40> > > > > This means that all-day events that span over multiple days will be > > ignored, which breaks many common PIM events. > > > > Otherwise the documentation should explictly say that the > > implementation has to resolve multi-day events into multiple EventData > > objects. It should be fine, the endTime can be three days ahead and isAllDay can be set to false by the plugin, then it will work. I added the isAllDay for easier working with the holidays which always have just a single date, so startDate + isAllDay = true, and that spares the model to check if it is from midnight to midnight. But thinking about it, it could be revisited. I think I'll just remove it and will treat EventType == Holiday as if isAllDay==true. > On Oct. 26, 2015, 11:05 p.m., Daniel Vrátil wrote: > > src/declarativeimports/calendar/daysmodel.cpp, line 177 > > <https://git.reviewboard.kde.org/r/125817/diff/1/?file=412932#file412932line177> > > > > This return statement probably shouldn't be there? No, wrong copypasta. > On Oct. 26, 2015, 11:05 p.m., Daniel Vrátil wrote: > > src/declarativeimports/calendar/plasmacalendarintegration/calendareventsplugin.h, > > line 31 > > <https://git.reviewboard.kde.org/r/125817/diff/1/?file=412937#file412937line31> > > > > IMO the members here should be hidden in PIMPL. > > > > 1) it would prevent ABI breakage (you can reoder members easilly when > > adding new ones) > > 2) it reduced copying and memory use when inserting/retrieving the > > objects from the QHash as well as passing a copy to EventDataDecorator. Hm, I'll see about that. On the other hand - how many other things would we need to add in the future? If we can think of some more usecases not covered by these, please share it. > On Oct. 26, 2015, 11:05 p.m., Daniel Vrátil wrote: > > src/declarativeimports/calendar/plasmacalendarintegration/calendareventsplugin.h, > > line 44 > > <https://git.reviewboard.kde.org/r/125817/diff/1/?file=412937#file412937line44> > > > > Should be called "description" IMO. "Comment" in the context of > > events/todos means something different (see RFC2445, part 4.8.1.4) Good point. - Martin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125817/#review87470 ----------------------------------------------------------- On Oct. 26, 2015, 9:22 p.m., Martin Klapetek wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125817/ > ----------------------------------------------------------- > > (Updated Oct. 26, 2015, 9:22 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 > > src/declarativeimports/calendar/plasmacalendarintegration/plasmacalendarintegration_export.h > 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
