Re: QTimeZone merged for 5.2
On Monday 14 October 2013 17:38:42 John Layt wrote: > On 14 October 2013 12:55, Kevin Ottens 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 use
Re: QTimeZone merged for 5.2
On 14 October 2013 12:55, Kevin Ottens 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. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QTimeZone merged for 5.2
On 14 October 2013 12:55, Kevin Ottens 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
Re: QTimeZone merged for 5.2
Hello, On Thursday 03 October 2013 18:15:22 John Layt wrote: > KDateTimeEdit > - My new widget to replace many local widgets, added in last kdelibs release > - Can replace KDateComboBox, KTimeComboBox, api is almost the same - Not > used anywhere!?! > - API uses QDate, QTime, KDateTime, KCalendarSystem, KTimeZone > - Suggest: Port to Qt5 > - KDE4 era apps can start pre-porting? > - Or add to Qt? > > KDateTimeWidget > - Used 8 times > - API uses QDateTime > - Poor UX > - Suggest: kde4support, replace with KDateTimeEdit 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? 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
Re: QTimeZone merged for 5.2
Hello, On Thursday 03 October 2013 18:15:22 John Layt wrote: > On 24 September 2013 19:24, Kevin Ottens wrote: > > On Tuesday 24 September 2013 19:03:21 John Layt wrote: > >> I'll do some analysis on the use of all the widgets and what ones are > >> worth keeping, and look at the Qt widgets to see if they're worth > >> switching to, if not before then at Qt Dev Days / Qt Contributors Day. > > > > OK, I'll ignore this part of KDE4Attic then and proceed with the rest. We > > really need to put this issue to a rest, it's been lingering for way too > > long. Really looking forward to your analysis! > > Replying to all the list, damn gmail not knowing about mailing lists :-\ > > And here's my analysis :-) > > tl;dr: > * Port KDateTimeEdit, KDatePicker, KDateTable and KTimeZoneWidget to Qt5. > * Move KDateTimeWidget, KDateWidget, KDateComboBox and KTimeComboBox > to kde4support > > General rule: > Any widget that uses KDateTime, KCalendarSystem, KTimeZone, or KLocale > must either go to kde4support or be ported. Porting would require > removing all uses of these K classes and using QDateTime, QTimeZone > and QLocale instead. KCalendarSystem would be replaced by using > QLocale, as QLocale will embed the QCalendarSystem class to be used, > as well as translations, formatters, etc. The widgets calendar api > setCalendar(), setCalendarSystem() and calendar() would be replaced by > setLocale() and locale(). OK, good to know. > No apps I checked currently use the calendar api on the widgets. Internal > code accessing date/time values like day() via KGlobal::calendar() would > change to directly accessing QDate or QTime for now, after Qt 5.3 they would > then need changing again to use QCalendarSystem via QLocale::calendar(). OK. > Method: Checked out all of the KDE SC, plus major gui apps from > extragear and calligra, then grepped for the class names. > > Visual guide: https://www.dropbox.com/s/qkdgo5s68pg6tp6/KDateWidgets.png > > KDateTimeEdit > - My new widget to replace many local widgets, added in last kdelibs release > - Can replace KDateComboBox, KTimeComboBox, api is almost the same - Not > used anywhere!?! > - API uses QDate, QTime, KDateTime, KCalendarSystem, KTimeZone > - Suggest: Port to Qt5 > - KDE4 era apps can start pre-porting? > - Or add to Qt? OK, let's port to Qt5 and then move in KWidgetsAddons. > KDateTimeWidget > - Used 8 times > - API uses QDateTime > - Poor UX > - Suggest: kde4support, replace with KDateTimeEdit > > KDateWidget > - Used 6 times > - API uses QDate, KCalendarSystem > - Poor UX > - Suggest: kde4support, replace with KDateTimeEdit > > KDateComboBox > - Used 30 times, 29 in kdepim > - API uses QDate, KCalendarSystem, KLocale::DateFormat > - Forked by several apps due to lack of features, KDateTimeEdit > written to replace > - Suggest: kde4support, replace with KDateTimeEdit > > KTimeComboBox > - Used 10 times, all kdepim > - API uses QTime, KLocale formats > - Forked by several apps due to lack of features, KDateTimeEdit > written to replace > - Suggest: kde4support, replace with KDateTimeEdit OK, can all go in kde4support IMO. Makes for poor widgets in the first place. > KDatePicker > - Used about 20 times, but hard to tell due to forks and wrappers > - Forked and/or wrapped by several apps due to lack of features, needs > to be reviewed > - Uses QDate, KCalendarSystem > - Suggest: Port to Qt5 OK, let's port to Qt5 and then move in KWidgetsAddons. > KDateTable > - Used directly 2 times, but is part of KDatePicker > - Forked and/or wrapped by couple apps due to lack of features, needs > to be reviewed > - API uses QDate, KCalendarSystem > - Suggest: Port to Qt5 > - Maybe make private, have flag on KDatePicker to hide chrome? > - Make KPopupFrame private? > - Make KDateVaidator private? What does it bring compared to QCalendarWidget? Couldn't KDatePicker use QCalendarWidget instead? > KTimeZoneWidget > - Used 4 times > - API uses KTimeZone > - Unlikely to be included in Qt, so needed in KF5 > - API looks a little old fashioned, users need major rewrite anyway > for QTimeZone > - Suggest: Port to Qt5? Or start anew? Eew, indeed it inherits publicly from QTreeWidget. I would say we can move it in kde4support renamed as K4TimeZoneWidget... but we need to come up with an alternative as it's used two times in the workspace. Thanks a lot for the work done. Cheers. -- 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
Re: QTimeZone merged for 5.2
On 24 September 2013 19:24, Kevin Ottens wrote: > On Tuesday 24 September 2013 19:03:21 John Layt wrote: >> I'll do some analysis on the use of all the widgets and what ones are >> worth keeping, and look at the Qt widgets to see if they're worth >> switching to, if not before then at Qt Dev Days / Qt Contributors Day. > > OK, I'll ignore this part of KDE4Attic then and proceed with the rest. We > really need to put this issue to a rest, it's been lingering for way too long. > Really looking forward to your analysis! Replying to all the list, damn gmail not knowing about mailing lists :-\ And here's my analysis :-) tl;dr: * Port KDateTimeEdit, KDatePicker, KDateTable and KTimeZoneWidget to Qt5. * Move KDateTimeWidget, KDateWidget, KDateComboBox and KTimeComboBox to kde4support General rule: Any widget that uses KDateTime, KCalendarSystem, KTimeZone, or KLocale must either go to kde4support or be ported. Porting would require removing all uses of these K classes and using QDateTime, QTimeZone and QLocale instead. KCalendarSystem would be replaced by using QLocale, as QLocale will embed the QCalendarSystem class to be used, as well as translations, formatters, etc. The widgets calendar api setCalendar(), setCalendarSystem() and calendar() would be replaced by setLocale() and locale(). No apps I checked currently use the calendar api on the widgets. Internal code accessing date/time values like day() via KGlobal::calendar() would change to directly accessing QDate or QTime for now, after Qt 5.3 they would then need changing again to use QCalendarSystem via QLocale::calendar(). Method: Checked out all of the KDE SC, plus major gui apps from extragear and calligra, then grepped for the class names. Visual guide: https://www.dropbox.com/s/qkdgo5s68pg6tp6/KDateWidgets.png KDateTimeEdit - My new widget to replace many local widgets, added in last kdelibs release - Can replace KDateComboBox, KTimeComboBox, api is almost the same - Not used anywhere!?! - API uses QDate, QTime, KDateTime, KCalendarSystem, KTimeZone - Suggest: Port to Qt5 - KDE4 era apps can start pre-porting? - Or add to Qt? KDateTimeWidget - Used 8 times - API uses QDateTime - Poor UX - Suggest: kde4support, replace with KDateTimeEdit KDateWidget - Used 6 times - API uses QDate, KCalendarSystem - Poor UX - Suggest: kde4support, replace with KDateTimeEdit KDateComboBox - Used 30 times, 29 in kdepim - API uses QDate, KCalendarSystem, KLocale::DateFormat - Forked by several apps due to lack of features, KDateTimeEdit written to replace - Suggest: kde4support, replace with KDateTimeEdit KTimeComboBox - Used 10 times, all kdepim - API uses QTime, KLocale formats - Forked by several apps due to lack of features, KDateTimeEdit written to replace - Suggest: kde4support, replace with KDateTimeEdit KDatePicker - Used about 20 times, but hard to tell due to forks and wrappers - Forked and/or wrapped by several apps due to lack of features, needs to be reviewed - Uses QDate, KCalendarSystem - Suggest: Port to Qt5 KDateTable - Used directly 2 times, but is part of KDatePicker - Forked and/or wrapped by couple apps due to lack of features, needs to be reviewed - API uses QDate, KCalendarSystem - Suggest: Port to Qt5 - Maybe make private, have flag on KDatePicker to hide chrome? - Make KPopupFrame private? - Make KDateVaidator private? KTimeZoneWidget - Used 4 times - API uses KTimeZone - Unlikely to be included in Qt, so needed in KF5 - API looks a little old fashioned, users need major rewrite anyway for QTimeZone - Suggest: Port to Qt5? Or start anew? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QTimeZone merged for 5.2
On 27 September 2013 16:52, Kevin Ottens wrote: > On Wednesday 25 September 2013 11:28:54 John Layt wrote: >> Started to look at the number of uses, but lxr hardly shows any. Does >> lxr include .ui files, or do I need to grep? > > I don't think it does unfortunately. No, doesn't appear to, I'm busy doing a full checkout of every repo... Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QTimeZone merged for 5.2
On 25 September 2013 17:21, Mark wrote: > >> >> I've been >> talking to the QML component guys and they will have a new calendar >> component for 5.3 that they need QCalendarSystem for as well. > > > > Hi John, > > What you said there sounds very interesting to me! Do you have any link for > me where i can read about that or where current code in that area is being > developed? > > Cheers, > Mark Sure. Just to correct myself, Mitch says its the QtQuick Controls' Calendar, not the actual QCalendarWidget. Not that I know what that means, I really need to take a QML course :-) https://codereview.qt-project.org/#change,45769 http://qt-project.org/doc/qt-5.1/qtqml/qml-qtqml2-date.html (the from* methods are missing.. see next link for those). https://codereview.qt-project.org/#patch,sidebyside,61255,1,src/qml/doc/snippets/qml/date.qml In response I pointed him at my draft QCalendarSystem class. http://qt-project.org/wiki/Qt-5-ICU#955c0120c32f7991db7d55a94df808c2. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QTimeZone merged for 5.2
On Wednesday 25 September 2013 11:28:54 John Layt wrote: > On 24 September 2013 19:24, Kevin Ottens wrote: > > On Tuesday 24 September 2013 19:03:21 John Layt wrote: > >> I'll do some analysis on the use of all the widgets and what ones are > >> worth keeping, and look at the Qt widgets to see if they're worth > >> switching to, if not before then at Qt Dev Days / Qt Contributors Day. > > > > OK, I'll ignore this part of KDE4Attic then and proceed with the rest. We > > really need to put this issue to a rest, it's been lingering for way too > > long. Really looking forward to your analysis! > > Started to look at the number of uses, but lxr hardly shows any. Does > lxr include .ui files, or do I need to grep? I don't think it does unfortunately. 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
Re: QTimeZone merged for 5.2
> I've been > talking to the QML component guys and they will have a new calendar > component for 5.3 that they need QCalendarSystem for as well. Hi John, What you said there sounds very interesting to me! Do you have any link for me where i can read about that or where current code in that area is being developed? Cheers, Mark ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QTimeZone merged for 5.2
On 24 September 2013 19:24, Kevin Ottens wrote: > On Tuesday 24 September 2013 19:03:21 John Layt wrote: >> I'll do some analysis on the use of all the widgets and what ones are >> worth keeping, and look at the Qt widgets to see if they're worth >> switching to, if not before then at Qt Dev Days / Qt Contributors Day. > > OK, I'll ignore this part of KDE4Attic then and proceed with the rest. We > really need to put this issue to a rest, it's been lingering for way too long. > Really looking forward to your analysis! Started to look at the number of uses, but lxr hardly shows any. Does lxr include .ui files, or do I need to grep? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QTimeZone merged for 5.2
On Tuesday 24 September 2013 19:03:21 John Layt wrote: > I'll do some analysis on the use of all the widgets and what ones are > worth keeping, and look at the Qt widgets to see if they're worth > switching to, if not before then at Qt Dev Days / Qt Contributors Day. OK, I'll ignore this part of KDE4Attic then and proceed with the rest. We really need to put this issue to a rest, it's been lingering for way too long. Really looking forward to your analysis! 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
Re: QTimeZone merged for 5.2
On 24 September 2013 12:11, Kevin Ottens wrote: >> OK, let's attempt to move KLocale, KDateTime and friends to kde4support now. >> With some luck we'll be able to completely get rid of KDE4Attic before >> release. > > Hmm, looking at that closer... indeed it looks like we can get rid of > K*TimeZone in favor of QTimeZone. But what would you advise for porting away > from KCalendarSystem and KLocalizedDate? > > Alternatives for those would be needed to move the date/time widgets currently > stuck in KDE4Attic to a more proper framework. Unfortunately QCalendarSystem was part of the QLocale changes that got postponed to 5.3 :-\ In the lower tiers this shouldn't be an issue as QDateTime or QLocale should be sufficient for their requirements. If you know of anything outside widgets that uses KCalendarSystem or KLocalizedDate then I'll have a look. For the widgets themselves, we had two main reasons for them: 1) The Qt ones were rubbish, and 2) The Qt ones didn't support our calendar systems Once Qt gets QCalendarSystem then the Qt widgets will need to support it, so I should have a good case for either fixing the existing Qt widgets or adding new ones that actually work. I've been talking to the QML component guys and they will have a new calendar component for 5.3 that they need QCalendarSystem for as well. As they stand, the KDE4 widgets are fairly tightly tied to KCalendarSystem and KLocale, and if we keep them in KF5 then they would need porting to QCalendarSystem and QLocale anyway, including a change of api for apps. We also want to drop some of our old date widgets that don't work very well. Given this all it may then make sense to move the date widgets to KDE4Support along with the other date classes, as they function as a whole. Then if we cannot get decent widgets into Qt we can create new widgets by porting our old ones to QCalendarSystem with new names. An alternative is to choose the date widgets we want to keep and remove the KCalendarSupport from them for now, and restore it when we get QCalendarSystem. I'll do some analysis on the use of all the widgets and what ones are worth keeping, and look at the Qt widgets to see if they're worth switching to, if not before then at Qt Dev Days / Qt Contributors Day. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QTimeZone merged for 5.2
On Monday 23 September 2013 09:33:54 Kevin Ottens wrote: > On Monday 23 September 2013 09:06:33 John Layt wrote: > > Hi, > > > > I am extremely relived to announce that QTimeZone finally got merged > > late late last night, thanks to the efforts of Thiago in fighting the > > CI system :-) Combined with other changes in QDateTime, this should > > mean we're free of KDateTime and KTimeZone, albeit with a few caveats. > > > > I'll be doing a lightning talk at Qt Dev Days on the topic, so I'll > > > > be documenting all the gotcha's people will need to look out for soon. > > > > Thanks also to the work from Martin and Rohan, all the necessary CUPS > > features have been merged into Qt 5.2, and a huge thanks to Alex for > > taking on QCollator and getting it in. I owe you all a beer or three > > next time I see you :-) > > > > I was less successful on the QLocale front, unfortunately there was > > too much resistance from Windows devs to using ICU everywhere, so that > > plan has been shelved and we've moved on to Plan C for 5.3. I'll be > > working through what that means for us soon, but I don't see any > > immediate problems for us in still switching to QLocale. > > Yay! > > OK, let's attempt to move KLocale, KDateTime and friends to kde4support now. > With some luck we'll be able to completely get rid of KDE4Attic before > release. Hmm, looking at that closer... indeed it looks like we can get rid of K*TimeZone in favor of QTimeZone. But what would you advise for porting away from KCalendarSystem and KLocalizedDate? Alternatives for those would be needed to move the date/time widgets currently stuck in KDE4Attic to a more proper framework. 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
Re: QTimeZone merged for 5.2
On Monday 23 September 2013 09:06:33 John Layt wrote: > Hi, > > I am extremely relived to announce that QTimeZone finally got merged > late late last night, thanks to the efforts of Thiago in fighting the > CI system :-) Combined with other changes in QDateTime, this should > mean we're free of KDateTime and KTimeZone, albeit with a few caveats. > I'll be doing a lightning talk at Qt Dev Days on the topic, so I'll > be documenting all the gotcha's people will need to look out for soon. > > Thanks also to the work from Martin and Rohan, all the necessary CUPS > features have been merged into Qt 5.2, and a huge thanks to Alex for > taking on QCollator and getting it in. I owe you all a beer or three > next time I see you :-) > > I was less successful on the QLocale front, unfortunately there was > too much resistance from Windows devs to using ICU everywhere, so that > plan has been shelved and we've moved on to Plan C for 5.3. I'll be > working through what that means for us soon, but I don't see any > immediate problems for us in still switching to QLocale. Yay! OK, let's attempt to move KLocale, KDateTime and friends to kde4support now. With some luck we'll be able to completely get rid of KDE4Attic before release. 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
QTimeZone merged for 5.2
Hi, I am extremely relived to announce that QTimeZone finally got merged late late last night, thanks to the efforts of Thiago in fighting the CI system :-) Combined with other changes in QDateTime, this should mean we're free of KDateTime and KTimeZone, albeit with a few caveats. I'll be doing a lightning talk at Qt Dev Days on the topic, so I'll be documenting all the gotcha's people will need to look out for soon. Thanks also to the work from Martin and Rohan, all the necessary CUPS features have been merged into Qt 5.2, and a huge thanks to Alex for taking on QCollator and getting it in. I owe you all a beer or three next time I see you :-) I was less successful on the QLocale front, unfortunately there was too much resistance from Windows devs to using ICU everywhere, so that plan has been shelved and we've moved on to Plan C for 5.3. I'll be working through what that means for us soon, but I don't see any immediate problems for us in still switching to QLocale. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
