Review Request: [KIO] AccessManager: the missing piece to go with 1bf9737.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101859/ --- Review request for kdelibs and Dawit Alemayehu. Summary --- Bonus question: should this go in 4.7 or master ? Diffs - kio/kio/accessmanager.cpp ef9b8ef Diff: http://git.reviewboard.kde.org/r/101859/diff Testing --- Thanks, Pierre
Re: Translation in Qt5
On Tue, Jul 05, 2011 at 11:04:41AM +0200, Chusslove Illich wrote: [: Oswald Buddenhagen :] - the class names cause many messages to be duplicated This is exactly the reason I was afraid someone had put out :) It basically reveals that they care zero about context. It shows you... On that it depends whether those who complained would want to compensate. sure they do - even if they don't know yet. the contexts were trying to automate disambiguation.[...] ...that they weren't seriously thinking about disambiguation at all. that's not entirely fair or even accurate. for one, i was talking about duplicated messages which positively do *not* need disambiguation (otherwise the argument would be bogus in the first place). second, it isn't too surprising that many people didn't think about alternatives, given that the automatic contexts are there, even if they do a rather poor job at disambiguating in a semantically meaningful way. I really would like it to be a library on its own, precisely so that I could use it and recommend it out of KDE (as in KDE project/community) and Qt apps. that won't fly. the current library's qt integration both improves its usefulness and makes its implementation much more lightweight. In fact, the hardest thing about that library is designing how it should interface and behave. yes, exactly. this is a typical case for shared specification, not shared code. - the ongoing basic feature duplication puts kde into a bad light There is already Linguist and raw Gettext. That already makes for duplication, unless Qt switches to raw Gettext, i mean duplication within the qt ecosystem. it would be a somewhat poor outcome for kde's qt-addon-ification effort if it doesn't manage to upstream something as core as i18n. - it fragments the qt ecosystem regarding translations. the communities translating qt and addons would have to deal with two systems. Not entirely. [...] I will personally go in and hack it to do the TS-PO-TS roundabout, so that KDE (as in KDE Translation Project) translators do not feel Linguist workflow. that's only half the problem. one also needs to contribute translations to qt upstream, and within the legal framework of the qt contribution model, there is no way around the translators dealing with whatever system qt chooses to use. fwiw, there have been thoughts of detaching the qt translation project from the qt contribution model. not sure about the licensing model; whether lgpl-only would be acceptable. - it deprives qt essentials themselves and addons apps which want to depend only on the essentials from having a reasonable translation system. Linguist is a *reasonable* translation system. ok, let's amend that. it deprives (apps libs using only) qt essentials from being being really well translatable. the dualism you are suggesting makes no sense even for qtcore itself - it has both high-quality community translations and crappy commercial translations out of need for nokia devices. consequently we need a system which serves both target groups, without noteworthy compromises on either side. It is better than anything other than raw Gettext/PO. When TS-PO-TS roundabout is present, they become equivalent[1]. [1] Just please add per-file plural formulas. They can be optional, with fallback to hardcoded default if missing. i already did that. in fact, (i think) i fixed all problems you pointed out in your last review round. and just for fun, the PO-TS-PO roundtrip should be lossless as well. in theory, you can directly open PO files in linguist (in practice, it often does not work due to TS having no representation for PO's #~|). the one thing that is not compatible are the plurals. during the TS-PO coversion, i simply duplicate msgid into msgid_plural (i wonder whether an empty string would work instead?). on the way back, i drop identical plural sources, while differing ones are stored in an extension field (which is displayed by linguist, but is otherwise meaningless to the system). on top of that, the plural formulas are inherently incompatible (linguist adds and preserves gettext ones, but cannot use them in any meaningful way). so while using PO is feasible for transporting qt translations, it isn't really native and thus would be a suboptimal choice for a default format given the current state of affairs. it's all about determining priorities and making choices now.
Re: Translation in Qt5
On Tue, Jul 05, 2011 at 05:09:38PM +0200, Chusslove Illich wrote: [: Oswald Buddenhagen :] if one defines that KUIT is a superset of qt rich text, there is not even a theoretical problem with it. But KUIT is supposed to be transformable into different target formats, of which Qt rich text is one? (The other currently is plain text, and I've reserved a slot for shell color sequences.) that doesn't matter. you can restrict the set of allowed tags per output format. it's only important to recognize meaningful markup and reject anything malformed. in the case of rich text output you can break out of the theory and do pass-through of everything which is not for you - at the risk of allowing stuff which will later break. First, some people really didn't like that semantic markup was thrown onto everyone, without possibility to disable it. This was mostly due to need to care about escaping. i'm not overly concerned. i'm sure somebody will complain if i make the new formatter reject %blubb (requiring %%blubb) instead of silently passing it literally, despite this being a very sane thing to do. The second problem is escaping and substitution. I tried briefly with auto- escaping, got regression reports in about a month, had to disable it. well, of course *something* would regress when you change something so fundamental. the answer is the per-placeholder possibiliy to disable auto-quoting: qTr(foo: %1 is %q2) % foo % bar; (q as in pre-Quoted) note that this quoting problem is not specific to semantic markup in any way. The third problem [...] When you have fixed semantic markup, there is the problem of set of tags. [...] So I went with a small set, and even myself am now not very happy at the choices I made. well, yeah. importantHighlight(i18n(Uses of) + ) + nodes[1] + importantHighlight( + i18n(from) + ) + nodes[0] + hr; that's easy ... qTr(m1Uses of /m1 %1 m1 from /m1 %2hr).markup(strong) % nodes[1] % nodes[0]; did you have something like that in mind? so in summary, you think we *should* go for semantic highlighting if the problems can be adequately solved, yes?
Re: Date/Time in KF5 / Qt5
On Wednesday 06 July 2011 18:26:16 Sean Harmer wrote: Hi, On 29/06/2011 20:54, John Layt wrote: Duration: A number of Qt community members have a merge request for this already, but I feel it needs some clean-up. It would be great if an experienced KDE eye could look at this as it is likely to end up in Qt5. Lars Knoll has now given some more feedback on this MR which we are now trying to address. Hopefully it will be up to scratch for inclusion shortly. Can you provide a URL for this? Duration should allow for daylight savings time changes when it is specified in terms of days. Even if the Qt class doesn't do this itself, it needs to make the appropriate methods virtual to allow us to override them. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm signature.asc Description: This is a digitally signed message part.
Re: Date/Time in KF5 / Qt5
On 06/07/2011 18:54, David Jarvie wrote: Can you provide a URL for this? Duration should allow for daylight savings time changes when it is specified in terms of days. Even if the Qt class doesn't do this itself, it needs to make the appropriate methods virtual to allow us to override them. Thiago already answered about DST in durations but here is the URL for the merge request: https://qt.gitorious.org/qt/qt/merge_requests/1014 Cheers, Sean -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Date/Time in KF5 / Qt5
On Wednesday 06 July 2011 19:52:50 Thiago Macieira wrote: Em Wednesday, 6 de July de 2011, às 18:54:37, David Jarvie escreveu: On Wednesday 06 July 2011 18:26:16 Sean Harmer wrote: Hi, On 29/06/2011 20:54, John Layt wrote: Duration: A number of Qt community members have a merge request for this already, but I feel it needs some clean-up. It would be great if an experienced KDE eye could look at this as it is likely to end up in Qt5. Lars Knoll has now given some more feedback on this MR which we are now trying to address. Hopefully it will be up to scratch for inclusion shortly. Can you provide a URL for this? Duration should allow for daylight savings time changes when it is specified in terms of days. Even if the Qt class doesn't do this itself, it needs to make the appropriate methods virtual to allow us to override them. There will be no virtuals in date-time or timespan classes. You don't need to override anything. It's not like you will ever need to extend the concept of date, time or timespan: dates are the same for all applications. Duration is simply the number of seconds or milliseconds between two dates, appropriately given in their universal time. So duration is not affected by daylight savings. Duration must record whether it was specified in terms of hours/minutes/seconds, or days/weeks/whatever so that daylight savings changes can be taken into account when calculating the end time of a duration, given a start time. If the duration class provides methods to calculate the end time, given a start time, then it must take account of daylight savings changes. See kdepimlibs/kcalcore/duration.h for example. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm signature.asc Description: This is a digitally signed message part.
Re: Date/Time in KF5 / Qt5
On Wednesday 29 June 2011 20:54:48 John Layt wrote: Hi, This is the second email in the series of three looking at KLocale in Frameworks 5. This email covers Date/Time, so I have also cc'ed the PIM mailing list for their input. As with QLocale, the lack of features in QDateTime has forced KDE to create our own solutions such as KDateTime, KLocalizedDate and KCalendarSystem at the cost of interoperability with pure-Qt code. In KF5/Qt5 I want to work to resolve this problem by implementing full support for our required features in Qt. The discussions held at QtCS were very promising on being able to achieve this. You can find the notes at http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/QDateTime Time Zones: A feature everyone wants but no-one seems to have the expertise or time to do. The general consensus was that a new QTimeZone class was required to be embedded in QDateTime with an api based around the Unix/Olsen time zones, but using the host platform time zone system in the background. This is the same concept as KTimeZone so should meet our requirements. I'll be trying to co-ordinate this, but I need people to step up and take on the implementation. Ideally the authors of our time zone support will be willing to port their own code over, or at least review other peoples code submissions. If not all the most advanced time zone features of KDateTime are accepted we can probably put them into a support class. Hi John, Sorry for not replying sooner. I don't have time to take on the work of implementing this, but in any case, I don't think that I'd want to contribute significant new code to Qt unless the licence was purely (L)GPL, or unless (and I wouldn't have time even in that case) I was paid for it. I would be willing to review other people's code, though. Cheers, -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm signature.asc Description: This is a digitally signed message part.
Re: Date/Time in KF5 / Qt5
On 06/07/2011 21:18, David Jarvie wrote: On Wednesday 06 July 2011 21:10:06 Thiago Macieira wrote: Em Wednesday, 6 de July de 2011, às 20:54:54, David Jarvie escreveu: Duration is simply the number of seconds or milliseconds between two dates, appropriately given in their universal time. So duration is not affected by daylight savings. Duration must record whether it was specified in terms of hours/minutes/seconds, or days/weeks/whatever so that daylight savings changes can be taken into account when calculating the end time of a duration, given a start time. If the duration class provides methods to calculate the end time, given a start time, then it must take account of daylight savings changes. See kdepimlibs/kcalcore/duration.h for example. That's not what QTimeSpan is supposed to be. It's simply a quantity of seconds. Ok. Being more limited, it won't be a suitable replacement for KCalCore::Duration. I would need to take a closer look at KCalCore::Duration but from what you have said it should be very simple to implement an equivalent to it in terms of QTimeSpan given that a duration is a fixed quantity (within an inertial frame). QTimeSpan has the facility to specify a start datetime and to calculate the end of the span but where it would fall short is the representation of that end time if it lies in a period of daylight savings different to the start time. QDateTime simply stores a QDateTime as the optional start (or end time if the span is negative) and the duration in milliseconds as a qint64. It was meant as a simple convenience class for cases like displaying a label with Download has x:y remaining or for working with datetime mathematical operations analogous to QRect for e.g. All the best, Sean -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Date/Time in KF5 / Qt5
Em Wednesday, 6 de July de 2011, às 22:54:39, David Jarvie escreveu: I've added a comment to the merge request suggesting that instead of a reference date/time, the units in which the time span was specified should be stored in the class. That way, daylight time changes could be catered for easily (by external classes), and also time spans of months or years would work intuitively when applied to any start date. Basically, I think that the class has taken the wrong approach, and could be made much more generally useful with a simple change in the way it does things. I think the class is fine. It was supposed to be a glorified way of storing a qint64 milliseconds and converting from that to a count of days, hours, minutes and seconds. This class was added so that people could format their timespans. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
