Jalali calender
-
As far as I know, there's no support yet. You might follow the discussions on the enhancements on [[Doc:QDateTime]]. The current state is documented on the Contributors' Summit's "wiki page about QDateTime":http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/QDateTime
-
Subclassing most likely is not a good idea. As far as I know QDateTime is based on a Julian date internally, although it expects a Gregorian date externally. Check out the static constructor functions. Maybe writing a wrapper from Jalali to Gregorian is all you need. What actually is Jalali? Never heard of this calendar before.
-
If you can not wait for Qt 5 (no guarantees it will be in there, but the people at QtCS I discussed this with seemed very motivated to get it into Qt 5), I suggest you take a look at what the KDE libs have to offer you.
QDate is not a good class to subclass, because it only has a default destructor and those are not virtual. If you subclass such a class, and you destruct it through a pointer to the base class, the results are undefined. You do not want to move into the realm of undefined behaviour.
-
It seems that I'll have to write a Qt-like class, (subclass of QObject) from scratch. It should not be so hard... for converting between calenders, got some complex algorithms for convert between Jalali, Hijri and Julian calender from Geophysical Institute of Tehran.
bq. What actually is Jalali? Never heard of this calendar before.
Jalali calender is a solar calender. first six mounts of a year are 31 days. months 7 to 11 are 30 days and 12th month is 29 day and becomes 30 days every four-year period. also there are two years in a 4-year period with 30 days in 12th month, every 33 years. and every 124 years there is no year with 30 days in 12th month. The year begin at March 21st. (Spring)
-
bq. Jelali is the Persian calendar system. I think KDE supports working with it out of the box, so yet again: I suggest you check out how they manage that.
KDE already has a complete implementation of Jalali calender (I'm using on my desktop :) but it's not so usable within Qt. I would like to have a Qt-like class. I started to implement a subclass of QObject with approach of SIGNAL / SLOT (hopefully).
-
[quote author="soroush" date="1309161858"]It seems that I'll have to write a Qt-like class, (subclass of QObject) from scratch. It should not be so hard... for converting between calenders, got some complex algorithms for convert between Jalali, Hijri and Julian calender from Geophysical Institute of Tehran.[/quote]
Why do you need to subclass QObject? Do you need signals and slots? Properties? -
bq. Why do you need to subclass QObject? Do you need signals and slots? Properties?
Actually no! but I think it could be a nice training to learn more about Qt.
Is it a bad idea to use signal / slot / properties and other things of Qt in some class when it's possible to implement that without them?
-
[quote author="soroush" date="1309163121"]bq. Why do you need to subclass QObject? Do you need signals and slots? Properties?
Actually no! but I think it could be a nice training to learn more about Qt.
Is it a bad idea to use signal / slot / properties and other things of Qt in some class when it's possible to implement that without them?[/quote]
Signals/Slots are there to be used. If you need them, by all means go and have a QObject subclass. What Andre meant was, if you don't need signals and slots ( other few good things that come with QObject,Q_OBJECT macro) you don't need to have your class derived from QObject.
