QDate, KCalendarSystem, KDatePicker, and some API change proposals (long)

[John Layt]

On Thursday 12 Jul 2007, John Layt wrote:
...
> The only solution I can see is to have KDatePicker hold a KCalendarSystem
> pointer and allow KDatePicker to access the currently protected locale()
> method on KCalendarSystem to get the right translation (via friend or
> making it public, but both options may expose too much).
...
> The whole thing is a can of worms I wish I'd opened earlier to give time to
> work out a proper solution.  Unless there's an obvious solution I'm
> missing? Otherwise the widgets may just have to wait for 4.1.

Well, after hacking on it, the date widgets only use 3 methods from the global 
locale (readDate, formatDate, startOfWeek), so by adding those 3 methods to 
the KCalendarSystem and having them pass the call to the internal locale() 
method, everything is solved in a safe way.  Note this is not re-implementing 
those methods, merely passing the call to the correct global or local locale.  
It also has the added benefit that if any future calendar system 
implementation don't work properly with the KLocale methods, they can be 
over-ridden just for that calendar system.

I've finished my proposed patches, I'm just struggling to get my devel 
environment set up properly to test them, so I'll post my proposals Monday 
for people to consider for inclusion on the final mad libs Monday :-).

John.

P.S. Thought of another justification for the whole multiple calendars at once 
question: India.  All official government business is conducted with the Saka 
calendar, but commerce and the public use Gregorian.  If we want to rule the 
Indian desktop, we'll need to support their side-by-side use.

--

Send instant messages to your online friends http://au.messenger.yahoo.com