The last month or so almost all development have been for the GUI and to my surprise, simple features like scroll bars are fairly tricky to get right. If that's just due to me not having much experience in this style of application development or if it's just naturally tricky is a different story.
Consider doing scroll bars the naïve way: draw the entire view, check the lowest pixel drawn and there you have the height of the area. If the area is larger than the clip region, you have all the data required to determine scroll bar size and position. This works very well, you can have dynamic layouts and the scrolling will just work. The problem is that BEdit is a binary file editor, and binary files may be small, large, huge or of ludicrous size and as such drawing the entire view is simply not feasible for some views. Doing a pre-pass to determine line count is for the same reason not feasible. The solution I went with is to determine the line count before doing the layout. See for example the hex view (check screenshots in project page), before rendering the lines I do know the width of the area, I know the width of the digit groups and hence I know the width of a line. A simple divide will say how many lines are required to draw the entire file. This puts a huge strain on what kind of layouts you can do, you must know the amount of lines before you start drawing. This means the structured view, that is a tree-hierarchy, must be done in two passes - one to figure out the amount of lines, one to draw it. But can't we have both methods? Yes, we can have the cake and eat it too (I call this cake programming). This does shove the problem to the usage code by some extent but it doesn't disable a good feature.
I had similar experiences last month regarding data storage of the binary file where you want minimal extra bookkeeping, quick insertions and random access. But with these features implemented, the major parts of the GUI is done and there's a small shine of light coming from the end of the first-release tunnel.
So what has been done and what's left before alpha release?
Done (alpha stage / usable)
- General layout of GUI, two panes with editors on left and right
- Editable config file, a binary file of course
- Hex editor
- Structured editor, display of members in order of definition
- By address editor, display of members in order of address
- Source code viewer (currently read-only)
- Unsigned binary, octal, decimal and hex member
- String member
- Enum member (flag-like enums not yet supported)
- Release platform, itch.io page awaiting release.
Before initial release
- Tax office, determine pricing etc. (don't worry, no in-app purchases!)
- Better arrays / repeating members
- Signed integers
- Float editor
- Flag-like enums
- Handle infinite loops (or close to infinite) in layout instructions
- Support really large binary files (probably through memory mapping)
- Handle edit conflicts, e.g. file has been modified by other program while being loaded in BEdit
- Hot-reload mode of layout source code, to allow you to modify the layout code in external text editor
After initial release
- Text editor for layout code
- Better visuals and more widget types
- Better interactions between editors (click to jump etc.)
- Layout code debugger
- Binary diff view
- RLE hex view (something like 0x00 <repeats 126 times> 0xFA ...)
- Plotting view
- More member types and perhaps custom ones (half floats, color type, ...)
- Mac and Linux support
- End-user feedback and bug fixes
... and probably much more that I just haven't imagined yet.