Hi

On Tue, Feb 26, 2002 at 01:39:49AM +0100, Cornelius Schumacher wrote:
> 
> To make it possible to use different calendar systems, we don't need to 
> subclass QDate, we need a new interface class CalendarSystem, which 
> provides functions to return for a given QDate object, which year it 
> belongs to, how many months that year has, to which month it belongs, 
> how many days the month has, how the month is called, etc. This 
> implicitly also contains the conversion functions from and to gregorian 
> dates, but so we have QDate as reference and only have to implement 
> conversions for this system and not for converting between two 
> non-gregorian systems.
> 
> The different calendar views then have to use the CalendarSystem class 
> to find out the information they currently have hard-coded.
> 
> Each different calendar system would have to be implemented as a 
> subclass of CalendarSystems, which provides all the required 
> information through the common abstract interface.

 
  I agree, that's a powerful and flexible design, and we avoid re-writing quite complex date management funcionality that yet QDate provides... So we can focus on views and conversion routines...
  
  I'll  try to do some stuff in that way. 

  	Salut everybody, it's a great pleasure to read all of you ;)


-- 

				Carlos Fernández Moro
				Departamento de Morfología y Biología Celular
				Universidad de Oviedo
				cfmoro@correo.uniovi.es

--------------------------------------------
| PGP/GnuPG public key at:                 |
|    http://www.rediris.es/cert/keyserver  |
|       keyID: 0x2190F184                  |
|    Send me mail with :                   |
|       subject: send pub key              |
| ICQ : 106984950                          |
--------------------------------------------
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/