[Interest] Assertions from QQuickTableView::forceLayout()

[Patrick Stinson]

TableView.forceLayout() seems prone to throwing assertions related to internal 
data structures being out of sync with the number of rows and columns from the 
QAbstractTableModel used. Some of these assertions were fixed in 5.13.0, more 
were fixed in 5.13.1. But this one still remains:

items/qquicktableview.cpp:458:void QQuickTableViewPrivate::dumpTable() const(): 
"table cells: (4,0) -> (15,15), item count: 160, table rect: 270,0 x 1040,704"
items/qquicktableview.cpp:477:auto 
QQuickTableViewPrivate::modelIndexAtCell(const QPoint &)::(anonymous 
class)::operator()() const(): output: modelIndex: 915 cell: QPoint(15,0) count: 
915
items/qquicktableview.cpp:477:None(): ASSERT: "(modelIndex < model->count()) || 
[&](){ dumpTable(); qWarning() << "output:" << "modelIndex:" << modelIndex << 
"cell:" << cell << "count:" << model->count(); return false;}()" in file 
items/qquicktableview.cpp, line 477

In many cases this assertion happens when TableView.rows is out of sync with 
model.rowCount(), or TableView.columns is out of sync with model.columnCount(). 
The fact that these are out of sync at all seems to me to be a bug?

At any rate, this isn’t a reliable workaround. This happens most often when 
emitting columnsRemoved() from the model while the column is visible. It never 
occurs when the column is hidden, e.g. scrolled beyond the width of the 
TableView’s viewport.

Is there something I’ve missed about the TableView implementation? Or does it 
just early days yet for this QtQuick Item?

And for what it’s worth, QQuickTableView::dumpTable() was also throwing an 
assertion regarding the GL context not matching when dumping the table to a 
png. I commented out that code block to be able to see the original assertion 
above.

Cheers,
-P___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] ASSERT failure in QCocoaScreen: "The application's primary screen should always be in sync with the main display"

[Patrick Stinson]

I received this error after upgrading from 5.13.0 to 5.13.1 and disconnecting 
my external monitor from my latest-model MacBook with Mojave:

qcocoascreen.mm:557:None(): ASSERT failure in QCocoaScreen: "The application's 
primary screen should always be in sync with the main display", file 
qcocoascreen.mm, line 557

It goes away when I plug in my external monitor. Anyone have any idea how to 
fix this? Some kind of app-level cached pref for primary display? It’s not 
possible to continue working while it’s happening.

-Patrick

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QDateTime uses different time zone offset prior to UNIX epoch?

[Thiago Macieira]

On Friday, 20 September 2019 14:20:40 PDT Patrick Stinson wrote:
> QDateTime initializes with a different time zone offset when passed a QDate
> before versus after Jan 1 1970. The following line says it all:
> 
> QDateTime(QDate(1969, 10, 14)).offsetFromUtc() != QDateTime(QDate(1970, 10,
> 14)).offsetFromUtc()
> 
> It seems to me that the offsets for these two QDateTime objects should be
> equal. Otherwise, this makes initializing and storing dates difficult.
> 
> I assume this is intentional. What is the rationale for this design
> decision? Is there a workaround?

Your test is not reliable. It works for less than half the planet and for just 
over half the year.

Anyway, there's no workaround. This is done because the timezone databases are 
inaccurate before 1970. So we just return each timezone's standard time, not 
accounting for DST.

This is documented:
  The range of valid dates taking DST into account is 1970-01-01 to the
  present, and rules are in place for handling DST correctly until 2037-12-31,
  but these could change. For dates falling outside that range, QDateTime
  makes a \e{best guess} using the rules for year 1970 or 2037, but we can't
  guarantee accuracy. This means QDateTime doesn't take into account changes
  in a time zone before 1970, even if the system's time zone database provides
  that information.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] QDateTime uses different time zone offset prior to UNIX epoch?

[Patrick Stinson]

QDateTime initializes with a different time zone offset when passed a QDate 
before versus after Jan 1 1970. The following line says it all:

QDateTime(QDate(1969, 10, 14)).offsetFromUtc() != QDateTime(QDate(1970, 10, 
14)).offsetFromUtc()

It seems to me that the offsets for these two QDateTime objects should be 
equal. Otherwise, this makes initializing and storing dates difficult.

I assume this is intentional. What is the rationale for this design decision? 
Is there a workaround?

Cheers,
-Patrick

P.S. Here is my original inconclusive entry in the qt forum:
https://forum.qt.io/topic/107005/qdatetime-uses-different-time-zone-offset-prior-to-unix-epoch/6
 




___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest