Replacement for KDateTime
Hello, the kdepim is discussing how we can replace KDateTime inside kdepim (primarly kcalcore) . There are some issues, why we can't replace it simply with QDateTime. * indivual timezone support, this is something that we need when parsing ical and have no known timezone information. I havn't looked into it, but I think this can make it eventually into QDateTime. * dateOnly support is used a lot. In ICAL it differs if you set dateonly or datetime. dateonly events f.ex. lasts a day without timezone info f.ex. New Year is a dateonly event that lasts one day - it everywhere startsat 1. january at 0:00 o'clock and ends at 24:00 o'clock in your current timezome. So it a different UTC time for every place at the world. That's why you can't replace it with a datetime event, that needs a timezone, so it would be wrongly displayed at other timezones. The core problem is with that that QDateTime is invalid if either the date or the time is invalid. KDateTime is valid also with invalid time. And this is behaviour change cannot go into QDateTime, that's why we need anything to replace KDateTime. The solutions we are were came along at akademy: * using QDateTime in a inalid way and check on our own if timedate are valid - This approch would lead to many errors, because every application must be aware, that qdatetime is used in a strange way * split the API everywhere into date and time members/functions - makes it much more worse to use the API, because you have to request everytime both elements. * keep KDateTime and transform it to an own framework - this is a very big overhead for only one feature As midterm solution we came up to split KDateTime to an own lib inside kde4support, so that we can acctually get rid of linking to every other lib, that would help to make the start faster and the memory footprint smaller. Nothing is hammered in stone and I want to start a disscussion, maybe others have good suggestions how we can solve this issues. Just for clearifing it- it is only a discussion about how we should transform the public API of kcalcore. Regards, sandro PS: I had a very nice time attending the akademy!
Re: RFC: KDE Bugzilla Bugs Expiration
On Saturday 01 August 2015 03:09:14 Kevin Kofler wrote: Christoph Cullmann wrote: I think one of the problems with our current Bugzilla database is that it contains a lot of old bugs and wishs. As the manpower is limited and we sometimes not even keep up with the incoming new bugs, might it be a good idea to adopt a similar strategy like the Qt Project and expire bugs that got not changed since more than one year? The idea would that a scripts closes all bugs that have no activity in the last year e.g. on a weekly basis and the closing comment would contain some gentle note that if the bug is still an issue, the reporter (or any person on CC) can just reopen it again. I think this would make a lot of time consuming bug triaging much easier. IMHO, KDE (as in, everything that uses bugs.kde.org) is too large a project with too different release cycles and maintainership for it to make sense to do this with global scripts. Keep in mind that 1. bugs.kde.org is used by much more than just the former KDE SC and 2. even that SC has now been split into 3 parts (Frameworks, Plasma, Applications) on different release schedules. Different policies make sense for different applications. So this should be done with per-application scripts. I would also strongly argue for keeping this manual for all applications whose maintainer(s) didn't explicitly opt in to such an autoclosing policy. Which would be completely fine and also agrees with the initial proposal: If an application / component should not be auto-cleaned-up, then we could blacklist it (or the other way round, whitelist). The proposal doesn't come out of nowhere: KDE has this issue for years already, and for the qt-project this solution works quite well it seems. Greetings, Dominik
Re: Replacement for KDateTime
On Sun, Aug 2, 2015 at 3:26 PM, John Layt j...@layt.net wrote: If you do this you also need all of KLocale again which we also do not want. Don't even go there, we changed it for a purpose. Fwiw, over the year(s) of Plasma5, many times it was expressed that KLocale is greatly missed, especially when it comes to date/time formatting. QLocale just doesn't cut it and the digital clock applet is doing many tricks to get the stuff formatted as wanted. The biggest downside is that it applies to the clock applet only, so there can't be a single system-wide Use 24h-clock format switch. Clock in panel can/will be 24h format while everything else will be LC_TIME format (time stamps in Dolphin eg). There are some other examples where KLocale was missed in Plasma but I can't remember which ones that was right now, maybe someone will fill it. Maybe it could be worth bringing KLocale back in some limited form as an intermediate solution? Alternatively, do you John have any roadmap about QLocale? Perhaps we could help with filling the missing bits into QLocale directly too. Cheers -- Martin Klapetek | KDE Developer
Re: Replacement for KDateTime
On 1 August 2015 at 19:47, Sandro Knauß b...@sandroknauss.de wrote: * indivual timezone support, this is something that we need when parsing ical and have no known timezone information. I havn't looked into it, but I think this can make it eventually into QDateTime. This is the real problem and the biggest stumbling block,and I'm sorry I haven't had the time to come up with a solution as promised. I'll try sort it out in the next week or so. It was something I wanted in QTimeZone but it was far to complex to get in the first version., or indeed maybe ever. I need to see if there's a way we can derive our own support separate to Qt. * dateOnly support is used a lot. In ICAL it differs if you set dateonly or datetime. dateonly events f.ex. lasts a day without timezone info f.ex. New Year is a dateonly event that lasts one day - it everywhere startsat 1. january at 0:00 o'clock and ends at 24:00 o'clock in your current timezome. So it a different UTC time for every place at the world. That's why you can't replace it with a datetime event, that needs a timezone, so it would be wrongly displayed at other timezones. I've been over this before on the PIM list, it's a fundamental mistake to say that 'Date Only' is an attribute of the datetime, it is in fact an attribute of the Event itself, and indeed is in the current API as such. I fail to see why it needs to be in the datetime as well? If there is anywhere using the datetime property instead of the Event property it is doing it wrong, make it check the Event instead. Do not put it back in the datetime. Use the datetime to represent the valid start time or endtime of the all day event, i.e. 00:00 in the time zone of the datetime on which the event starts or finishes. * keep KDateTime and transform it to an own framework - this is a very big overhead for only one feature You do *not* want to do this, we specifically got rid of KDateTime to be compatible with Qt and other apps using Qt to attract new users and devs. If you do this you also need all of KLocale again which we also do not want. Don't even go there, we changed it for a purpose. If you plan to release KCalCore as a Framework, then it must be free of KDateTime and KLocale in the API, otherwise no-one else can use it and you're locked-in with a bad API. John.
Re: Replacement for KDateTime
On Sunday 02 August 2015 17:08:04 Martin Klapetek wrote: On Sun, Aug 2, 2015 at 3:26 PM, John Layt j...@layt.net wrote: If you do this you also need all of KLocale again which we also do not want. Don't even go there, we changed it for a purpose. Fwiw, over the year(s) of Plasma5, many times it was expressed that KLocale is greatly missed, especially when it comes to date/time formatting. QLocale just doesn't cut it and the digital clock applet is doing many tricks to get the stuff formatted as wanted. The biggest downside is that it applies to the clock applet only, so there can't be a single system-wide Use 24h-clock format switch. Clock in panel can/will be 24h format while everything else will be LC_TIME format (time stamps in Dolphin eg). If the format you're looking for is in the CLDR, you're welcome to add the support to QLocale. If the format you're looking for requires support from translators, please add a new class to QtCore. 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: -- 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 Sunday 02 Aug 2015 14:26:18 John Layt wrote: On 1 August 2015 at 19:47, Sandro Knauß b...@sandroknauss.de wrote: * dateOnly support is used a lot. In ICAL it differs if you set dateonly or datetime. dateonly events f.ex. lasts a day without timezone info f.ex. New Year is a dateonly event that lasts one day - it everywhere startsat 1. january at 0:00 o'clock and ends at 24:00 o'clock in your current timezome. So it a different UTC time for every place at the world. That's why you can't replace it with a datetime event, that needs a timezone, so it would be wrongly displayed at other timezones. I've been over this before on the PIM list, it's a fundamental mistake to say that 'Date Only' is an attribute of the datetime, it is in fact an attribute of the Event itself, and indeed is in the current API as such. I fail to see why it needs to be in the datetime as well? If there is anywhere using the datetime property instead of the Event property it is doing it wrong, make it check the Event instead. Do not put it back in the datetime. Use the datetime to represent the valid start time or endtime of the all day event, i.e. 00:00 in the time zone of the datetime on which the event starts or finishes. 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). 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)? In order to use QDateTime in the representation of date-time or date-only values, the best solution in my opinion would be to have a new date time class which contains a QDateTime member together with a bool member indicating whether it is date-only. For a date-only value, the time component of the QDateTime should be set to 00:00:00, to avoid the problem of what an invalid value indicates. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: [Development] Please help me get my pending review count down
On Sunday 02 August 2015 13:46:02 Christoph Cullmann wrote: Hi, is one of the problems the misuse of QDBus in KUniqueApplication before the actual QApplication is constructed? That's the working theory, but it's not proven. All I know is what Albert reported when I asked him to test my patches in a KF5 environment and a Unity one. Would it be possible to just create in that case a temporary QCoreApplication on the stack in KUniqueApplication::start? QtDBus is supposed to work with construction, destruction and reconstruction of QCoreApplication. I think I have tests for that, but I would be surprised if you found a few cobwebs. Kate had similar I get stuck problems until the QApplication was correctly constructed in all cases before the first QDBus use. That's one of the things I fix in this patchset by moving the socket handling to another thread. However, I think I forgot to include the patches that change QCoreApplication event delivery and creates the QDaemonThread class... QDBusConnectionManager isn't using QDaemonThread, but delivery of events when QCoreApplication isn't extant relies on those patches. ... which makes me wonder: did I fix the problem but never gave Albert the patches that fixed them? -- 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: [Development] Please help me get my pending review count down
Hi, is one of the problems the misuse of QDBus in KUniqueApplication before the actual QApplication is constructed? Would it be possible to just create in that case a temporary QCoreApplication on the stack in KUniqueApplication::start? Kate had similar I get stuck problems until the QApplication was correctly constructed in all cases before the first QDBus use. Greetings Christoph - Ursprüngliche Mail - On Wednesday, July 29, 2015 11:03:15 AM Martin Klapetek wrote: On Wed, Jul 29, 2015 at 11:47 AM, Marc Mutz marc.m...@kdab.com wrote: On Wednesday 29 July 2015 09:04:42 Martin Klapetek wrote: Can you perhaps create a single diff against 5.5/dev/master which could be easily applied? That should make things much easier to help :) Assuming you're talking about the dbus changes, wouldn't you actually want to cherry-pick them one by one and see which one breaks? Perhaps that should be done as well, yes, although Thiago requested the /whole set of changes/ to be tested: I need someone to take the whole set of changes, apply to their Qt 5.5 build and test KF5-powered applications to see what gets broken and why. Please provide patches to either QtDBus, KF5 or the applications. Which would be much simpler with a single diff. Gerrit gives you a git command to copy'n'paste and you can pull the changeset and test it. That's much better than manually applying some plaintext diff. Bye -- Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: RFC: KDE Bugzilla Bugs Expiration
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. Regards, Ingo signature.asc Description: This is a digitally signed message part.
