On Tuesday 04 August 2015 17:52:18 Ben Cooksley wrote:
> 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?
Right.
If a LC_TIME solution isn't possible, we could consider a QSystemLocale
configuration t
On Tue, Aug 4, 2015 at 8:57 AM, John Layt wrote:
> On 3 August 2015 at 07:33, Martin Klapetek 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
On Monday 03 August 2015 22:00:04 John Layt wrote:
> On 3 August 2015 at 20:07, David Jarvie 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 inv
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 conf
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 t
Git commit d9a6ce124ee6ece84e6af4c741f2ad0ed2599928 by David Faure.
Committed on 03/08/2015 at 23:23.
Pushed by dfaure into branch 'master'.
KDBusService: document how to raise the active window, in Activate()
CCMAIL: kde-core-devel@kde.org
M +3-0src/kdbusservice.h
http://commits.kde.o
On 3 August 2015 at 19:58, David Jarvie 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
[Again resend from subscribed account, damn gmail!]
On 3 August 2015 at 19:03, Thomas Lübking 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 (
On 3 August 2015 at 19:03, Thomas Lübking 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
On 3 August 2015 at 20:07, David Jarvie 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 va
On 3 August 2015 at 07:33, Martin Klapetek 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
On 2 August 2015 at 19:32, 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 e
[Reply sent again from subscribed account]
On 2 August 2015 at 16:08, Martin Klapetek wrote:
> On Sun, Aug 2, 2015 at 3:26 PM, John Layt 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 be
On 2 August 2015 at 16:08, Martin Klapetek wrote:
> On Sun, Aug 2, 2015 at 3:26 PM, John Layt 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
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 havi
On Monday 03 Aug 2015 18:22:28 you wrote:
> 2015-08-03 17:33 GMT+03:00 David Jarvie :
> > On Monday 03 Aug 2015 14:29:41 Dāvis Mosāns wrote:
> >
> >> 2015-08-03 15:26 GMT+03:00 David Jarvie :
> >
> >> > On Monday 03 Aug 2015 12:59:59 you wrote:
> >
> >> >
> >
> >> >> 2015-08-02 21:32 GMT+03:00 Davi
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 sepa
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 nonsens
On Mon, Aug 3, 2015 at 6:34 PM, Thiago Macieira 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 abo
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 fo
On Monday 03 Aug 2015 14:29:41 Dāvis Mosāns wrote:
> 2015-08-03 15:26 GMT+03:00 David Jarvie :
> > On Monday 03 Aug 2015 12:59:59 you wrote:
> >
> >> 2015-08-02 21:32 GMT+03:00 David Jarvie :
> >
> >> >
> >
> >> > Date-only KDateTime instances are not only used for Event start/end
> >> > timestamps
On Monday 03 Aug 2015 12:59:59 you wrote:
> 2015-08-02 21:32 GMT+03:00 David Jarvie :
> >
> > 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-on
- 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. Feel
On Mon, Aug 3, 2015 at 9:19 AM, Ingo Klöcker 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 t
24 matches
Mail list logo
