SUMMARY Okteta show empty HEX-dump area. If open any file, or create new random data, the basic HEX-dump area is empty. No any byte, full clear. At console writing errors: QPainter::begin: Paint device returned engine == 0, type: 2 QPainter::setPen: Painter not active QPainter::setBrush: Painter not active QPainter::setFont: Painter not active QPainter::setPen: Painter not active QPainter::end: Painter not active, aborted STEPS TO REPRODUCE 1. Open Okteta 2. File - New - Random Data - 256byte - Create 3. Show empty area with header "New Byte Array" OBSERVED RESULT Empty HEX-dump area EXPECTED RESULT HEX-dump area with bytes SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian Linux 11 Stable Qt Version: Using Qt version 5.15.2 in /usr/lib/x86_64-linux-gnu ADDITIONAL INFORMATION If touch ZOOM slider, as random result, okteta show HEX-bytes with VERY BIG FONT. In console show message: kf.xmlgui: Index 10 is not within range (0 - 9 ) Next, this slider may be changed font size, may be not. If changed, in min position font size show as ~48pt in LibreOffice, in max position as ~110pt. It both too big. It is impossible to work with this programm.
Thanks for the report. Though 0.26.5 is an outdated version, the latest is 0.26.11 just released last week, which should work with the same requirements as 0.26.5., the latest on the bug fix releases for 0.26. So please first try to update to 0.26.11 and check for the bugs you experienced again. "Paint device returned engine == 0" hints that something is broken in the Qt setup with your system, nothing that Okteta does control (and should control). That might also explain why no content is rendered. Never seen that log output before. Please compare other Qt-based programs. "kf.xmlgui: Index 10 is not within range (0 - 9 )" should be gone since 0.26.9, BTW :)
One thing to try perhaps is another system font for fixed size fonts. Okteta uses the font as Qt reads from the platform plugin. In case of Plasma, that would be configured in the Systemsettings > Appearance > Fonts. What desktop environment are you using?
Notes for self/developer: "QPainter::begin: Paint device returned engine == 0, type: 2" here the type 2 seems to be "Pixmap" from QInternal enum PaintDeviceFlags. Okteta uses a QPixmap for caching the cursor (gui/cursor.cpp). Forcing that QPixmap to be an 0x0 QPixmap results in the same log as reported: QPainter::begin: Paint device returned engine == 0, type: 2 QPainter::setPen: Painter not active QPainter::setBrush: Painter not active QPainter::setFont: Painter not active QPainter::setPen: Painter not active QPainter::end: Painter not active, aborted The size of the pixmap is calculated from args PixelX Width, PixelY Height, qreal devicePixelRatio, where the width & height are taken (indirectly from the QFontMetrics of the fixed size font. And devicePixelRatio is taken from the widget (Qt). The latter being 0 would fail elsewhere I assume, so a working theory here would be that either of or both the maxWidth() and height() have a value of 0, perhaps due to broken font metadata. So the font having some (unexpected) 0 values might explain the experienced display. Testing with other fonts for the system fixed size/width font might help to confirm that theory.
(In reply to Friedrich W. H. Kossebau from comment #2) > What desktop environment are you using? I'm using LXDE 11
(In reply to xintrea from comment #4) > I'm using LXDE 11 Not exactly sure which platform integration plugin Qt uses to read the system/platform configuration with that environment, seems people even can select different ones. To see which font actually is used, please see to have qtdiag installed. Then on the command line have the tool print its info into a textfile: $ qtdiag > qtdiag.txt Then open qtdiag.txt in a text editor and search for "Fixed font". What does it have for you? Here for comparison the lines I get --- 8< --- Fonts: General font : "Droid Sans" 10 Fixed font : "Droid Sans Mono" 10 Title font : "Droid Sans" 10 Smallest font: "Droid Sans" 8 --- 8< --- What font is listed there for you with "Fixed font"? To configure another fixed-width/monospace font on your system to try to find if that is the cause, with LXDE you might need to edit the fontconfig settings. No own experience with that, please get support from LXDE community on that. They might also know how to configure things for Qt-based applications and perhaps lend a hand with the fixedwidth/monospace font. Okteta itself simply relies on the Qt platform abstraction and tries to integrate by using whatever the system/environment has configured, as provided by the Qt platform integration plugins.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!