Re: Replacement for KDateTime
On Monday 03 Aug 2015 14:29:41 Dāvis Mosāns wrote: 2015-08-03 15:26 GMT+03:00 David Jarvie djar...@kde.org: On Monday 03 Aug 2015 12:59:59 you wrote: 2015-08-02 21:32 GMT+03:00 David Jarvie djar...@kde.org: Date-only KDateTime instances are not only used for Event start/end timestamps. In KAlarm they are also used among other things for alarm snooze times (independently of whether the event is date-only or not). So usage of the date-only attribute is *not* restricted to Events (even if that is all it is used for in kcalcore). Sorry for injecting myself, but IMO there's no such thing as Date-only and what you need is something like QDateTimeRange (just made up) where you would have start QDateTime, end QDateTime and it could represent any Event/Interval. Like whole day, part of day or even multiple days. And could also check whether some QDateTime is inside this range. Date-only extends the current QDateTime concept to allow it to represent a single date (which is intrinsically a time range) or a single date-time, without requiring any extra date-time information to be stored - only a boolean flag is required to indicate whether the time component should be ignored. A generalised time range on the other hand requires storing distinct start and end times, and cannot (except for special cases) be represented by a single date or date-time. That sounds like kind of a hack... trying to save few bytes for very minimal use case. As soon as you'll need to represent something outside of that you'll need a proper range. Besides can implement range with QDateTime + qint64 My point is that a QDateTime already contains both a date and a date-time. A date-only option provides the option to select one or the other. QDateTime does not contain a range, so a time range is something different (except for the special case of a single date). Adding a flag to select data which is already there is IMHO different in scope from adding extra data (either another QDateTime or a qint64). -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: Replacement for KDateTime
On Monday 03 August 2015 21:57:36 John Layt wrote: The problem actually is that Plasma is not considered a system platform by QLocale, it doesn't go looking for what Plasma wants, it just uses the underlying GNU/Linux system settings. Convince Qt to hard-code in a lookup of some Plasma config file with user overrides to be applied whenever Qt apps run under Plasma and then you can get what you need. I had plans somewhere for how that would work, and how we could also make Gtk apps use our settings too by manipulating the LC_* settings. That's not going to happen. The only solution I'm going to accept is one that also applies to /bin/ls. So far, the idea of setting LC_TIME to a file containing the rules is the only solution I've seen to accomplish that. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Replacement for KDateTime
On Monday 03 August 2015 22:15:51 John Layt wrote: One problem is Qt completely ignores the contents of that file, and indeed I'm not sure it would even manage to extract the correct locale name even so you'd end up with some default. We just need to fix QSystemLocale and make it fall back to the C API if the locale is a file or one not found in the database it carries. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Replacement for KDateTime
On Monday 03 August 2015 22:00:04 John Layt wrote: On 3 August 2015 at 20:07, David Jarvie djar...@kde.org wrote: As I understand it, a QDateTime is invalid if either the date or time component is invalid. People would usually expect that if QDateTime::isValid() returns false, the object must be invalid. So a date-only value in which only the date was valid would make the whole object invalid, which is misleading and would almost certainly lead to mistakes. That is correct and it is a long-standing QDateTime behaviour that I would hate to change in a non-major release due to the huge amount of code that expects it to work that way. It's just not an option to use. QDateTime::isValid() indicates whether it's a valid date-time pair. It isn't. The QDateTime object may still contain a valid date or valid time though. And I agree with John that we can't change it in 5.x and we probably won't change in 6.0 either because that would lead instead to code that assuming that a date-only QDateTime equals a full QDateTime at midnight. Or, worse, somehow parsing a time-only QDateTime as a few hours into Nov 24, -4713, which leads to severe issues when this time-only QDateTime somehow gets converted to time_t (out of range). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Replacement for KDateTime
On Tue, Aug 4, 2015 at 8:57 AM, John Layt jl...@kde.org wrote: On 3 August 2015 at 07:33, Martin Klapetek martin.klape...@gmail.com wrote: So what is missing/wanted is telling QLocale to use en_GB *but* return any time string in 24h format for example. Or to use ISO date format by default. The stuff coming from cldr might not always be what the user wants. And there's no easy and global way to override it other than setting different LC_TIME value, which is less than ideal as it can give you 24h clock format but will leave you with different date format too, so it's a hit'n'miss game. Suppose there's such QLocale setting as described above, then it would be just a matter of some regexp inside the time formatting function which would add/remove the ap/AP strings for the clock. I imagine. There's code that does that floating around in KDE or Qt, can't recall where, but it is fraught with problems in unconventional languages. You also need to replace the hh with HH to get the 24 rather than 12. But it's a hard rule in QLocale: no overriding default settings provided by the system, as those are the system settings and what the user expects you to use, e.g. on Windows and Mac you can switch from 12 to 24 hours and have it respected by Qt. If you want a different format, then pass a custom pattern each time. The problem actually is that Plasma is not considered a system platform by QLocale, it doesn't go looking for what Plasma wants, it just uses the underlying GNU/Linux system settings. Convince Qt to hard-code in a lookup of some Plasma config file with user overrides to be applied whenever Qt apps run under Plasma and then you can get what you need. I had plans somewhere for how that would work, and how we could also make Gtk apps use our settings too by manipulating the LC_* settings. I'm assuming QLocale isn't routed through the platform plugin like other parts of Qt do in these cases, so we can't manipulate things there? John. Ben
Re: Replacement for KDateTime
On 3 August 2015 at 19:03, Thomas Lübking thomas.luebk...@gmail.com wrote: Disclaimer: I may talk nonsense. What about exporting LC_TIME=KDE and have a ~/.local/share/i18n/locales/KDE which can be configured from the locale kcm. This way *all* applications (including even mc ;-) would follow the pattern the user configures there. (Except the KDE SC4 applications, but we could probably write the legacy config for them) The major pitfall (what I don't know how to do) is: how to get userpath locale definitions recognized? Not nonsense, exactly my long-term plan to get Gtk and other apps to use the right Plasma locale settings when running under Plasma. It 'just' requires the kcm to learn how to write and compile a POSIX locale file. One problem is Qt completely ignores the contents of that file, and indeed I'm not sure it would even manage to extract the correct locale name even so you'd end up with some default. John.
Re: Replacement for KDateTime
[Again resend from subscribed account, damn gmail!] On 3 August 2015 at 19:03, Thomas Lübking thomas.luebk...@gmail.com wrote: Disclaimer: I may talk nonsense. What about exporting LC_TIME=KDE and have a ~/.local/share/i18n/locales/KDE which can be configured from the locale kcm. This way *all* applications (including even mc ;-) would follow the pattern the user configures there. (Except the KDE SC4 applications, but we could probably write the legacy config for them) The major pitfall (what I don't know how to do) is: how to get userpath locale definitions recognized? Not nonsense, exactly my long-term plan to get Gtk and other apps to use the right Plasma locale settings when running under Plasma. It 'just' requires the kcm to learn how to write and compile a POSIX locale file. One problem is Qt completely ignores the contents of that file, and indeed I'm not sure it would even manage to extract the correct locale name even so you'd end up with some default. John.
Re: Replacement for KDateTime
On 3 August 2015 at 19:58, David Jarvie djar...@kde.org wrote: There are a number of cases in kdepim where a date-time or a date can be supplied. Using KDateTime makes the code cleaner - there is no need to provide overloads or to track whether it's date-only when calling multiple layers of functions or classes, because the KDateTime value provides that information. Not to mention needing the time zone as well which a QDate doesn't. John.
Re: Replacement for KDateTime
On Sun, Aug 2, 2015 at 7:36 PM, Thiago Macieira thi...@kde.org wrote: If the format you're looking for is in the CLDR, you're welcome to add the support to QLocale. It's not really about any missing locale, it's about setting different parameters for the given locale. For example David Edmundson (a brit) repeatedly tells me that en_GB (cldr) uses 12h clock format but pretty much any clock is guaranteed to be 24h clock format. So what is missing/wanted is telling QLocale to use en_GB *but* return any time string in 24h format for example. Or to use ISO date format by default. The stuff coming from cldr might not always be what the user wants. And there's no easy and global way to override it other than setting different LC_TIME value, which is less than ideal as it can give you 24h clock format but will leave you with different date format too, so it's a hit'n'miss game. If the format you're looking for requires support from translators, please add a new class to QtCore. Suppose there's such QLocale setting as described above, then it would be just a matter of some regexp inside the time formatting function which would add/remove the ap/AP strings for the clock. I imagine. Alternatively, do you John have any roadmap about QLocale? Perhaps we could help with filling the missing bits into QLocale directly too. The roadmap currently stands as follows: Does this mean there is no roadmap? :) Cheers -- Martin Klapetek | KDE Developer
Re: RFC: KDE Bugzilla Bugs Expiration
- Original Message - On Friday, July 31, 2015 09:55:30 PM Thomas Lübking wrote: On Freitag, 31. Juli 2015 19:29:53 CEST, Ingo Klöcker wrote: I also do not see the point in nagging the user after a certain period of time if nobody else ever cared to comment on the bug. Feels a bit like little kids asking Are we there yet? over and over again. The idea is not only to get rid of cruft (bugs which auto-fixed either implicitly by eg. code cleanups or as dupes) but also to remind developers by resubmission (eg. when a bug fell off the table during high activity periods) I do see the point in Daniel's proposal because the time a release goes EOL feels like a sensible point in time for asking whether the bug still exists. - when do unspecified version bugs EOL? Unspecified version is IMO a silly thing in the first place. How is developer supposed to fix a bug if he does not know what version it happens with? I can see the point of it for wishes, but there I think it was agreed above that auto-closing should not affect those. - when do git version bugs EOL? Hmm, good question. Maybe when a new version is released, all git bug reports should be moved to that version? That's another process we have in Fedora - Rawhide rebase. At the point next release branches, we move all Rawhide bugs (except FutureFeature, RFEs etc.) to the branched version as it was reported during the development of this version. I was running it in Fedora for a few years, there was opposition we can't close bugs as people would not report new bugs, sometimes I go through closed bugs and it's sad when it's something really simple. But we are all humans, with other work to do and I think it's honest to reporters to tell them sorry, we have limited resources. Also it requires some activity from reporter and developer so many bugs are revived and even fixed in this period. The other thing we try is to make reopening bugs as easy as possible, explain what we do and why we do it. Of course, sometimes it's hard but I think it's worth. It keeps Bugzilla clean. https://fedoraproject.org/wiki/Fedora_Program_Management/EOLRebaseSOP Just as Kevin pointed out - it's much more easier in Fedora Bugzilla, as it's one product developed at one time. I used simple perl script that processed CSV exported from Bugzilla query. I'm not sure if Bugzilla Rule Engine already hit upstream/KDE Bugzilla but that could be another tool to help with cleanups... Jaroslav
Re: RFC: KDE Bugzilla Bugs Expiration
On Mon, Aug 3, 2015 at 9:19 AM, Ingo Klöcker kloec...@kde.org wrote: On Saturday 01 August 2015 01:49:13 Daniel Vrátil wrote: I like the idea of a nag and I don't think it necesarily conflicts with the ideas above. Having a weekly/bi-weekly nags to developers would IMO work (hey, you have 10 new bugs this week that you did not comment on or confirmed yet, please look at them asap). If the developer ignores the bugs even after that then it becomes a different problem, but that I don't know how to solve. It certainly wouldn't work for me. I know because I'm nagged all the time by mailman that there are n messages in the moderation queue. I know this because I also receive each individual moderation request. The nagging is just annoying. I'm filtering out all kdepim bug reports (yeah, I could just unsubscribe from the list). I'll certainly filter out the nag mails as well. If I was still interested in the bug reports then I'd prefer to create my own workflow for handling them without being annoyed by some robot that doesn't no anything about how I work. Note that behaviour such as the above (aggressive filtering) is one of the reasons Sysadmin moved away from using Bugzilla for our task tracking - because our replies effectively got ignored until we pestered developers via IRC or private email. Such filters are extremely disrespectful to the community at large (including users and all other contributors) and should not be used as they simply result in important issues being completely neglected. Regards, Ingo Regards, Ben
Re: Replacement for KDateTime
On Mon, Aug 3, 2015 at 6:34 PM, Thiago Macieira thi...@kde.org wrote: On Monday 03 August 2015 08:33:54 Martin Klapetek wrote: If the format you're looking for requires support from translators, please add a new class to QtCore. Suppose there's such QLocale setting as described above, then it would be just a matter of some regexp inside the time formatting function which would add/remove the ap/AP strings for the clock. I imagine. How would that setting be set? Who would set it? Is that something that the clock app would use and allow the user to set? If so, why not extract the time format and show that to the user? Or, at least, parse it to set the default of Use 24-hour clock? If the user wants to toggle 24-hour, save the new time format in the config file and use it to format the time next time. I may have explained it poorly, so let me try again. tl;dr at the bottom :) I can put a checkbox to the Plasma panel clock which would either enable or disable 24h clock format. And in fact we do exactly that. If the user wants to see 24h clock format in the panel, he can check that checkbox. If he wants AM/PM clock, he can uncheck the checkbox. Simple as that. The implementation takes the Qt.locale().timeFormat(Locale.ShortFormat) (it's QML), checks for the 24h clock option and either adds AP or removes AP from the format string returned by Qt.locale(). The actual clock on the panel is then printed using Qt.formatTime(currentTimeObject, thatModifiedTimeFormatString). Now, this will affect _only_ the Plasma panel clock. This will _not_ affect Dolphin's time stamps, Gwenview's picture-taken times, this won't affect anything else but the panel clock and the panel clock alone. But if I want to have 24h clock format, I want it everywhere, in all apps, system-wide, not _only_ in the panel clock. Everything else will be however using time formatted by the LC_TIME locale default format. Currently each and every application would have to implement similar code as the Plasma panel clock - get the locale's time format string, check for some config, add/remove AP from the format string, print the time using QDateTime().toString(theModifiedTimeFormatString). Or each application would have to read the date/time format string from somewhere, some global config in order to have the same time format everywhere. Is it clear now? Do you see what I'm getting at? Setting different LC_TIME values proven to not be feasible, because very often users want just 24h clock format _and_ their locale's date format. Or some date format and their locale's time format. Ideally there would be a global setting, set from System Settings, perhaps written into ~/.config/QtProject.conf, which QLocale could internally read and return the time formatted according to that setting already. This would spare every single application doing it on its own. Then, calling QDateTime().toString() or QLocale().toString(QDateTime) would return the time formatted by user preference already and it would return it in all apps, uniformly, same format. I guess such feature might not be feasible for QLocale, hence my suggestion to bring back KLocale in a limited form, purely for global date/time formatting purposes around KDE apps, to have the same date/time format everywhere around. As a side note, missing global date/time format setting is a regression from the kde4 times. --- tl;dr - it'd be nice to be able to set a custom time format for all QDateTime/ QLocale users without them needing to do anything at all. Hope it's clear now :) Cheers -- Martin Klapetek | KDE Developer
Re: Replacement for KDateTime
On Sonntag, 2. August 2015 20:32:43 CEST, David Jarvie wrote:
Having a date-only attribute in KDateTime is very useful
because it allows both date-time and date-only values to be
encapsulated in a single class. This avoids having to be able to
pass either a QDate or QDateTime or to have a separate flag
everywhere this is used, and it allows date-time values to be
compared to date-only values using class methods.
Sorry, but I don't follow here.
QDateTime *has* a QDate AND a QTime member.
They can independently be null/invalid.
= With a QDateTime with invalid QTime member, you *have* a QDate-only
QDateTime, agreed?
The problem would be that
if (kdt.isValid()) {
if (kdt.isDateOnly())
foo();
else
bar();
}
turns into:
if (qdt.date().isValid()) {
if (!qdt.time().isValid())
foo();
else
bar();
}
right?
Doesn't look that horrible.
-
Now, it however seems to me you'd like to have a flag butIgnoreTheTime that
hints for some client code behavior, ie. you actually want to carry valid date and time
in the object, but in addition have a flag _in_the_object_ to effectively pass a
parameter to a function to do something different with this object.
Is this actually correct?
= That frankly sounds like a bool trap on steroids.
You've an object flying around that may or not have set this flag for some™
ominous reason in the past for some™ function call and different modules might
have different requirements for this flag for different reasons... e.
Imo, if you want to embed instructions on what to do with the object inside the
object, they should rather be not the least ambiguous, ie. provide dynamic
properties or such.
But, ultimately, function parameters belong into the function parameter list - not into
object attributes (yes, unless you're doing some hardcore optimizations or dirty
side-channel communication hacks)
Cheers to my 2¢,
Thomas
Re: Replacement for KDateTime
On Monday 03 Aug 2015 18:22:28 you wrote: 2015-08-03 17:33 GMT+03:00 David Jarvie djar...@kde.org: On Monday 03 Aug 2015 14:29:41 Dāvis Mosāns wrote: 2015-08-03 15:26 GMT+03:00 David Jarvie djar...@kde.org: On Monday 03 Aug 2015 12:59:59 you wrote: 2015-08-02 21:32 GMT+03:00 David Jarvie djar...@kde.org: Date-only KDateTime instances are not only used for Event start/end timestamps. In KAlarm they are also used among other things for alarm snooze times (independently of whether the event is date-only or not). So usage of the date-only attribute is *not* restricted to Events (even if that is all it is used for in kcalcore). Sorry for injecting myself, but IMO there's no such thing as Date-only and what you need is something like QDateTimeRange (just made up) where you would have start QDateTime, end QDateTime and it could represent any Event/Interval. Like whole day, part of day or even multiple days. And could also check whether some QDateTime is inside this range. Date-only extends the current QDateTime concept to allow it to represent a single date (which is intrinsically a time range) or a single date-time, without requiring any extra date-time information to be stored - only a boolean flag is required to indicate whether the time component should be ignored. A generalised time range on the other hand requires storing distinct start and end times, and cannot (except for special cases) be represented by a single date or date-time. That sounds like kind of a hack... trying to save few bytes for very minimal use case. As soon as you'll need to represent something outside of that you'll need a proper range. Besides can implement range with QDateTime + qint64 My point is that a QDateTime already contains both a date and a date-time. A date-only option provides the option to select one or the other. QDateTime does not contain a range, so a time range is something different (except for the special case of a single date). Adding a flag to select data which is already there is IMHO different in scope from adding extra data (either another QDateTime or a qint64). Ok, I don't really understand what's your use case and so I don't see why you would need that. There's QDate and QTime, you can use QDateTime::date() to extract QDate and for other cases you really do need a range. Sounds like you want QDateOrTime (also made up), but I think very few applications would use something like. And IMO that's bad design, because cleaner code would be with method overloads which take either QDate or QTime. There are a number of cases in kdepim where a date-time or a date can be supplied. Using KDateTime makes the code cleaner - there is no need to provide overloads or to track whether it's date-only when calling multiple layers of functions or classes, because the KDateTime value provides that information. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: Replacement for KDateTime
On Monday 03 Aug 2015 19:49:52 Thomas Lübking wrote:
On Sonntag, 2. August 2015 20:32:43 CEST, David Jarvie wrote:
Having a date-only attribute in KDateTime is very useful
because it allows both date-time and date-only values to be
encapsulated in a single class. This avoids having to be able to
pass either a QDate or QDateTime or to have a separate flag
everywhere this is used, and it allows date-time values to be
compared to date-only values using class methods.
Sorry, but I don't follow here.
QDateTime *has* a QDate AND a QTime member.
They can independently be null/invalid.
= With a QDateTime with invalid QTime member, you *have* a QDate-only
QDateTime, agreed?
The problem would be that
if (kdt.isValid()) {
if (kdt.isDateOnly())
foo();
else
bar();
}
turns into:
if (qdt.date().isValid()) {
if (!qdt.time().isValid())
foo();
else
bar();
}
right?
Doesn't look that horrible.
-
Now, it however seems to me you'd like to have a flag butIgnoreTheTime that
hints for some client code behavior, ie. you actually want to carry valid
date and time in the object, but in addition have a flag _in_the_object_ to
effectively pass a parameter to a function to do something different with
this object.
Is this actually correct?
= That frankly sounds like a bool trap on steroids.
You've an object flying around that may or not have set this flag for some™
ominous reason in the past for some™ function call and different modules
might have different requirements for this flag for different reasons...
e.
As I understand it, a QDateTime is invalid if either the date or time component
is invalid. People would usually expect that if QDateTime::isValid() returns
false, the object must be invalid. So a date-only value in which only the date
was valid would make the whole object invalid, which is misleading and would
almost certainly lead to mistakes.
--
David Jarvie.
KDE developer.
KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: Replacement for KDateTime
On Montag, 3. August 2015 19:09:17 CEST, Martin Klapetek wrote: Setting different LC_TIME values proven to not be feasible, because very often users want just 24h clock format _and_ their locale's date format. Or some date format and their locale's time format. Disclaimer: I may talk nonsense. What about exporting LC_TIME=KDE and have a ~/.local/share/i18n/locales/KDE which can be configured from the locale kcm. This way *all* applications (including even mc ;-) would follow the pattern the user configures there. (Except the KDE SC4 applications, but we could probably write the legacy config for them) The major pitfall (what I don't know how to do) is: how to get userpath locale definitions recognized? Cheers, Thomas
Re: Replacement for KDateTime
On Monday 03 August 2015 08:33:54 Martin Klapetek wrote: If the format you're looking for requires support from translators, please add a new class to QtCore. Suppose there's such QLocale setting as described above, then it would be just a matter of some regexp inside the time formatting function which would add/remove the ap/AP strings for the clock. I imagine. How would that setting be set? Who would set it? Is that something that the clock app would use and allow the user to set? If so, why not extract the time format and show that to the user? Or, at least, parse it to set the default of Use 24-hour clock? If the user wants to toggle 24-hour, save the new time format in the config file and use it to format the time next time. Alternatively, do you John have any roadmap about QLocale? Perhaps we could help with filling the missing bits into QLocale directly too. The roadmap currently stands as follows: Does this mean there is no roadmap? :) It means the roadmap is empty. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Replacement for KDateTime
On Monday 03 Aug 2015 12:59:59 you wrote: 2015-08-02 21:32 GMT+03:00 David Jarvie djar...@kde.org: Date-only KDateTime instances are not only used for Event start/end timestamps. In KAlarm they are also used among other things for alarm snooze times (independently of whether the event is date-only or not). So usage of the date-only attribute is *not* restricted to Events (even if that is all it is used for in kcalcore). Sorry for injecting myself, but IMO there's no such thing as Date-only and what you need is something like QDateTimeRange (just made up) where you would have start QDateTime, end QDateTime and it could represent any Event/Interval. Like whole day, part of day or even multiple days. And could also check whether some QDateTime is inside this range. Date-only extends the current QDateTime concept to allow it to represent a single date (which is intrinsically a time range) or a single date-time, without requiring any extra date-time information to be stored - only a boolean flag is required to indicate whether the time component should be ignored. A generalised time range on the other hand requires storing distinct start and end times, and cannot (except for special cases) be represented by a single date or date-time. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: Replacement for KDateTime
On 2 August 2015 at 19:32, David Jarvie djar...@kde.org wrote: Having a date-only attribute in KDateTime is very useful because it allows both date-time and date-only values to be encapsulated in a single class. This avoids having to be able to pass either a QDate or QDateTime or to have a separate flag everywhere this is used, and it allows date-time values to be compared to date-only values using class methods. Without this encapsulation, it would make a significant amount of code more cumbersome. KAlarm for one will certainly need the equivalent of KDateTime even if it has to have its own class, but given its use in kcalcore I think it should be available in a library. Also, do you know that date-only is NOT used elsewhere (apart from kcalcore and KAlarm)? lxr tells me it is only KCalCore and KAlarm. KCalCore uses it about 16 times. If we want KCalCore used outside kdepim then I do think they need to try and live without the isDateOnly option and find a nice way of doing it . For KAlarm I don't see a problem with you having your own KADateTime class to do this. John.
Re: Replacement for KDateTime
On 3 August 2015 at 07:33, Martin Klapetek martin.klape...@gmail.com wrote: So what is missing/wanted is telling QLocale to use en_GB *but* return any time string in 24h format for example. Or to use ISO date format by default. The stuff coming from cldr might not always be what the user wants. And there's no easy and global way to override it other than setting different LC_TIME value, which is less than ideal as it can give you 24h clock format but will leave you with different date format too, so it's a hit'n'miss game. Suppose there's such QLocale setting as described above, then it would be just a matter of some regexp inside the time formatting function which would add/remove the ap/AP strings for the clock. I imagine. There's code that does that floating around in KDE or Qt, can't recall where, but it is fraught with problems in unconventional languages. You also need to replace the hh with HH to get the 24 rather than 12. But it's a hard rule in QLocale: no overriding default settings provided by the system, as those are the system settings and what the user expects you to use, e.g. on Windows and Mac you can switch from 12 to 24 hours and have it respected by Qt. If you want a different format, then pass a custom pattern each time. The problem actually is that Plasma is not considered a system platform by QLocale, it doesn't go looking for what Plasma wants, it just uses the underlying GNU/Linux system settings. Convince Qt to hard-code in a lookup of some Plasma config file with user overrides to be applied whenever Qt apps run under Plasma and then you can get what you need. I had plans somewhere for how that would work, and how we could also make Gtk apps use our settings too by manipulating the LC_* settings. John.
Re: Replacement for KDateTime
On 3 August 2015 at 20:07, David Jarvie djar...@kde.org wrote: As I understand it, a QDateTime is invalid if either the date or time component is invalid. People would usually expect that if QDateTime::isValid() returns false, the object must be invalid. So a date-only value in which only the date was valid would make the whole object invalid, which is misleading and would almost certainly lead to mistakes. That is correct and it is a long-standing QDateTime behaviour that I would hate to change in a non-major release due to the huge amount of code that expects it to work that way. It's just not an option to use. John.
Re: Replacement for KDateTime
[Reply sent again from subscribed account] On 2 August 2015 at 16:08, Martin Klapetek martin.klape...@gmail.com wrote: On Sun, Aug 2, 2015 at 3:26 PM, John Layt j...@layt.net wrote: Yes, KLocale was in many ways the best localization library around, I and others worked hard to make it that good, but ultimately it's one that lost because it made KDE a walled garden and failed to play well with others. ICU is an ugly mess, but it's a supported, sponsored, ubiquitous mess that is the industry standard. Sometimes you just have to take a stepp backwards in order to be able to move forward. For a little bit more background on why see https://community.kde.org/KDE_Core/KLocale and https://community.kde.org/KDE_Core/Platform_11/Locale Maybe it could be worth bringing KLocale back in some limited form as an intermediate solution? People are free to liberate it from kdelibs4support and embed it themselves, but it's a lot to ship and maintain, and at the end of the day you end up with localization that doesn't match what the rest of the system does. Alternatively, do you John have any roadmap about QLocale? Perhaps we could help with filling the missing bits into QLocale directly too. The roadmap was waiting on two things: me to get motivated to work on Option 3 after burning out on the first two rejected options, and for Qt to drop Windows XP/Vista support. We can't get new Locale stuff into Qt that only works on a couple of platforms, it has to work on every platform from day 1 with some lowest common denominator of features, and Windows XP was so pathetic we couldn't do much more with it than QLocale already does. With XP/Vista gone, we can target a more useful feature set. But even once all that is implemented, I still have to convince Lars and Thiago to accept it :-) I've recently been trying to update the plan at http://wiki.qt.io/Locale_Support_in_Qt_5 for those interested, it provides a lot of background detail about what we want to do and why it has been so hard to achieve. Frankly, 18 months ago I had been looking for sponsorship to implement all this as it is a massive undertaking, but it's one of those things everyone wants to just work but no-one is interested in paying to be done right.
