https://bugs.kde.org/show_bug.cgi?id=332770
Friedrich W. H. Kossebau <kosse...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|REPORTED |CONFIRMED
--- Comment #4 from Friedrich W. H. Kossebau <kosse...@kde.org> ---
Thanks for the bug report, sadly as actual developer never got around to look
closer at it all the years. Also as the lack of proper support for really large
file has been a pain point which I hesitated to look closer at to not sadden
myself.
Can confirm your observations.
First investigations show that the problem is caused by
QAbstractSlider/QScrollBar only supporting int types for min & max values.
While the calculations to estimate the size of the viewport are based on number
of lines of the bytes and the line height, which for such large files then
happen to go beyond signed integer range. With the current max supported file
size they go into negative values, resulting in hidden scrollbars but also
other rendering relying on those now negative numbers going off screen.
Possibly, given 2 GB are for now the max files size, relying on the lineheight
being constant, that one can be factored out of size & rendering calculations,
so one is back to range of sized integers. Will see to explore that next.
For the future and support of > 2 GB sizes, seems the Qt UI classes won't
support the concept of a continuous range display, as currently done. Which
might not be the best approach anyway. But what UX to use for very large files
is not yet researched in any case with Okteta (ideas very welcome).
Sidenote:
while playing around I also learned that QByteArray::resize() actually throws
an exception if it cannot assure the requested size. Resulting crash to be
fixed as well (already testing patch), to at least prevent data loss with other
opened files.
--
You are receiving this mail because:
You are watching all bug changes.
