On Monday 14 October 2013 17:38:42 John Layt wrote: > 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). > > 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
