[Development] Qt Quick Controls Calendar

[Martin Klapetek]

On Tue, Jan 7, 2014 at 4:36 PM, Mark Gaiser <markg85 at gmail.com> wrote:

>
> >> * Controls for the day names (mon, tue, wed, thu, fri, sat, sun). And
> >> the ability to change the name to shorter/longer variants.
> >
> >
> > What would be the usecase for longer variants? Full screen/huuge
> calendars I
> > assume? Here's an important question imho - should the days be
> capitalized
> > or not? Qt's locale follows, well, the locale and for example the Czech
> > weekday names are not capitalized because we do not capitalize them, like
> > for example Friday in English is. However, when it's put standalone, I
> think
> > it should always be capitalized. It simply looks better.
>
> You're thinking just about the calendar grid now. For that you don't
> need more then 3 char day names.
> But my intention is more to have a general data model that can be
> easily used for more then just a calendar grid though the grid would
> be it's primary goal.
> So it is tailored towards a grid, but not limited to it.
>

Well...if you think it makes sense to have a data model for 7 different
strings...ok, I guess.


> An example where you might want longer daynames is in a event overview
> which just sums up the upcoming events. The current plasma calendar
> even has that so i think it should have the ability to set the day
> name lengths with the possibilities that you can also find in QDate.
>

Sure, but why would you mix a whole model to display one string, which you
can obtain very easily in other ways?


> As for capitalize the first char.
> I think the model (the C++ side) should just return the string that
> the locale gives. Without modification. The QML side - the view - can
> then capitalize it. It's kinda pointless to add a model property:
>
> bool capitalizeFirstDayChar..
>
> Possible, but seems a bit odd.
>

I didn't mean it as an option, but rather do it always. As I said, Qt's
locale returns values not really suitable to be used standalone (for other
than English locales anyway). Plus you'd get inconsistent looks across
languages (imho the UI should just always be consistent in these things, no
matter what the locale returns - and we currently are in the plasmoid).


> >
> >>
> >> * Controls for the weeknumbers that are shown in the grid.
> >
> >
> > Optional with default off. But if the visual side is made good enough
> > looking, it might work. But in 76% of times you don't need to know the
> week
> > number, then it just clutters the grid.
>
> It's just a model :) on/off is decided by the view i guess.
>

Well when you say "Controls", I think (visual) QML controls, ie. the View.


> >
> >>
> >> As far as i understand the QML code, all but the weeknumbers are in.
> >
> >
> > Yup, but it's made as one single component (for consumers) iirc.
> >
> >>
> >> -- Locale --
> >> In KDE there was already an issue with differences between the
> >> JavaScript date object and the QDate object. I don't know the fine
> >> details here, someone else will probably fill that in i hope. I know
> >> there where issues, just not what exactly.
> >
> >
> > I already posted it before, but for the sake of completeness, QDate
> starts
> > weekdays and months with 1 while JS Date object starts both with 0, so
> eg.
> > QDate weekday value 7 is Sunday while JS Date would give you "undefined"
> for
> > 7.
>
> Right, so we either should do no modification in from the C++ model
> and let it be done by the view. Or we should do all modifications -
> which i can't even think of - and just hope that it won't ever
> interfere with the view.
> I vote for sending date objects to QML and let the view decide what to
> do with it.
>

I /think/ that if you pass a QDate object from C++ to JS, it's
automatically converted. But needs to be checked.


> >
> >>
> >> -- C++ part --
> >> This is the part where i really would like some feedback. I have a
> >> general idea of how it should be done, but i don't know the details or
> >> implications it might have.
> >> It is my hope that calendar controls like Mitch is proposing now will
> >> be extensive enough to simply swap the models to another backend.
> >> Akonadi comes to mind. However, there should obviously be a
> >> non-akonadi based version for default Qt usage.
> >>
> >> My idea on that is as follows. Again, i don't know the implications of
> >> it or if it's really viable to take this route. Feedback is very much
> >> welcome here!
> >> The calendar model should be based on a new model that provides some
> >> default functionality and properties. I would say:
> >> QAbstractCalendarModel : public QAbstractListModel { ... }
> >> This model should provide the default - should be implemented -
> >> properties:
> >> * day -- INT number of the day in a current month
> >
> >
> > You mean like 31, 28 etc? Or what would this property be for? The
> selected
> > day? Then let's name it properly.
>
> Interesting!
> I actually thing "day" is named properly :)
>
> The model basically has a list of days (one for each in a month). Each
> day had a number which "day" would be.
> Perhaps "dayInMonth" would be more clear?
> Yes, this is:
> 1, 2, 3, 4, .... 28, 29, 30...
>
> Note that the abstract model has no knowledge about the selected day.
> It just has a list of days represented in a model, another model with
> all events for the days in the model and that should be about it.
> Besides some convenient models for the week numbers and day names.
>
> However, your reply did make me wonder how i would ever make this work
> if the abstract model doesn't know about the currently selected day. I
> now think it does need to know abut that, but doesn't need to
> implement it. It must know the properties which classes implementing
> the abstract model should re-implement to give it meaning.
>

I still have no clue what would I use this property for.


