enhancement for tags?

[xenogenesi]

Tags are handy, working with binary files, there's some feature I think would be very nice to have in the editor (ordered by my idea of importance):

1. A gui element (combobox+button?) to run an external command (keeping track of recent) with the current file as argument (optionally current selection start-end offsets could be also useful), the external command should simply generate on stdout (or replace the .tags file in-place) new xml and refresh current tags.
2. A textinput filter on tags panel to hide/show only matching tags
3. Currently to remove tags need to select one by one and use the context menu on the hex panel, would be nice to have a context menu on the tags panel to remove all selected tags.
4. Tags in the tags panel optionally colored with same font/note colors.
5. Overlapping tags are already supported, but the result in the hex panel could get a bit messy (I guess some sort of z-order is required to fix this, at least bringing up the one selected in the tags panel? I've no idea how the tags highlight works in the hex panel yet)
6. Would be nice to support also nested tags, with a treeview instead of a list in the tags panel.
7. Having point 1 implemented would be nice to have an "output" panel to display the stderr of the executed external command.

How do you think? I may take a look at the sources and work at it in a (hopefully not too far) future but sadly not yet.

Cheers

(I'm using version 0.23+repack-2+b1 from debian/sid)

[newsgrep]

regarding 3) removing them by pressing the delete key would also be nice

8. reordering of tags by drag & drop would be nice to
9. search & tag: so that a tag is created on all place were a pattern was found. (extension of the search function)
10. please make it possible to open the window to tag a place and the search window at the same time.
11. please do not make the color of the quick tag random. Keep it changing but not in a random way
12. could you put in shortcuts like ctrl+1 for color 1, ctrl+2 for color 2 etc.

[DMJC]

Can you please enhance the search box to make it so you can automatically create tags from a search result? This could be as simple as adding a checkbox to copy search results into the tags panel. Preferably with a color selector so that search items can be highlighted with a color selected from the find box? This will make it MUCH easier to reverse engineer file formats as I can instantly see patterns in the files and keep them highlighted for referencing. The tags at the moment are too time consuming to use because you create them one at a time.

[EUA]

Also might be better to Merge tag related operations at right click menu with addition of Remove Tag option.

[TBeholder]

(3) "Clean All Tags" and "Remove Tags in Selection". (6) Yes, that. Small fields make long lists. Also, collapsible hierarchy dovetails with associated types (which is the obvious next step). In that among the types obviously should be array/named array (e.g. "R","G","B","A") and record structure. If only to define them only once, and then just refer in several places. (11-12) perhaps it could be a simple palette menu? With values stored in the main config.

[EUA]

Back to this request:

1. This looks like external program to generate tags on the fly.. Not implemented. No plan for it.
2. Good idea. Need to open another issue for that may be.
3. [Done] Already done it. Not added "delete" key support for deletion, yet. Which is good idea. Add it to priority list.
4. Himm. Don't know if support for it at wxWidgets API. Also I think it's bad idea due might look crowded to eye.
5. This would be major improvement.
6. It's hard to show three form under combo box... But could use directory forms if possible.
7. Complicated. I don't decide how to generate automated tags yet.
8. Himm. Don't know/sure if it solve more problem than it generates programmatically.
9. [Done] Search & Tag... Himm. I don't know why I don't make it before. Added to priority list. @DMJC
10. Okay. But don't know what if user switch another file tab while opened search dialog. This why it's disabled. Need to work on it.
11. I believe it's more useful in that way. Might be an option is eligible to enable / disable that randomization and select one predefined color.
12. Don't understand that. ctrl+1 -> create tag with color stored at number 1. Himm. I don't know. This require to another dialog panel to configure colors also...

[xenogenesi]

I thought the email was to close the issue, instead ... I'm glad you decided to work on it! Nice

Point 1 is similar to an implementation that I saw in a commercial hexadecimal editor (I don't remember the name), I was evaluating the time limited version and I found that flow very practical to examine a file format, set the executable the first time, and then only edit the parser /tag generator and a click to update the view. I used the same flow with wxHexEditor but having to reload the tag file each time was more cumbersome. Since you decided not to implement it I could try to do it, obviously creating a PR in case of success.

[EUA]

At the end of the day, wxHexEditor need to parsing mechanism to recognize file type and auto-generate tags for it, using a dynamic template structure/language. Bug #20 is about this.

But making it via external program or allowing such a mechanism... I don't think on it before. Also, do I expect external program create tags at wxHexEditor tag format to import automatically? This means the external program need to be designed for wxHexEditor tag structure and I just need to make auto-update mechanism. But ... why to choose run external program that way? A plug-in mechanism sounds a better fit.

[xenogenesi]

In my case I'm talking about using wxHexEditor and the tags to implement and verify a parser of an unknown file format.

010Editor, that was the editor.

Fortunately the .tags file format of wxHexEditor is markup / XML, easy to generate in any language.

At the time I used a simple python script to parse the files that interested me and generate the related .tags file, during the implementation of the parser it would be useful to have a fast flow, edit -> refresh -> edit -> refresh ... with the fewer clicks possible.

Personally I would prefer it as an external program / command / script for simplicity and flexibility, it would allow using any language to generate it.

[petergeoghegan]

I agree with @xenogenesi -- simply being able to quickly indicate to wxHexEditor that the .tags file has been updated and needs to be refreshed would be a big step forward. Ideally there would be polished integration with third party plugins that make everything happen automatically and seamlessly, but that sounds like a lot of work. Doing the simplest possible thing would help me a lot.

[petergeoghegan]

That being said, I understand where @EUA is coming from. There are a lot of things that a custom scripting language would enable that are hard to get any other way, since it puts the hex editor in control. You can do very granular invalidations, and stuff like that. This is probably why 010Editor does it that way. I get it.

For what it's worth, the ideal outcome for my pg_hexedit tool (see https://github.com/petergeoghegan/pg_hexedit) would be a wxHexEditor plugin interface that understands that the pg_hexedit binary outputs tags for fixed-width 8KiB blocks. wxHexEditor could interrogate the pg_hexedit binary to get new tags based on block-level invalidations. I am not sure how general a solution this is, or how much work it would be. Just giving you one perspective.

I wonder if the work that @xenogenesi is using wxHexEditor for can fit with this model. Could you live with those constraints? In other words, would you also be happy with an invalidation model that works in terms of fixed-width blocks, where the plugin interface gives wxHexEditor the ability to request redrawing fixed-width blocks in response to invalidations/modifications from users? (Typically these will be page sized, or block sized -- 4KiB - 32-KiB.)

[petergeoghegan]

@EUA BTW, reading the pg_hexedit source code once more might give you a sense of where I'm coming from here. It is a PostgreSQL frontend utility, which has huge dependencies on Postgres backend code -- it uses a huge number of structs that describe the on-disk format.

It would be impractical to write this in a custom scripting language or plugin language, even if I was starting out today. The final behavior of the pg_hexedit binary will automatically be different depending on whether it is compiled on a 32-bit or 64-bit platform (the width of some of the struct fields is platform dependent).

I'm not sure how representative my particular requirements are. It's a good example of why a person might want to keep close control of how the tags are generated, though. (As I just went into, it may be possible to come up with some kind of compromise that everyone can be happy with.)

[xenogenesi]

If I remember correctly the 010 Editor system worked like this:

• there is a button-with-dropdown that keeps the list of the last N scripts / commands executed in the dropdown, the most recent visible in the button part, plus the option in the dropdown to run a new one that opens the dialogue to choose it

• pressing the button executes the script / command passing to it the name of the file opened as the first argument, if it is successful it updates the tags, if it fails it shows the output of the execution with the error message

All in all it seems like a simple implementation, there's no reason why it can't coexist with plugins to recognize file types and generate tags automatically.

edit

"if it is successful it updates the tags" The command / script updates the .tags file, if there are no errors wxHexEditor should reload it and refresh the displayed tags. I used the same name as the input file + .tags (I don't remember if it's a wxHexEditor convention), but I imagine that eventually stdout could be read, or using a temporary file

[EUA]

Okay. Will look what I could. point 1 it's not related with "enhancement tags" brainstorm anymore. Please open another issue and continue this request as external auto-tag generation and import etc. So we could continue brainstormin on other points here.