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

[Kevin Krammer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20130729/f3f848b1/attachment.sig>
-------------- next part --------------
_______________________________________________
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/