QHexView 5.0 Development

[Dax89]

QHexView 5.0 is now under development! The widget is almost rewritten from scratch in order to keep its codebase as simple as possible.
I'm interested to listen all feedbacks here in order to create the best release as possible (if anyone is interested, of course!).

The current widget's appearance is this one:

Changes:

• QHexView doesn't use hardcoded colors anymore, but it relies on QPalette
• It's possible to customize (almost entirely) the widget with the new QHexOptions class
• It's possible to create columns with groups 1, 2, 4, 8, etc bytes
• Replaced the blinking cursor with a fixed one
• Configurable scroll speed (through QHexOptions)

Known Bugs/Missing Features:

• Mouse input can be improved
• Selection highlighting can be improved
• Horizontal scroll is not implemented

Wants:

• Qt 5.6 support (someone asked for it)
• Keep C++11 as minimum target
• Windows support (I work in a Linux environment, but I can test it on WIndows too)
• Restore highlighting support
• Restore comments/notes support
• More?

Branch Link: https://github.com/Dax89/QHexView/tree/5.0

Sample code

//The second argument is a QHexOption
QHexDocument* doc = QHexDocument::fromFile<QMemoryBuffer>("/home/davide/Programmazione/Cavia.exe", { }, this);
doc->setGroupLength(2); // Default is 1, see options here: https://github.com/Dax89/QHexView/blob/5.0/document/qhexoptions.h
ui->hexView->setDocument(doc);

@audetto @T-640 @neomissing @aerosoul94

If you are not interested, feel free to ignore this notification/email!

[T-640]

Excellent, and thanks for notification as well!

Here is what I can report so far from version downloaded yesterday:

1. Rendering is messed up, take a look:

This happened on Windows 11, on high DPI (2880x1800) display. Not sure if that matters, but the old version works fine on this system.

2. If QWidget::show is called and QHexDocument is not set for the widget a crash occurs.

3. qhexutils.h and qhexutils.cpp are not included in the .pri file.

4. The lines separating columns are gone, could you bring them back please? They could be another optional feature. And there also could be an option to style them like it is done for QFrame's VLine shape (plain, raised, sunken styles), take a look at screenshot in QFrame's documentation - https://doc.qt.io/qt-5/qframe.html

5. Highlighting is restored and appears to be functional, so you might want to remove it from the "to do" list above. Also I see that it has a higher level API now, with functions like QHexMetadata::setBackground it is much more convenient to use, well done!

6. The API has become more terse, which is good of course. The only renamings I am not sure about are from QHexView::hexCursor and QHexView::hexDocument functions, I believe just the "cursor" and "document" should be enough because:

• Anyone can see in the header file that they return QHexCursor and QHexDocument, so adding an extra "hex" in function names seems to be redundant;
• It is obvious from the context what kind of cursor and document is being dealt with here. What else could that be? Are you concerned about confusion with similar functions of QTextEdit? I don't think that there is a problem here.

Porting to the new version was easy, so once that rendering issue is fixed I think I will be ready to use QHexView 5.0 full-time.

[Dax89]

1. I will investigate this issue: it doesn't happen on my Windows 10 VM
2. Fixed
3. Added qhexutils.h and qhexutils.cpp files in .pri file
4. Restored as separator option (in QHexOptions), it's also possible to change the color: currently is drawn as a simple QPainter's line.
   It's also possible to use a QFrame's VLine as you asked, but we lose the ability to change its color, even the styles (Plain, Raised and Sunken) doesn't seems to be honored for VLine/HLine
5. Done
6. I can change that, but a cursor method already exists because QWidget implements that and QHexView hides that one.
   A possible solution is to remove hexCursor from QHexView and rename hexDocument as document,

Thanks for the feedback!

[T-640]

A possible solution is to remove hexCursor from QHexView

Pubic access to QHexCursor from QHexView is needed to at least being able to switch modes. Removing would make sense if you can completely hide QHexCursor within QHexView's implementation, and add functions like QHexView::setCursorMode to relay calls to the underlying cursor. But QHexCursor has more than a dozen public functions, so adding all these 'proxy' functions would likely clutter QHexView's own API.

So I'd say if you come up with a way to hide QHexCursor in QHexView go for it, if not let the "hexXXX" names stay for consistency then.

[T-640]

Update on the rendering issue:

Tested on an older notebook (Windows 10, 1366x768 display), messed up there as well. Old version works fine on that machine.

Try changing display resolution of your virtual machine, perhaps you have accidentally hardcoded some value that happens to work for you particular resolution?

[Dax89]

I need two informations (so I can try to reproduce this issue):

• The font selected by the widget
• It might be useful to know the Qt version

I've tried to change the resolution and used different fonts, I can't reproduce it.

[T-640]

Qt version is 5.14.2.

The result of this (on Windows 11):

qDebug () << hex_view.font() << QFontDatabase::systemFont(QFontDatabase::FixedFont);

is

QFont(Courier New,9,-1,2,50,0,0,0,0,0) QFont(Courier New,9,-1,2,50,0,0,0,0,0)

Let me know if you need font results from the other Windows 10 machine.

[T-640]

Looks like I found the fix for this.

The issue is in QHexView::renderDocument, in this block:

QHexView/qhexview.cpp

Lines 206 to 219 in 34e1dcb

	// Hex Part
	for(auto column = 0u; column < this->options()->linelength; )
	{
	QTextCharFormat cf;
	for(auto byteidx = 0u; byteidx < this->options()->grouplength; byteidx++, column++)
	{
	QString s = linebytes.isEmpty() || column >= static_cast<qint64>(linebytes.size()) ? " " : QHexUtils::toHex(linebytes.mid(column, 1)).toUpper();
	quint8 b = static_cast<int>(column) < linebytes.size() ? linebytes.at(column) : 0x00;
	cf = this->drawFormat(c, b, s, Area::Hex, line, column, static_cast<int>(column) < linebytes.size());
	}
	c.insertText(" ", cf);
	}

Convert the result of this intoQString:

QHexUtils::toHex(linebytes.mid(column, 1)).toUpper();

Like this, for example:

QString(QHexUtils::toHex(linebytes.mid(column, 1)).toUpper())

This brought everything back to normal for me. I have no idea how exactly this fixes the issue, but I suppose using QStrings instead of QByteArrays when drawing could be more reasonable choice. So perhaps you should make sure that QByteArrays get converted to QStrings within functions that deal with rendering.

[Dax89]

Great!
It must be a nasty implicit cast with some Qt/Compiler/OS specific combo

Pushed! Let me know if it's ok now.

[T-640]

Everything looks fine. Now, to the lesser issues:

1. In Hex area background highlighting grabs an extra character (an empty character that separates representation of bytes). In ASCII area it works fine, highlighting from cursor selection is correct too.

The green color demonstrates the issue, the black one is just cursor selection, working correctly.

2. When copying bytes from hex area via Ctrl + C the last byte is never copied.

The FF byte will not be copied.

3. Regarding the Renderer does not work well with widget’s width #57

In the old version I used a small hack to adjust widget's size to what is actually being rendered (to remove that useless white space after ASCII column) by calling QHexRenderer::documentWidth, but it is gone now. I was giving user an option to change the size of QHexView by making its font larger, and then readjusted its width via a call to that function. But the best solution would probably be to implement some function like QHexView::adjustWidthToContent(bool) or make it default behaviour of QHexView altogether. I suppose the situation when widget becomes too large needs to be considered in that case, or when user wants to set fixed width for it.

The whole idea of what is the best way to resize QHexView may need more speculation though, because resizing such widget correctly seems to be more challenging than doing it with others. Changing its font and adjusting width accordingly is what I could come up with, it is a bit stiff but fairly simple. Maybe there is a better idea, but for now this will do.

4. It still crashes unless I set QHexDocument within my subclass of QHexView first.

5. Alternate row colour starts in the wrong place:

6. Vertical scrollbar. Probably not a bug, but rather an aesthetical preference. It feels like it should be larger. Take a look:

This view has 17 rows, two of which are not seen. Scrollbar steps correctly, that is, twice, as it is supposed to. I am only pointing out its appearance. Shouldn't it be longer?

For comparison, this is a scrollbar from a QTreeView with 17 root items (not expanded), it is twice as large:

Other than that everything else that I use appears to work well so far. Editing works fine, both in Hex and ASCII areas, both modes, insert and overwrite work correctly. I mentioned changing font above, that works well too.

[Dax89]

I've fixed 1, 2, 5 and 6 along with a bunch of other minor fixes/improvements.

About the other issues:

• 3: Do you want that the widget calculates the line's length according to its width?
• 4: I can't reproduce it, is it possible to have a sample code which causes this issue?

[T-640]

Do you want that the widget calculates the line's length according to its width?

The reverse of that, if I understood the question correctly. But this could work too I suppose. Either way I would like widget's width (just width, not height) to be "synchronised" with the actual content, with what is being drawn (hex , ASCII areas, etc.). Right now widget draws offset, hex and ASCII columns and anything after that is wasted space (if widget's width is larger than what these 3 columns occupy).

So if widget is too wide I think its width should be reduced. In the old version I did something like this:

hex_view->setMaximumWidth(m_renderer->documentWidth());.

It may have some implications since widget is programmatically resized, but the idea seems to be worth exploring.

4: I can't reproduce it, is it possible to have a sample code which causes this issue?

I figured it out. New QHexView does not create QHexDocument unless it is explicitly set by QHexView::setDocument. In the old version, an empty one was always created at the end of the constructor:

QHexView/qhexview.cpp

Line 36 in b3c0e4a

this->setDocument(QHexDocument::fromMemory<QMemoryBuffer>(QByteArray(), this));

My program crashed because of this:

1. QHexView instance is created, QHexDocument is not set (it will be when something is actually loaded);
2. QSettings instance is being read to retrieve "insert" or "overwrite" mode setting and calls hex_view->hexDocument()->cursor()->setMode();;
3. But because QHexDocument has not been set yet, QHexView::hexDocument returns nullptr and thus crash occurs.

The simplest way to fix is to just copy that single line from the old version. Although perhaps cursor mode could be set directly from QHexView, with something like QHexView::setCursorMode, thus bypassing the need to call QHexView::hexDocument? Unless it is designed to handle multiple cursors, like QTextEdit though. And it could unnecessarily bloat QHexView's public API too I suppose, so I am not sure.

A few more bugs:

7. Alternate colour is still drawn incorrectly, but in a different way:

8. At certain widget height scrollbar does not appear when it is supposed to:

In this screenshot there is actually one more line at offset 0xF0. It is not visible, thus scrollbar is supposed to appear, but it doesn't. Reducing widget's height slightly makes scrollbar to appear.

[Dax89]

I have added QHexView::setCursorMode and QHexView::setAutoWidth in order to rescale the viewport's width according to the rendered area, let me know if it's ok now.

And I've also fixed all issues you have reported, an empty QHexDocument is created by default too, like the previous version.

[T-640]

Issue 8:

Now scrollbar area appears, I can see up and down arrows, but the scrollbar itself is not there, so I am still unable to scroll down to the 0xF0 line.

QHexView::setAutoWidth:

When QByteArray supplied is large, that is, when vertical scrollbar needs to appear, it does readjust width successfully. However, there are two occasions when it does not do that: when QHexDocument is empty and when the size of QByteArray is small (when there is no need for scrollbar).

Also while the widget itself correctly adjusts its width, the QAbstractScrollArea::viewport does not seem to - horizontal scrollbar appeared and I could scroll a lot to the right.

[T-640]

And there is also one more thing that could be restored from the old version: in Hex area bytes 00 and FF were coloured differently from the rest, and dots in ASCII area were too. Now that there is QHexOptions it would make a good optional feature. Maybe even provide an option to change colour of these sort of special bytes.

[Dax89]

I've improved the scrollbar's behavior, issue 8 should be fixed.

You can highlight any byte by using QHexOptions::bytecolors map, for example:

QHexOptions options;
options.bytecolors[0x00] = {Qt::lightGray, QColor()};  // {Foreground, Background}
options.bytecolors[0xFF] = {Qt::darkBlue, QColor()};   // {Foreground, Background}

hexview->setOptions(options);

It's also possible to highlight bytes from the widget itself with these functions:

• void QHexView::setByteColor(quint8 b, QHexColor c)
• void QHexView::setByteForeground(quint8 b, QColor c)
• void QHexView::setByteBackground(quint8 b, QColor c)

By default the new version doesn't highlight anything.

Screenshot

[T-640]

5.10 is old enough I believe

The goal is to retain compatibility with the version 5.6.3 though, according to this discussion - #69

[NikolajSchlej]

Had to make some trivial changes to make the widget buildable with vc141_xp target in Qt 5.6.3:

• replacing std::isxdigit with isxdigit from <cctype>
• replacing QString.first() and QString.last() calls with at(0) and at(1), as that string is 2 characters long.

Switched to this widget because it natively supports UI dark mode and overall looks much nicer than QHexEdit2 I've used before in UEFITool: LongSoft/UEFITool@cba31d8

Huge thanks for making it, and for using MIT license.

Minor feature ideas (might implement some and send PRs later):

• STATIC_READ_ONLY option that ifdefs all editing-related code away
• similar static options to disable unused features, i.e. large file support, editable memory buffers, commands, etc.

[NikolajSchlej]

Dark mode in Linux with Qt 6.2.4, global scaling 200% on 5K display. Works really well!

[NikolajSchlej]

A minor bug to report: macOS starting with 10.7 has scrollbars hidden by default and shown only when scrolling is performed. Had to make this modification to restore the expected behavior there:

