https://bugs.kde.org/show_bug.cgi?id=332770
--- Comment #5 from Friedrich W. H. Kossebau <kosse...@kde.org> --- > 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. Sadly using normalized sizes (with line height factored out) does not work, at least with current basic implementation. E.g. internally QAbstractScrollArea expects the scrollbars to deliver real pixel-grid sizes (like by signal QAbstractSlider::valueChanged), and so on. Seems one would need to switch from using QAbstractScrollArea to fully implement based on a raw QWidget all the scrollbar logic oneself. Which currently also cannot be done without breaking the ABI.. And will be some bigger work, but possibly unavoidable. Comparing other implementations: GHex can cope with >2GiB files. Seems that Gtk uses gdouble for scrollbar ranges, so is not bound by signed int range. wxHexEditor can by design also cope with >2GiB files. It uses wxScrollBar, which is based around signed int. But wxHexEditor uses the range values not relative to grid pixel sizes, but relative to the amount of lines displayed on the visible area. In any case also it still is to question if it makes sense/is useful to e.g. with 2GiB and 16 bytes per line to have 134217728 lines of bytes :) Then there might be no generic rule to split up a continuous range into sections. And given the two tools mentioned above can do it, I guess one still try to achieve get that done also with okteta. So keeping the bug report open as before, Hopefully not for another 10 years. -- You are receiving this mail because: You are watching all bug changes.
