On 14 October 2013 12:55, Kevin Ottens <er...@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). > > Opinion?
Hi, 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. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel