QTimeZone merged for 5.2

[Kevin Ottens]

On Monday 14 October 2013 17:38:42 John Layt wrote:
> 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.

Can't tell for KTimeEdit, but KDateEdit is *very* different from 
KDateComboBox. They don't even share the same base class (line edit vs combo 
box).

> 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?).

Well, I remember a time when I tried to adopt some features of the KDateEdit 
various forks into the copy I have in Zanshin. But that's about it, my efforts 
to then get the result in kdepimlibs failed.

> 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.

Honestly I didn't know it was there, I don't think I've been told it was 
available. And looking at it, in its current state I wouldn't use it instead 
of my KDateEdit copy... it still lacks features (to be expected as it just 
layouts a KDateComboBox next to a KTimeComboBox).

> 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.

Again it uses KDateComboBox and KTimeComboBox... so if we keep KDateTimeEdit 
we're forced to keep the three of them... Two could be private copies of 
course.

> 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.

Sure, that's a nice point for it. Design wise, it's a bit mixing up 
responsibilities though... it's a date time editor, no wait it's a date 
editor, no wait it's a time editor, no wait user can set calendar with it too.

> 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.

We're past the point were we can bump the Qt dependency anyway. So the choice 
for each of the date/time widgets in kde4attic is really:
 * port to qt5 and move in kwidgetsaddons;
 * push to kde4support.

I think for KDatePicker the choice is clear (port to qt5, I'm working on it in 
fact). For KDateTimeEdit I thought it was clear too... I'm now less sure.

> 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?

So far it has been OK I would say. And indeed we wouldn't need to add much to 
QCalendarWidget to be on par with KDatePicker... Damn! Now I got doubts that 
KDatePicker needs to be salvaged too...

The situation with the date/edit widgets is a never ending headache...

Any chance I could reach you over IRC today so that we discuss that a bit 
further? We really need to settle on a final decision.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

Sponsored by KDAB to work on KDE Frameworks
KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20131015/b448f803/attachment.sig>