Future of QML calendar components

[Mark Gaiser]

On Mon, Nov 25, 2013 at 3:09 PM, Sebastian Kügler <sebas at kde.org> wrote:
> Hi Mark,
>
> On Monday, November 25, 2013 14:57:33 Mark Gaiser wrote:
>> I want to do the move to extragear + release this week.
>> Can plasma then depend on that library?
>
> No, we don't want that. Please don't move it.
>
> OTOH, whoever uses these things needs plasma-framework anyway, so keeping it
> there is not a problem for users. Once kdepimlibs becomes ready, we might
> consider moving some of the model stuff there, but as long as that's not the
> case, the point is moot.

Right now they require plasma because they are within plasma ;)
The intention with those components was to recreate the calendar popup
(i guess i succeeded there) and the bigger goal: re-creating
KOrganizer with them. With the later there should be no dependency on
plasma. That's why i never developed those components from within a
plasma branch to begin with.
>
>> I guess plasma can't because of pimlibs.. This would be temporary
>> issue (until pimlibs gets "frameworkized").
>
> Why not just develop these components in plasma-framework? It fits topically,
> the components use Plasma, so they depend on it anyway. That makes it one less
> dependency for *every* user, and saves headaches in synching of versions.

I simply can't. I need to have pimlibs for that and those don't work
in a Qt 5 environment yet.
>
> Especially, if you don't have time right now to work on it, it makes no sense
> to move them out, then let them hang there. That's less visibility and more
> pita for everyone involved. On the other side, we're working on it right now,
> you can join the fun once you've got time again. This is not a component that
> can be owned by one person, and depend on his/her schedule alone.

I actually do have the time right now, just not the pimlibs on Qt5 :)
Besides, i also have another fun QML project where i'm working on a
lot these days. It's called Accretion :)
>
>> == 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
>
> Not really, the models are there, the locale handling is there, it's not "just
> a grid. I've actually put more things together in the same place, since it was
> scattered across plasma-framework and the digital clock widgets. Now it's
> shared.

Yes, the models for "the grid" are there. The actual fun parts (the
events and the models for them) are all disabled. The grid might be
something more then just the grid + locale handling. But in reality
it's just exposing a month grid view to QML without events.

>
> Cheers,
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel