[Kde-pim] Brainstrom - editing calendar events through QML?

[Mark]

On Mon, Jul 29, 2013 at 3:34 PM, Kevin Krammer <krammer at kde.org> wrote:

> Hi Mark,
>
> On Friday, 2013-07-26, Mark wrote:
> > Hi PIM folks,
> >
> > Lately I've been working quite a lot on the calendar stuff to get it
> > in a working shape that people can actually use.
>
> Very cool!
>
> > Showing basic calendar events (as in only events! not todos and
> > journal) are already working quite well so i'm thinking of the next
> > step there. The next step would be to edit a calendar event.
> >
> > Thus far i can think of a few different approaches to do this, but i
> > don't know which one would be seen as the most neat one or even if you
> > folks have a different solution.
> >
> > == Option 1: mass Q_PROPERTY adding to Incidence class ==
> > The easiest approach is probably to add Q_PROPERTY to the Incidence
> > class for all property's that the user should be able to change. In
> > QML you would then have a function available to get the incidence
> >
> > var incidence = <obj>.getIncidence() // gets the calendar incidence
> >
> > And then you can simply read and set the property's as you want:
> >
> > incidence.summary = "a new summary"
> > incidence.dtStart = ...
> > ... you get the point
> >
> > The biggest downside to this entire option is that Incidence doesn't
> > seem to inherit from QObject. I don't know if it's a n issue or even
> > possible to add QObject inheritence?
>
> We can't do that in the 4.x series and it is probably too much overhead
> anyway
> (I think there can be a lot of incidence objects).
>
> > == Option 2: Incidence wrapper for QObject ==
> > If option 1 isn't possible due to QObject then it's not very difficult
> > to create an Incidence wrapper that inherits from QObject. The rest
> > can be the same as option 1.
>
> IMHO the better way, also because it allows things like type conversions
> (if
> QML needs different types for the properties than what the C++ API of
> Incidence provides).
>
> > == Option 3: QML Incidence component ==
> > With option 1 and 2 we are already close to an actual QML Element,
> > it's just not exposed as such. Perhaps exposing it as a QML element is
> > better? It will be more readable on the QML side and can probably be
> > used in the future for making a new incidence as well.
>
> I am not sure about the use case for it, but I guess we could easily just
> register the adapter class if we wanted to do that at some point.
>
> Cheers,
> Kevin
>
> --
> Kevin Krammer, KDE developer, xdg-utils developer
> KDE user support, developer mentoring
>
> _______________________________________________
> KDE PIM mailing list kde-pim at kde.org
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/
>

Hi Keven,

I went for option 3 for the moment because that's easier for development
purposes in attaching a signal handler. Right now even editing events (just
the summary and description) are working just fine :) I'm actually hoping
that i can re-use the same class/object to create new events as well.

Cheers,
Mark
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/