Date/time class changes to handle extended date ranges

[David Jarvie]

On Monday 20 February 2006 10:43, 'R.F. Pels' wrote:
>On Monday 20 February 2006 10.36, David Jarvie wrote:
>
>> I didn't word my reply well. You are partly citing KDE convention to back
>> up your position. What I meant to say is that until people who know about
>> such things say that you are right in that respect, I don't buy into it. 
>
>That is the easy way out for you. Go ahead and see for yourself and check a 
>number of K classes that have a Q counterpart:
>
>	QColor		--> KColor
>	QComboBox	--> KComboBox
>	QApplication	--> KApplication
>	QMainWindow	--> KMainWindow
>	QToolbar	--> KToolBar
>	QLabel		--> KLabel
>	QLineEdit	--> KLineEdit
>	QButton		--> KButton
>
>There are a few exceptions, for example KEdit, but that is a deprecated class 
>which is replaced by KTextEdit. Need I go on? 
>
>> So far, unless I'm mistaken, nobody else has agreed with you on the naming
>> issue. So unless that changes, and because I disagree with you, I will use
>> the names which I proposed.
>
>Great... Then I /do/ hope you also propose to adjust KDateInternalXXX, 
>KDatePicker, KDateTable, KDateTimeWidget, KDateValidator and KDateWidget to 
>use the KDate class. After all, the name you propose creates the expectation 
>that they all work with a KDate object.

I think that you're taking too narrow a view on this. To repeat, unless a consensus 
agrees with you, I won't change the proposed class names.

--
David Jarvie.
KAlarm author & maintainer.
http://www.astrojar.org.uk/linux/kalarm.html