I have my doubts whether this model should be QAbstractListModel-derived
or not. At first i thought i could not be, because i need to be able to
get a “view” (i.e., a [begin, end) pair of iterators) based on the
segment of TimelineView that becomes exposed due to scroll. However,
QAbstractItemModel::match returns a QModelIndexList, and that could also
be used for the same purpose, except that there is no QDateRange….
Until i have more needs for this model, the current coupling between
TimelineModel and TimelineView is OK, as i do not expect TimelineView to
be used for anything else.
I also renamed CalendarModel to TimelineListModel, since this is the
important part—the timeline—, and there is no “calendar” thing anywhere
in the application—at least, not what traditionally is understood as a
calendar, that is.
This is supposed to be like a kind of horizontal ListView, however the
elements need to be placed according to its starting date, and must be
as long as the number of days of the stay. As far as i know, i can not
do that with a Qt-provided ListView because it has a strict one-to-one
mapping between QModelIndex’s row and visual element’s row (i.e., the
first item is always the first row, the second item the second row,
etc.), while i to have “holes” in the rows for item that are not
continous in time.
Unfortunately, Qt Quick does not provide a C++ API, meaning that i can
not derive from QQuickListView or, rather, QQuickItemView, without using
the private API. And that API is private for a reason; i do not want to
see myself redoing the control because they have changed who knows what.
Thus, had to base this control on QQuickItem.
I am also pretty sure i will not be able to use QAbstractItemModel for
this control, as, again, that model assumes that everything is
continuous: lists have rows next to each other, tables columns next to
each other, and trees are “just” nested tables. But i am not certain
yet.
Meanwhile, what i really need to do is to show a delegate for each
“filled in” day, and that’s is what this controls does for now. Since i
can not inherit from QQuickFlickable—not that it would be a great idea
here, since i need a list of these views anyway—, i have to know the
viewport’s position and width in order to have only the minimum number
of items visible. I do like QQmlDelgateModel (that i can not reuse
without private API), and reuse the delegates when possible.