QTimeZone merged for 5.2

[John Layt]

On 14 October 2013 12:55, Kevin Ottens <ervin at kde.org> wrote:
> Giving it a closer look, I'm wondering: are you sure about this course of
> action?
> KDateTimeEdit is basically a KDateComboBox and a KTimeComboBox layouted
> together. So deprecating those two without deprecating KDateTimeEdit sounds
> weird to me... In particular internally it could/should use KDateEdit (which
> is forked several times and not in kdelibs ATM) which is a much more
> interesting widget.
>
> At that point I would be tempted to move KDateTimeEdit to kde4support too as
> it's not used anyway and push people toward using stock Qt widgets to their
> date/time needs.
>
> It means the only two widgets we would save from the kde4support fate are
> KDatePicker and later on KDateEdit (once all its forks are merged or we pick
> one implementation from the lot).

KDateEdit and KTimeEdit are forks of KDateComboBox and KTimeComboBox
with extra features added, which were then copied around a lot.
KDateTimeEdit was a new kdelibs widget in 4.8 designed to replace all
the forks and merge all the extra features into one clean new widget,
which was done in consultation with the apps involved (I think you
even did the review?).  Why none of the apps maintaining their own
forks have changed over I don't know, I certainly told them it was
available, but it may be worth asking them to find out why.
KDateTimeEdit can replace all of KDateEdit, KTimeEdit, KDateComboBox,
and KTimeComboBox simply by setting the mode to use, hence why I
prefer for it to be the one that is kept if any are.  Another plus is
it is only derived from QWidget so can have its internals changed,
unlike KDateWidget and KDateComboBox which are derived from QComboBox
and KComboBox.

Pushing people to use the Qt widgets might be preferable, but we'd
need to do a feature-by-feature comparison to see if people would
actually want to use them or if it would just lead to more forks.
Also it would need to be an either/or thing, as the date edit widgets
need a date picker pop-up, so the two go together.  Ideally I'd have
time to write brand new Qt widgets, but I can't guarantee that.

Speaking of which, I was looking at KDatePicker vs QCalendarWidget
situation, and here's my analysis.

- K has optional close button
- K has next/prev year and month buttons, Q only month buttons
- K has year edit pop-up, Q has spin box
- K has Today button
- K has visible line edit for date, Q has hidden entry when type numbers
- K has week selector combo
- K has optional right-click context menu (unused)
- K can set font size (prob obsolete?)
- K has more signals
- K has custom date painting, can set fg/bg colour and bg shape circle/square
- Q has custom date painting using QTextCharFormat
- Q can set nav bar invisible, K uses separate KDateTable class
- Q can change header day name length, can format with QTextCharFormat
- Q has optional week number column, can format with QTextCharFormat
- Q can toggle visible grid
- Q can set min/max date, but only in 100AD to 7999AD range
- Q can override first day of week
- Q can set editable or not editable
- Q can set single date selction or no selection

Basically QCalendarWidget has better guts, more flexability and
themability, but KDatePicker looks better and has better usability.
We may be able to extend QCalendarWidget with some of the KDE
features, but that would require buy-in from the Widgets maintainers.
Current Q looks ugly when used with Oxygen, it doesn't seem to pick up
any themeing?  Then again, KDateTable is not exactly very themed
either.

I'm not sure what the best option is here.  If others could have a
play with QCalendarWidget and give an opinion on whether it performs
well enough or not?  Also, how receptive have the QWidgets maintainers
been to visible changes?

Cheers!

John.