QGraphicsView, QGraphicsScene and QGraphicsTextItem / Implementing a HexEditor

Hi,

I want to implement a hex-editor with a classical 3-parts-layout (offset, hex, ascii) with Qt (and Python, but that does not matter because class-names are equal to those of C++). As a proof of concept I thought it's maybe a good idea to use a QGraphicsView in which I place a QGraphicsScene. The QGraphicsScene is then filled with the three QGraphicsTextItems representing the current offset, hex and ascii values.

See the graphics below to get a better understanding:
Attachment 5571

Currently this implementation has some problems:

• First of all, I wanted to get your opinion on this setup. Is there any better way? All in all it's less pixel-calculations than I expected because almost all geometry can be determined by already available methods (e. g. like those provided by QFontMetrics). The QGraphicsTextItem also allows me to apply colors, e. g. for implementing selections.
• The QGraphicsScene is created in case the navigation bar or the mouse wheel is used on the QGraphicsView or when a resizeEvent() occurs. That works fine, but I'm not sure if that's the best approach.
• Is there any way to fix the QGraphicsScene in the QGraphicsView? When I press the Page-Up/Page-Down keys it moves around (but the mouse-click coordinates which are relative to an item's position are still given correctly).

Thanks for reading and giving me your opinions beforehand :)

Rainer

Quote:

---

Originally Posted by dubbaluga

Currently this implementation lacks some problems:

---

I would be quite happy when my implementation lacks problems...

But seriously, just out of curiosity, why didn't you choose the QTextEdit/QTextDocument pair for this uhm... text editing?

Quote:

---

Originally Posted by franz

I would be quite happy when my implementation lacks problems...

---

Thanks for mentioning. :-) Corrected it. I'm not native English-speaking, so maybe that's an explanation ...

Quote:

---

Originally Posted by franz

But seriously, just out of curiosity, why didn't you choose the QTextEdit/QTextDocument pair for this uhm... text editing?

---

As far as I remember, I tried it, but it seemed too inflexible to me. I think it was difficult to arrange these elements (e. g. by using 3 of them for offset, hex and ascii) beautifully together (which is easy with drawing QGraphicsTextItems in a QGraphicsScene).

And on the other side it was difficult to determine the clicked position, e. g. when one wanted to select a specific element. But maybe I just didn't get the application of the Document-View pattern here ...

Thanks for your opinion!!

Hi,

Using a GRAPHICS widget for creating a TEXT tool doesn't seem the best way to me.

Maybe you can look at how it is done in this application from qt-apps : QHexEdit.

Best regards,
Marc

Hi,

Quote:

---

Originally Posted by marcvanriet

Using a GRAPHICS widget for creating a TEXT tool doesn't seem the best way to me.
Maybe you can look at how it is done in this application from qt-apps : QHexEdit.

---

I downloaded and reviewed the code from QHexEdit. It uses QPainter and Co, meaning a graphics-widget, to "draw" the objects as well. First I also thought using text-based-only widgets would be the best solution, but then I found out that it's often too restricting, e. g. for visualizing several selections. But maybe there is still a better solution!

The main reason for me implementing my own hex-editor is actually that almost all implementations I know (Okteta, QHexEdit) copy the contents of the file opened into memory which is the real dilemma since it does not allow you to open whole hard-disks or images of storage devices. And actually it's as easy as using a memory-map (mmap) which allows you to open files or devices as if they were huge arrays. On the other hand I could also have replaced the QByteArray with my own model in the existing implementations ...

Best regards and thanks,

Rainer

Have you made the editor with help of Qgraphicsview architecture?