Looking at the hex editor view, it's just a big bunch of numbers that lack meaning. But BEdit is all about giving meaning to numbers! So I set out to display the memory region each member occupies.
First attempt was to draw a line under the memory span. And it looked, well, horrible. Having a bunch of lines all over the place was cluttering up the view, it also failed to take into account that multiple members may occupy the same memory space.
Second attempt, change hex number text background color. Easy enough, and if multiple members occupy the same region I can just display mutliple background colors - but with different heights (i.e. if two members occupy the same memory span, one background is displayed on top with 50% height). This of course means the background color needs to vary to prevent things like blue being displayed on blue.
But what colors to pick for background variations? Just flip some RGB values around until you're happy? That's the approach I started with, but I quickly decided it wasn't going to cut the mustard. The problem is that brightness isn't a part of RGB (and I want roughly same brightness for all variations), also the iteration time during development is way too long.
Step one of the rabbit hole, implement a color picker with RGB and HSL support (see main page for screenshot of ad-hoc bright theme).
I haven't used HSL (Hue Saturation Lightness) that much before, but I must say I like to use that more than the RGB color picker variant.
But wait a minute, BEdit uses a bunch of colors for, well, everything! Texts, backgrounds, buttons, popups, ... Why not expose that while I'm at it. This is step two of the rabbit hole. The current implementation supports changing of almost all colors, as a proof of concept I added a bright theme. Now I can also dump all kinds of configuration and settings in one place, like font size, default byte grouping of the hex editor, etc. As the code reads the configuration directly and the color picker changes the source configuration, you also get instant change of the GUI, in other words: iteration cost is very low.
Future iterations on the color picker might include common colors in use, and there are some other things to play around with so it's still a bit from perfect but already quite useful.
This got me thinking. Image formats store pixels, and now with a color picker - why not extend the layout language to include colors? Something like pixel.rgba(4) color;. BEdit could display the hex values of a BMP image in the actual RGB color! However, the layout language doesn't have a concept of colors, and I feel it might be a bit too special purpose to add colors as a first class citizen. Just as adding wave forms, that could be useful for audio files, is a bit too special purpose. Also the command line viewer would have issues displaying RGB values, especially it they're the same as the console background.
Having the RGB displayed and editable is still very useful, so how to have a feature and not have it (cake feature?), by plug-ins!
Current step of the rabbit-hole is to extend BEdit (the layout language, library and GUI application) to allow for plugins. I haven't decided yet if I should dig myself up and delay that until after initial release of the GUI but it's definitely in the backlog now!
Who would've known that plug-ins was a dependent feature of the hex editor?