Dear BogDan,
Thank you for the 2 regressions being fixed.
Should the fixes appear in 5.5.1?
Sorry to bother you but it seems that the issue with QProgressDialog
wasn't treated:
QTBUG-47049
[REG 5.4 -> 5.5] QProgressDialog is Shown Immediately After Allocation
and Even Despite hide() Call.
Thank
On Monday 03 August 2015 07:31:51 Robert Knight wrote:
> Follow-up question - if a data type is a union of a pointer and some
> other representation, can it be stored in a QVariant without
> transitioning to the allocated version?
Irrelevant. You're not storing that type. You're storing the QDateT
On Monday 13 July 2015 14:48:40 Thiago Macieira wrote:
> This test began failing about a week ago, for no apparent reason. I don't
> think it's a Qt issue, but more of a CI issue.
>
> It's failing on:
>
> FAIL! : tst_QMimeDatabase::initTestCase() 'm_temporaryDir.isValid()'
> returned FALSE. ()
>
Follow-up question - if a data type is a union of a pointer and some
other representation, can it be stored in a QVariant without
transitioning to the allocated version?
On 3 August 2015 at 03:39, Thiago Macieira wrote:
> On Monday 03 August 2015 03:23:44 Mark Langezaal wrote:
>> On 2015-08-01 23
On Monday 03 August 2015 03:23:44 Mark Langezaal wrote:
> On 2015-08-01 23:51, Thiago Macieira wrote:
> > QDateTime API accepts the offset from UTC in seconds, but all existing
> > timezones are multiples of a quarter hour. With a range from -12 to
> > +13.5, we
> > need ceil(log((13.5 + 12) * 4)
On 2015-08-01 23:51, Thiago Macieira wrote:
> QDateTime API accepts the offset from UTC in seconds, but all existing
> timezones are multiples of a quarter hour. With a range from -12 to
> +13.5, we
> need ceil(log((13.5 + 12) * 4) / log(2)) = 7 bits for the timezone.
> With the
> one bit for t
On Sunday 02 August 2015 10:04:36 Thiago Macieira wrote:
> How often do people construct a QDateTime containing only a QDate as a
> stepping stone to a full QDateTime? Note that the QDateTime constructor
> containing a QDate sets a valid time; you can only get valid date and null
> time if you u
On Sunday 02 August 2015 01:24:50 John Layt wrote:
> [Reply to list this time...]
>
> This could work, as Qt::LocalTime / Qt::UTC / Qt::OffsetFromUtc don't
> actually create or use QTimeZone for anything (at least not yet,
> LocalTime may yet). I'm assuming dates outside the 1970-4207 year
That w