>
> >
> >>
> >> * isCurrentMonth -- returns true for the current month (aka, the month
> >> you are viewing in the calendar). Returns false for the days before
> >> and after the currently viewing month. Based on the position in the
> >> grid you can then calculate if the entry where "isCurrentMonth"
> >> returns false is before or after the current month.
> >
> >
> > "isCurrentMonth" implicates "is this the month that currently really is",
> > eg. QString("January").isCurrentMonth() = true;. If it's supposed to be
> the
> > month currently in the view, let's name it "isCurrentlyDisplayedMonth" or
> > something.
>
> +1. isCurrentlyDisplayedMonth makes more sense.
> >
> >>
> >> * containsEvents -- true if the day contains events, false otherwise
> >
> >
> > How would one then retrieve the events for the given day? Also, wouldn't
> it
> > be better to have a model role returning this?
>
> This is something i thought - at the time i wrote the proposal - would
> make since since you could use this to check if a day has events. If
> it does then you can load the model for that day. However, that
> doesn't make any sense anymore. Specially because i forgot to name a
> property like:
>
> QAIM events
>
> I think it's better to just return a model for the events in the
> current day. That makes more sense anyway.
>

Yes. However I think we're still operating on different ideas.

So basically you want to have a model providing data...and you expose this
data through properties? That sounds horribly wrong.

If we're making a model, let's make it a proper model and return /all/ the
data through the QVariant data(..) method. Let's define set of roles which
the subclassing model must implement. Then it becomes quite an easy task.



> However, that poses another difficulty. multiday events!
>
> In a grid view you might not want to see multiday events for each day
> it occurs. You just want to see it when it starts (like it's now in
> plasma calendar). However, in a list view or timeline view you
> actually might want to see it for each day.
>
> While writing this mail i'm thinking about leaving out a property for
> events altogether and make a function available:
> Type would be a flags field with one or more of the following:
> - Events
> - Todo
> - Holiday
> - Journal
>
> includeMultiday.
> true: for each day the event occurs, you will have an event object
> false(default): only the first day of the overlap will have a event object
>
> QAbstractListModel events(QDate, Type, bool includeMultiday)
>
> And a range version of the same function:
>
> QAbstractListModel events(QDate start, QDate end, Type, bool
> includeMultiday)
>
> I think that would be very flexible and accommodate every need.
>
>
> >
> >>
> >>
> >> "day" and "isCurrentMonth" should be convenience implemented in the
> >> QAbstractCalendarModel.
> >>
> >> Next there should be a model for core Qt calendar usage. Or in other
> >> terms: no akonadi dependency.
> >> That would be a class like:
> >> QSimpleCalendarModel : public QAbstractCalendarModel { ... }
> >>
> >> That class should probably have some basic storage in json files
> >> somewhere? Or ini or sqlite or..? Just something so that it can be
> >> used out of the box without any other requirements beyond Qt.
> >> Till this point is what would probably go in Qt. Everything after this
> >> line becomes Akonadi specific and should not be in Qt.
> >
> >
> > What would it store? I mean what events would be in the simple calendar?
> If
> > you want that to be a base class for other people implementing calendar
> > events backend, I think the Abstract class is enough? Or is that meant
> just
> > as an basic example? Then it can go to qt's examples and use whatever is
> the
> > easiest. Imho.
>
> Well, you can have a calendar without akonadi you know ;) It's more
> intended to be a simple calendar storage type for those wanting to
> have a calendar but not from anything fancy like akonadi. Just some
> local simple storage. How it would store it or where. I don't know.
> This is not a class i would implement :)
>

Yes, I know. I was wondering about the purpose of this class.


> I would make the abstract version and the akonadi based
> implementation. This class would probably be done by Mitch i guess?
> >
> >>
> >> If a structure like the above is approved then Akonadi can be very
> >> easily used in KDE with the Qt calendar components.
> >> We'd just have to make out own QAbstractCalendarModel implementation
> >> that uses akonadi data. That would be a class like:
> >> (K)AconadiCalendarModel : public QAbstractCalendarModel { ... }
> >>
> >> It can still use the base QAbstractCalendarModel implementation for
> >> it's grid stuff and re-implement the "containsEvents" property to be
> >> filled with data from akonadi.
> >
> >
> > How would that be filled with data if it returns boolean? I mean, what do
> > you want to fill where? :)
> >
> >
> > Overall I like the real model backend, however I think your proposal also
> > could use definition of roles for the model and what would be returned
> for
> > those roles (what comes to mind is single vs. multiple events in one day,
> > would it always return a list or a string in one case and list in other
> > case...etc).
>
> The return for those roles is decided in the class re-implementing
> QAbstractCalendarModel. In this case the akonadi implementation.
> How that would look like is completely unknown right now. You can
> however expect it to resemble the stuff i already made for my calendar
> components ;)
>

Sure, but you need to define which roles is the subclass going to
reimplement and also define what those roles actually mean.


> But i guess there is one class missing here.
> The object it returns for events in a day must be known in
> QAbstractCalendarModel thus a class has to be defined for that as
> well.
>
> Just on the top of my head i'd like to propose (probably very incomplete):
>
> QAbstractCalendarData
> {
> public:
>   QVariant data(int col) { return QVariant(); }
> }
>
> That class is intended to used per calendar day where the class is the
> "wrapper" around an event, journal item, holiday or todo item. So you
> will very likely get multiple instances of that class per day. As much
> as you have events/jour.... you get the point.
>

Why not simply return a list in the main QAbstractCalendarModel rather than
reimplementing a whole model? Sounds overly complicated...?

Cheers
-- 
Martin Klapetek | KDE Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140107/54858c75/attachment-0001.html>