Future of QML calendar components
Mark Gaiser
markg85 at gmail.com
Mon Nov 25 13:57:33 UTC 2013
Hi,
The calendar components seems to be used more and more in plasma 2.
That kinda makes this an issue to resolve.
During the PIM sprint i also discussed the state and place of these
components. The result is:
== Qt 4 ==
QML Calendar Components as they are right now will go in bug fixing
mode (which it was already :p) and be for Qt 4. Or at least developed
in Qt 4. The current branch [1] will move to exteragear and be
released as "QML Calendar Components 1.0" and will only feature
calendar reading and calendar events. Todo, Journal and Holiday events
won't be in. At least not in 1.0. This version will depend on
kdepimlibs.
I want to do the move to extragear + release this week.
Can plasma then depend on that library?
I guess plasma can't because of pimlibs.. This would be temporary
issue (until pimlibs gets "frameworkized").
== Future development ==
Future development for calendar components is for now on hold. I do
very much like to continue development, but am being stopped by other
issues. Namely kdepimlibs that needs to be ported to Qt 5. Once
pimlibs is ported far enough (akonadi-calendar and kcalcore at the
very least) it will allow me to continue development of those
components under Qt 5.
== Calendar is no calendar ==
Lastly a slight bit of concern. When Heena copied the calendar bits to
plasma i was afraid that there was going to be some divergence between
the two places and now that seems to have happened. However, the
calendar bits in plasma don't seem to be about the calendar at all.
It's just the grid calculation stuff that is actually enabled in
there. Everything else - the real calendar bits - are disabled. So i
think we need to make a decision here. It was my initial plan to have
calendar components that both provide you the calendar grid data and
provide the actual calendar events simply because that's the easiest.
However, the actual events seem to be thoroughly disabled in plasma so
perhaps it's better to split it up in:
1. Calendar Grid - components for just the calendar grid data
2. Calendar Events - components that expose calendar data
If we diverge then i'd like the plasma bits to be renamed to
"CalendarGrid" and the import to be:
import org.kde.plasma.calendar.grid
The actual events will then be placed in:
import org.kde.plasma.calendar.events
To be clear. [2] (with a rename obviously) will be the main place for
the development of .grid. [1](+rename and move to extragear) will be
the main place for .event development.
Or we don't split up and my initial idea stays which is [1]. It's up
to the plasma folks what i do. I'm fine with either, but not with
duplication and divergence as we have now.
Cheers,
Mark
[1] http://quickgit.kde.org/?p=kdepim-runtime.git&a=shortlog&h=a37e777b73c607f10f8ae87b0950509bab084ced
(branch: calendar_components)
[2] http://quickgit.kde.org/?p=plasma-framework.git&a=tree&hb=580d7d198ad5030641c3f4014c42a7e0555ac617&h=f27982b3fac2156415671bc61e829d77e7f2b35c&f=src%2Fdeclarativeimports%2Fcalendar
More information about the Plasma-devel
mailing list