I realize this is related to bug 182577, but it's different. It's one thing to say, "program x doesn't support feature y", but half-way working isn't ever good. Having a message when trying to open files >= 2 GiB works [1], but the problem is that up to < 2 GiB isn't supported and results in undefined behavior. For example, try: $ truncate -s 2G zz $ truncate -s -1 zz # or, up to about -227M $ okteta zz On my box, you can see just the selected character, and you can move around and edit and save, but it obviously doesn't work right and there's no scrollbar. Observed on 0.11.4 on 4.11.5 on (K)Ubuntu 13.10. [1] While the intent is easily understood, the message: "Support to load files larger than 2 GiB has not yet been implemented." is technically incorrect, since it appears even when the file is exactly 2 GiB. Reproducible: Always
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
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.
> 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.