Would be incredibly handy when opening from 'Recent' say several weeks later and you don't know where that file is located.

How it looks right now:

How it might look:

Seems to mostly occur when resizing back and forth around sizes that are far too small to display anything. Grab a corner and shake it like a madman, it'll eventually get stuck in a loop and consume memory at a frightening rate.

Should be able to select all or even perhaps an option to select a range from one offset to another (which could fundamentally provide this functionality in itself).

The vertical scrollbar currently operates directly on the number of lines in the rendered Document, this means that assuming the window is wide enough to display 20 bytes per line, you would encounter issues scrolling with files larger than a measly 43GB or so on most platforms.

We should instead split the whole range of lines into a limited number of segments which are then mapped to the scrollbar position, so dragging the bar moves the file by 1/1000th of its height or something, while the up/down arrows still scroll on a per-line basis.

Maybe implicitly, maybe it should pop up a yes/no dialog.

Disable when no action to undo/redo, show description in label.

Firstly, Document needs updating so that the authoritative store of comments is a NestedOffsetLengthMap or similar, like the highlighting prototype uses. Regions still need to exist to reflect what is there, but are to be considered transient.

Once that is done, a start of the following changes can be made:

• Listing of comments outside the main Document view, perhaps also serving as bookmarks? Something like a wxListBox, or a tree to show where they are nested, or a Google Docs-esque thing where they float around to the right of the document, with loosely coupled scrolling? Searching of comment text too?
• Comments can apply to a region of bytes rather than just a single point, they can also be nested, where annotating data structures.
• Hiding of comment regions in the main Document view, either globally or on a per-comment basis, once hidden, comments would still be visible in the above view, and also perhaps as tooltips when hovering over the relevant bytes.

Any other ideas welcome...

n/t

The "Find Text/Value/etc" dialogs are non-modal and associated with the Document that was selected when the dialog was opened.

If you switch tab and then carry on playing with the find dialog, it does things, but nothing appears to happen to the active document - because the search is running and the cursor is being moved in the invisible document.

Possible resolutions:

• Hide find dialog(s) when a different tab is selected, make them visible again when tab becomes active.
• Make dialog modal, disappear after first search and make "Find next" continue the previous search (downside: can't see/modify search parameters).
• Create a "tool panel" under the tab rather than a dialog.

...like Chrome and other fancy tabbed applications

If the active document has a backing file, the directory containing it should be the default when the Open or Save As dialogs are spawned, if it doesn't have a backing file, then the last directory navigated to should be used.

Additionally, the filename in the Save As dialog should be initialised to that of the active document (if it has one).

Printed to console when the active document is closed. Possibly something something tool panel sizing.

(rehex:24146): gtk-xfce-engine-CRITICAL **: draw_box: assertion 'width >= -1' failed

If enabled, ranges of bytes with a comment assigned should be split out into a separate range of lines which are indented to distinguish where they start/end.

Depending on platform, text rendering seems to be relatively slow, and doing it with individual DrawText() calls moreso.

When rendering a data region, Document will optimise each column of "normal" text into a single DrawText() call, however bytes which are selected and/or highlighted (i.e. coloured) are rendered using a DrawText() call for each byte.

I don't think this is severe enough to worry about for now, but might be more of a pain to people on slower computers, or with wide windows/large "bytes per line" settings. On my Windows box here, maximising the window, disabling the ASCII view and dragging the scrollbar up/down like a madman is responsive. If I select everything, then do the same, there is a slight delay, not enough to be annoying, but this is a fairly fast machine.

At some point it could be worth implementing the line-at-a-time optimisation for coloured text as well, or perhaps maintaining a cache of pre-rendered characters and then blitting them. Needs some profiling.

Current behavior is to steadfastly refuse to change the file size for any reason in overwrite mode - can't type past the end, pastes will be truncated, etc.

n/t

Support breaking large search ranges down into smaller chunks and farming them off to worker threads.

Current text search performance I'm seeing on this machine is ~100MB/s when compiled with -O2.

Per title. Part of this might involve making which LLVM architectures we link against configurable.

Clicking the mouse and holding for a fraction of a second is enough to start selecting, and the byte being hovered over will be selected even with zero mouse movement.

Selection should require the mouse button going down at one end of the byte/character, and not counting until the mouse has traversed a good portion of its width, like other software.

wxWidgets seems to support it, just need to put all the glue in around selecting and middle clicking.

If searches take more than a few tenths of a second, display a progress bar and cancel button.

Document-level setting with the following options:

Hidden - Don't display inline comments
Short - Only display first line of comment, and truncate if it doesn't fit in the virtual width
Full - Show full comments, current behaviour

It should at least show the offset column, and a cursor

The ability to select a range, and then export it to a HTML document including colour formatting and comments.

Select X number of bytes, right click and select 'Export to HTML...'? Or copy it as HTML to the clipboard.

This would be very handy for documentation purposes.

I would post a screenshot but my mac won't let me, so you'll just have to take my word for it :)

