Summary: | Date outputs need to use KCalendarSystem | ||
---|---|---|---|
Product: | [Applications] kst | Reporter: | George Staikos <staikos> |
Component: | i18n | Assignee: | kst |
Status: | RESOLVED NOT A BUG | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | 1.x | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
George Staikos
2004-10-19 07:35:49 UTC
The user may not want to use the locale format for any number of reasons, so they are presented wih several standard options - including use of their locale. Sure, some of them are nice to have. It could even take a formatting string and format the date based on that. However, Qt's "locale" formatting code is obviously insufficient since we created KCalendarSystem. That's the point of the bug. On Tuesday 19 October 2004 13:05, Andrew Walker wrote:
> One obvious problem is that KCalendarSystem is in KDE 3.2 and up,
> whereas many people are still using KDE 3.1. What is it that
> KCalendarSystem provides that Qt doesn't? (not in general, but
> specific to what we are trying to do here). If we're going to go to the
> trouble of ifdef'ing code then there should be a very good reason for it.
There's no need to ifdef. The files are of course LGPL and self-contained.
It's maybe a dozen or so including the implementations of all the different
calendars. It should hook cleanly into Kst, and we just conditionally
compile it if we need to the way KMDI is done. Regarding KDE 3.1, if I
remember discussions long ago, were we going to prepare to move to 3.2/3.3
min requirement in the new year?
What KCalendarSystem does is output the dates correctly for all KDE users.
It is the most correct approach, which is why it was suggested from the
start. Do we have people from these backgrounds using Kst? Certainly, our
oldest bug proves that. The non-deprecated K* classes must be preferred to
the Qt equivalents in Kst.
I must still be missing something here. KCalendarSystem does not (that I can see) provide a formatted string from a QDate. What it does do is return such things as the month name, day of week name, etc from a QDate. So I don't see where KCalendarSystem would be useful in this scenario as I'm not interested in anything but numeric values for day, month, etc. Qt does exactly what I want, and KCalendarSystem adds nothing to it. If you disagree please give me same example code of how KCalendarSystem could be used in this case, else I'll withdraw this bug. On Monday 07 March 2005 17:22, Andrew Walker wrote:
> ------- I must still be missing something here. KCalendarSystem does not
> (that I can see) provide a formatted string from a QDate. What it does do
> is return such things as the month name, day of week name, etc from a
> QDate. So I don't see where KCalendarSystem would be useful in this
> scenario as I'm not interested in anything but numeric values for day,
> month, etc. Qt does exactly what I want, and KCalendarSystem adds nothing
> to it. If you disagree please give me same example code of how
> KCalendarSystem could be used in this case, else I'll withdraw this bug.
Ok, I think there may have been month text code in there at one time. If
it's gone, then we probably don't need KCalendarSystem. -However-, numeric
formatting for dates and times still need to follow the KDE l10n settings
since, for example, 03/03/05 means one of six different things depending on
the location.
KCalnedarSystem does not provide the stated functionality. |