[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Date/time class changes to handle extended date ranges
From: David Jarvie <lists () astrojar ! org ! uk>
Date: 2006-02-20 10:57:11
Message-ID: 20060220105759.18146.qmail () ktown ! kde ! org
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic