QML Calendar components for Akonadi in scratch repo

[Mark]

On Sat, Jul 13, 2013 at 9:25 PM, Heena Mahour <heena393 at gmail.com> wrote:
> Hey  Marco and other plasma developers as well ,
>
>>using cmake is a requirement before it can move anywhere.
>
> CMakeLists.txt and qmldir are made and is pushed for Mark's calendar
> component .He will make sure import org.kde.pim.calendar is to be installed
> .
>
> Between Mark suggested that calendar would require months to complete (based
> on his experiance last year).Easily stuff that can take you months to
> grasp..Would it be possible to port it in a month? Though a simple calendar
> with some functionalities as a pop up dialog to the clock that is resizable
> are already made (you can check out heenamahour/gsoc branch) .

well, that kinda depends on some things.
If you start from scratch and ignore what's there already then you have to:
- have quite a bit of Akonadi knowledge to make the calendar events
available in QML
- somehow interact with the current holidays library for the holiday
events. An added note here is that doing that is not wise since that
library is supposed to be dropped in favor for holiday data in some
special (installed by default) akonadi calendar resource. That part
alone can take you up to a month or more to make.
- You have to have in depth knowledge of Qt's model system and the
proxy models that lay on top of it. That's knowledge i don't have but
was lucky to find at the last kdepim sprint. Learning all that stuff
from scratch will take weeks till you understand it and can work with
it.
- then you have the different calendar systems to take into account.
Those are not possible with today's Qt (Or are they since Qt 5.1?),
but are in KDE classes. Classes that are about to be deprecated
because they will go into Qt which makes this part very complicated to
say the least.

The components that i made don't even take the last point into
account. It simply uses QDate to figure all the fuzzy stuff out, but
that certainly isn't enough for all the different calendar systems
that KDE supports. I haven't done anything in that area nor do i plan
to do anything there. I simply wait till ICU support is merged in Qt
with the calendar systems till i look at that again.
The current components also completely lack KHollidays support.

So yeah, you did took quite a big beast to tackle!

My suggestion for you is to do the following to get a visual feature
parity (functional near feature parity) for the calendar stuff:
1. I will make my components usable under kdepim-runtime in a separate
branch. You should use them.
2. Extend the components to support KHolidays and make them available
in the same was as i'm making other calendar events available. Or make
that custom calendar resource for holiday support, then you don't have
to do anything in the components themselve. Either way, jou should
contact "John Layd" for the best and easiest solution there since he
maintains KHolidays and probably knows best what the easiest approach
would be.
3. Ignore the multi calendar system support for now, it's out of our
hands (Actually in "Jonh Layd" his hands) and way to complicated.
4. Create a new calendar component (based on my demo component
perhaps) that looks exactly the same as the current calendar popup.

If you do that it is certainly possible to "finish" it within a month.
KHolidays will be the most difficult part, the QML part is fairly
easy.


>
>
> On Sat, Jul 13, 2013 at 2:51 PM, Mark <markg85 at gmail.com> wrote:
>>
>> On Fri, Jul 12, 2013 at 2:59 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
>> > On Friday, July 12, 2013 14:20:37 Mark wrote:
>> >> This is also one of the questions i have, where should i put this,
>> >> kdepim-runtime or kde-runtime?
>> >
>> > that entirely depends on the dependencies.
>> >
>> > what would be optimal is:
>> >
>> > * QML calendar widgetry with no akonadi integration in kde-runtime
>>
>> Will try that. I believe that dependency was needed for some proxy
>> models. However, i don't know the current state anymore and if that is
>> even still in.
>>
>> > * akonadi integration for the calendar in kdepim-runtime
>>
>> Awesome, guess i can make an kdepim-runtime branch then for these
>> components.
>> >
>> > looking at the documentation on the wiki, this seems like it should be
>> > possible.
>> >
>> > if it is not possible to separate out the akonadi support, then it will
>> > need
>> > to go into kdepim-runtime .. but you will need to check with the kdepim
>> > developers first as they maintain those modules, not us here on
>> > plasma-devel :)
>>
>> if it's going to end up in kdepim-runtime then yeah :) However, "you
>> plasma folks" still need to know of it's existence since plasma will
>> be the part using it. So having a topic in here about those components
>> is probably a good thing as well.
>>
>> >
>> > having apidocs along these lines:
>> >
>> >         http://api.kde.org/4.x-api/plasma-qml-apidocs/
>> >
>> > would be good; using cmake is a requirement before it can move anywhere.
>>
>> Converting it to CMake is next on the list.
>> >
>> > having just tried it out, the QML does need some work yet as you noted.
>> > would
>> > be nice to see use  of Plasma QML Components for the header and buttons
>> > .. but
>> > it is a nice start!
>>
>> Will do that.
>> >
>> > --
>> > Aaron J. Seigo
>> > _______________________________________________
>> > Plasma-devel mailing list
>> > Plasma-devel at kde.org
>> > https://mail.kde.org/mailman/listinfo/plasma-devel
>> >
>> _______________________________________________
>> Plasma-devel mailing list
>> Plasma-devel at 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 at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>