void QHexView::wheelEvent(QWheelEvent* e)
 {
     e->ignore();
 #if defined Q_OS_OSX
     // In macOS scrollbar invisibility should not prevent scrolling from working
     if(!m_hexdocument) return;
 #else
     if(!m_hexdocument || !this->verticalScrollBar()->isVisible()) return;
 #endif

[NikolajSchlej]

Also, the default font in macOS is somehow not a monospace one, so I had to manually call setFont() to set it back to sanity. This is how it looks in macOS 13.3.1 on the same 5K screen.

[T-640]

@NikolajSchlej,

I see that you happen to be in possession of a high resolution monitor. There is a bug related to these. Could you confirm that it happens on your Linux and Macintosh systems as well?

The bug is described here - #71 (comment). Make sure to call QApplication::setAttribute (Qt::AA_EnableHighDpiScaling) in advance before the QApplication instantiation and pay close attention to the last line, as the glitch may be hard to spot. A somewhat crude workaround can be found here - #71 (comment).

The reason behind it is yet to be determined, so any assistance would be appreciated.

[Dax89]

@NikolajSchlej

replacing std::isxdigit with isxdigit from

I have done an internal implementation (implemented as QHexUtils::isHex()) so we'll avoid compiler shenanigans entirely!

replacing QString.first() and QString.last() calls with at(0) and at(1), as that string is 2 characters long.

I have found a front() and back(): both replaced replaced with at() .

A minor bug to report: macOS starting with 10.7 has scrollbars hidden by default and shown only when scrolling is performed.

Fix done as you suggested

Also, the default font in macOS is somehow not a monospace one, so I had to manually call setFont() to set it back to sanity

Is there some way to set a monospace font for MacOS?

There is a conditional statement that may create some issues, this is the relative code:
https://github.com/Dax89/QHexView/blob/5.0/qhexview.cpp#L36-L40

[Dax89]

@arabine

I have a question: is there a way to refresh the view when the memory content has changed? My use case is an emulator, I want to view the RAM content (I can call a method to force the refreshing if needed).

There is QHexDocument::documentChanged() signal which is connected automatically to the view and it redraws the data when notified.

If data is changed externally I think it's sufficient to trigger an update manually with Qt's update() method when needed

[NikolajSchlej]

@Dax89, not really a fan of platform-specific hacks, and it feels like a Qt-issue more than a QHexEdit-issue, but I'll investigate those font shenanigans further.

@T-640, I don't use the flag you mentioned because UEFITool is only using Qt 5 for a single legacy platform (x86 Windows XP and newer), with explicit refusal to support HiDPI on anything that is not built against Qt 6. As mentioned on https://doc.qt.io/qt-6/highdpi.html, "Qt 5 behavior assumes that AA_EnableHighDpiScaling has been set (this flag is not needed on Qt 6)".
Will still try to reproduce it on supported configurations later.

[NikolajSchlej]

@Dax89, @T-640, looks like the issue is reproducible even with Qt 6.5.0 and without the explicit HiDPI flag, just resizing the window with nothing but QHexView widget slowly, a moment can be caught where the next line is already drawn (so now about a half of line is visible), but the scroll area is not yet updated (so it can't be scrolled to become fully visible). The window can then be resized back a tiny bit, making the visible potion even smaller. Resizing further back or forward fixes it, but it can be repeated indefinitely.

[arabine]

@Dax89

There is QHexDocument::documentChanged() signal which is connected automatically to the view and it redraws the data when notified.

If data is changed externally I think it's sufficient to trigger an update manually with Qt's update() method when needed

Do you have an example? Because in this case, I think I have to create a document with a reference to the data (without copying it on each data update).
It would be worth to have it, it would complete the README examples provided (the examples show only the use case when the user can change the data from the view).

[Dax89]

I suppose that the RAM is just a buffer of bytes updated by a virtual CPU, outside the control of the widget.

In this case I think QMemoryRefBuffer is what you need, because it takes an external buffer without copying it.
Note that QMemoryRefBuffer have deletion and insertion disabled, but you can edit its content.

For example:

#include <QHexView/model/buffer/qmemoryrefbuffer.h>
#include <array>

static std::array<char, 8> BUFFER = {
    'm', 'y', 'b', 'u', 'f', 'f', 'e', 'r'
};

// QByteArray is also accepted
QHexDocument* hexdocument = QHexDocument::fromMemory<QMemoryRefBuffer>(BUFFER.data(), BUFFER.size());
hexview->setDocument(hexdocument);

If you want something even more specific you can also roll your own model inheriting from QHexBuffer class.

[caffedrine]

Guys, is there any way to scroll to a highlighted area? I tried manually method QHexView::scroll(0, 20) and it does produce a really weird output. It seems the whole area is shifted down:

[Dax89]

The widget scrolls automatically if the cursor (or selection) is outside of visibile range, otherwise it doesn't do anything.

The method scroll() is inherited from QAbstractScrollView and shouldn't be used.

[Dax89]

This commit: 2bafc90
reorganizes the source tree in order to follow the most common C++ project structure, so:

• Every include now is prefixed as #include <QHexView/...>.
• QHexView is now a static library (as proposed in Add example program and make this repository compile by itself. #80), at least when CMake is used.
• The tagged release 5.0.0 is available if the previous behavior and source tree is needed.

Let me know if I broke something on your side by opening new issues, thanks!

PS: I have converted this issue in a Discussion.