This is an idea for a future tool panel. It would render selected data to the screen as a bitmap, including sliders for image width and pixel size, to aid in identifying bitmap images stored inside files.

Colours will be chosen at runtime to provide visible contrast between different values, but also to show similar ones (so a gradient should look like a gradient, for example).

The search dialogs should have a "Find all" button which finds and lists every match, possibly also with highlights/comments/etc.

Things to consider:

• Huge files
• Huge numbers of matches
• Exporting listing
• UI... should the matches go in the existing search dialog? Another window? A tool tab thing?

Make it so the offsets used in the UI can be adjusted by an arbitrary amount, for example to help finding things relative to a DLL base address, or to a point in the file.

When right clicking onto the comment into the comments section, provide a copy option (which will copy that comment inc. all nested comments as well. Which I can then paste into another document.

And add a button to copy here as well? If not might be worth looking at adding an option to right click the comment within the hex view and then provide a copy option there.

Need some kind of visible marker showing comment boundaries in Document.

Perhaps a box around the bytes, but only when not highlighted? I feel too many things might end up adding their own indistinct boxes and highlights to the document.

This is in addition to #22.

n/t

There should be a pluggable mechanism for adding new tools/functions rather than continually adding more hooks to MainWindow.cpp

Ideas for tools:

• Relative value search (algorithm prototyped)
• File (i.e. file(1))
• Export selection
• Import file
• External tools for disassembly, images, audio, etc
• Bit editor

Existing search and decode table could be updated to use this system.

Plugins would need to be notified of documents being opened/closed/modified, selection changed, etc. Would need to be able to add menu entries, key bindings, create windows/panels, etc and manipulate document. May be dynamically loadable the future, but probably all "plugins" would be statically linked into the binary at this point.

What about interfering with Document rendering process?

How this could work, is select a segment of one file and copy it. Then go into another file, set the cursor position and right click, then show a "Compare" option.

No idea how this could then be displayed - maybe automatically colour bytes in red that don't match the source.

Don't blindly carry on, because GCC can produce some confusing errors when you invoke it with -I -I/foo/

Display strings in the file

LLVM supports lots of architectures, and the Windows/OS X builds are shipping ~50MB of embedded LLVM, most of which isn't usable because we only use x86/amd64.

Comments with fancy (probably anything which isn't 7-bit ASCII) characters in them seem to be dropped entirely.

Errors from some file read calls are not caught, which can lead to the editor crashing out on I/O errors or the file being truncated underneath us.

Mac keyboards don't have an insert key.

We should handle at least common (i.e. 32-bit and 64-bit IEEE 754) floating point values in the decode table.

Are there any other common encodings?

Right clicking on a tab should provide the following.

• Close
• Close All
• Close Others

For other 8-bit codepages, simply substitute the values going in/out.

For other sizes of fixed-length encoding, also narrow the width reserved for the text view.

For variable-length encodings like UTF-8, render multibyte characters at the position of their first byte, with spaces or some other indicator showing their length. Be wary of control characters (e.g. right-to-left) and also fullwidth characters (thanks Japan!).

Either by clicking on the offset at the bottom (so it'll switch it around), or by going into 'View' and yadda yadda.

This would be very handy.

If I want to paste the same data over and over between two points in a file, having a function to paste from and then to would be super helpful.

Alternatively this could be a 'Set bytes...' function which has it's own dialogue, you enter the hex you want to set, the offset and the end offset, and whether or not it should 'repeat until end'.

Basically I'd want to zero out an entire file or whatever or a file within a package etc., just to give you a usage idea.

This is going to be a complicated feature, but the ability to perform a search for multiple hex values in sequence could be incredibly useful.

So for example, I have a package that contains multiple files of the same format but I want to see how many of X there are exactly - I know these files have the same bytes at the start or end - so I enter this information into the search and it highlights the hex values that match for me.

To do this, you might need some sort of search syntax, I'm not sure how this could optimally be introduced; heck maybe this is something for a plugin? But say as an example; 32:b, 32:b, 32:b would perform a search for three bytes in sequence that are equal to 32.

You could also skip so many bytes here as well (32:32i, 256, 32:b, 256, 32:32i).; this would check for a 32-bit integer of 32, skip 256 bytes, check for a byte with a value of 32, skip another 256 bytes and then finally read another 32-bit integer with the value 32.

n/t

Some tools (e.g. disassembly) may not have a one-size-fits-all size. Use wxSplitterWindow or similar to allow sizing both tool panes.

Allow jumping relative to the current cursor position by prefixing the value in the "Jump to offset" dialog with a plus or minus sign. Requires text in the dialog describing this.

Decode values using different pixel formats (24-bit RGB, 16-bit RGBA, etc) and show as coloured blobs in "Decode values" tab.