I do quite a bit of coding in C, and occasionally some in PIC assembler. As such I'm often using values in hexadecimal (because for certain purposes it makes a lot of sense). However that doesn't mean I can convert arbitrary values to and from hex
in my head. A few obvious values such as 0x20=32 (which is also ASCII whitespace), or 0xFF=255, or 0xFFFF=65535, I know perfectly well, but otherwise I use the
bc terminal-based calculator thingy to do the conversions (assuming I actually need to know them).
Unfortunately though, this gets rather awkward as it involves telling it to output in base 16, or take input in base 16, and then if I want to change it back, what am I doing? Do I tell it to use base 10 in base 10, or in base 16? Doubtless simple if you're wide awake but rather than think about it I usually close it and restart it again!! Or launch a further instance. Too much bother to think about as I'm the sort of person who sometimes gets relations backwards if not concentrating. Plus it only recognises capital ABCDEF, rather than lower case. Or is it the other way round? It's generally whichever one I'm not using. And I wind up tying up yet another whole xterm window with it, unless I keep starting and stopping it as needed, which, again, gets tedious. In short, a less than ideal arrangement.
Hence the urge to sort out a decent hex-conversion program. Now I could do it as another terminal-based program, and that'd probably be quite simple, but I'd have to be able to tell it what direction to do the conversion, or have 2 versions and keep starting and stopping those, too. GTK2 is now pretty firmly established and I have the dev packages for it in my Debian Linux system at last (there were nontrivial issues preventing this for the past year or so), and the documentation is at least adequate for this purpose (I'll have to see if things have improved since I turned my back on the toolkit due to the patchiness of the docs of the time). So I'm going to try some more GTK code, something I don't think I've done since v1.0.
Features
- Just a little window with two columns, left side has a decimal input box above an label used for hex output, distinguished by the 0x prefix (a-la C). Right side is basically the same sort of thing but for converting hex to decimal instead (with the decimal distinguished by a "d " prefix for want of something better :P )
- Output labels are copy-and-pasteable for improved basic usability.
Planned/contemplated features
- Better distinguish the hex entry+label from the decimal entry+label, by using different fonts, eg a computery looking one for the hex values. Also a graphic with say an arrow or such pointing from each entry to the corresponding output label, that might also express which one is hex and which is decimal.
- Output toggleable between "chunked" (for want of a better term??) format and uh, plain. "Chunked" being where long numbers are split up into pieces-- 4 digits with spaces between for hex values, or 3 digits separated by commas (or dots depending on national preference!!) -- to improve readability. Majority of software doesn't like those formats for input though. Alternatively might have it output both ways at once, in separate labels??
- Possibly (later addition?) a 2nd, pop-up window that shows a list of values converted, each with note explaining what that value MEANS. This would probably be optional, eg there could be a button by the output label that brings up a dialogue to enter a description of that conversion, and then that adds them both to the history list. A further button in the main window would open the history window, which could easily be closed again obviously.
- Once a value's been added to the list, the button for it gets greyed out until a new value is calculated. There'd be one for each conversion type.
- Possibly also a simple hex-based calculator app??? Just to do the operations you usually associate with hex values: Addition, subtraction, bitwise boolean ops, shifts and multiplication. Perhaps endianness conversion type stuff too?? All this is sorta hypothetical though, I've not given the hex calculator idea (as opposed to the simple hex convertor) a whole lot of thought.
Screenshots

Version 0.01! It's no oil painting, and is pretty limited, but it does essentially work.
Download
Hex Combobulator, V0.01 (Linux source code in tar.gz format. Don't ask me for Windows versions, nor how to compile it for Windows though it is most likely possible with MinGW32 and the Windows version of GTK2. If you want that, you're expected to know how for now, sorry!)
News
11th December 2008:Turned out that though "hex cromulator" was unused, "cromulator" was in fact someone's username (multiple someones?), so it seemed... wrong somehow. I decided "Hex Combobulator" was quite good though and have decided on that even though there's also people with the username "combobulator" :D It seems different somehow, I'm not sure I could explain why *ahem*. Anyway, Hex Combobulator is now roughly functional at V0.01, though it lacks most of the neat features. Further updates to come as time allows.
10th December 2008:Project started. Working title picked of "hex_cromulator", it would
probably be unused...
See also
- Unpicking XCom .cat files, shows an example of quite a bit of hex dump usage, in which I found myself wanting a better hex-convertor again, leading to this mini-project.
- "Linux Headquarters": GTK examples, GTK dialog. Doesn't really help for the specific details I wanted to know, and also the particular example may be a bit confusing if you're not paying attention, but there it is.
- PHP-GTK module, for GTK programming in PHP. Not really appropriate to this, but nice to note they're caught up with v2 at last. I wonder if it works better than most of the other PHP modules I tried?
- EM_386: Your favorite 'better than C' scripting language is probably implemented in C. A blog post warning that users of fancy scripting languages may not actually be as insulated from the sorts of risks C users encounter, as they may like to think. Example here being a security vulnerability in the Ruby bindings for GTK.
- Tinymail TRAC page for tny-gtk-password-dialog.c, this was what I eventually found on the subject I was looking up. Not a tutorial page or anything, just a piece of source code where they actually do the sort of relatively simple thing I was interested in rather than something painfully trivial. OT WARNING, for some strange reason they have the page on https, but the certificate is self-signed and doesn't even match the site anyway. Much of the issue is probably down to limitations in the design of https, but still I wish people would either do their certificates right or just stick to http...
Note most of those links were for finding out about GTK2 dialog[sic] boxes, which are quite terribly explained in the official tutorial and the reference docs are a bit much to take in as introductory material.
(planning notes)
- comment entry for logging values, should be in a dialogue box, popped up by a small button by each output value (which is greyed out when the prog is opened or after you've logged the value, and reenabled when you convert a new value). I think I've explained this in planned features.
- that dialogue box should consist of a pair of labels in the vbox at the top, the first of which shows what the values are that are being logged, in a sublabel, and the 2nd contains the text entry for your comment. The button area has OK and Cancel. I suppose there could be a "Help" that explains roughly what sorts of comments you'd put.
- the log page could be written to disk via a save button, or written to disk as it's produced, or just kept entirely in memory. Undecided.
- Title of "hex combobulator" might want to be earnt by adding other handy and relevant features, but aside from the hex-based calculator idea I can't think of much. I suppose said calculator could have variables, to store things like opcode constants that are combined with variable values in moderately regular CPU machine code architectures (eg PIC)??? And/or maybe arrays/tables that can be loaded from files for similar purposes?? I'm not quite sure how the latter would work out...