<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 6, 2013 at 3:08 PM, Mark Gaiser <span dir="ltr"><<a href="mailto:markg85@gmail.com" target="_blank">markg85@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br></div>
Below is my "feature" list that i'd like to have in that calendar.<br>
Since i have some experience in that area i will try to help out as<br>
much as i can.<br>
<br>
-- QML part --<br>
* Controls for the calendar grid<br>
* Controls for next/forward or just a few functions. This should at<br>
least have a nextMonth/previousMonth. Perhaps also nextYear and<br>
previousYear for convenience.<br></blockquote><div><br></div><div>nextMonth/prevMonth totally agreed. For years, that depends on the UI imho, so that the header is not too cluttered with different arrows. I can imagine a fading up/down arrows above/below the year, not sure how much would that work in practice though...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Controls for the day names (mon, tue, wed, thu, fri, sat, sun). And<br>
the ability to change the name to shorter/longer variants.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Controls for the weeknumbers that are shown in the grid.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As far as i understand the QML code, all but the weeknumbers are in.<br></blockquote><div><br></div><div>Yup, but it's made as one single component (for consumers) iirc.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-- Locale --<br>
In KDE there was already an issue with differences between the<br>
JavaScript date object and the QDate object. I don't know the fine<br>
details here, someone else will probably fill that in i hope. I know<br>
there where issues, just not what exactly.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-- C++ part --<br>
This is the part where i really would like some feedback. I have a<br>
general idea of how it should be done, but i don't know the details or<br>
implications it might have.<br>
It is my hope that calendar controls like Mitch is proposing now will<br>
be extensive enough to simply swap the models to another backend.<br>
Akonadi comes to mind. However, there should obviously be a<br>
non-akonadi based version for default Qt usage.<br>
<br>
My idea on that is as follows. Again, i don't know the implications of<br>
it or if it's really viable to take this route. Feedback is very much<br>
welcome here!<br>
The calendar model should be based on a new model that provides some<br>
default functionality and properties. I would say:<br>
QAbstractCalendarModel : public QAbstractListModel { ... }<br>
This model should provide the default - should be implemented - properties:<br>
* day -- INT number of the day in a current month<br></blockquote><div><br></div><div>You mean like 31, 28 etc? Or what would this property be for? The selected day? Then let's name it properly.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* isCurrentMonth -- returns true for the current month (aka, the month<br>
you are viewing in the calendar). Returns false for the days before<br>
and after the currently viewing month. Based on the position in the<br>
grid you can then calculate if the entry where "isCurrentMonth"<br>
returns false is before or after the current month.<br></blockquote><div><br></div><div>"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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* containsEvents -- true if the day contains events, false otherwise<br></blockquote><div><br></div><div>How would one then retrieve the events for the given day? Also, wouldn't it be better to have a model role returning this?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
"day" and "isCurrentMonth" should be convenience implemented in the<br>
QAbstractCalendarModel.<br>
<br>
Next there should be a model for core Qt calendar usage. Or in other<br>
terms: no akonadi dependency.<br>
That would be a class like:<br>
QSimpleCalendarModel : public QAbstractCalendarModel { ... }<br>
<br>
That class should probably have some basic storage in json files<br>
somewhere? Or ini or sqlite or..? Just something so that it can be<br>
used out of the box without any other requirements beyond Qt.<br>
Till this point is what would probably go in Qt. Everything after this<br>
line becomes Akonadi specific and should not be in Qt.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If a structure like the above is approved then Akonadi can be very<br>
easily used in KDE with the Qt calendar components.<br>
We'd just have to make out own QAbstractCalendarModel implementation<br>
that uses akonadi data. That would be a class like:<br>
(K)AconadiCalendarModel : public QAbstractCalendarModel { ... }<br>
<br>
It can still use the base QAbstractCalendarModel implementation for<br>
it's grid stuff and re-implement the "containsEvents" property to be<br>
filled with data from akonadi.</blockquote><div><br></div><div>How would that be filled with data if it returns boolean? I mean, what do you want to fill where? :)</div><div><br></div><div><br></div><div>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).</div>
<div><br></div></div><div>Cheers</div>-- <br><div><span style="color:rgb(102,102,102)">Martin Klapetek | KDE Developer</span></div>
</div></div>