MIME Browser 1.2 Released

Version 1.2 of MIME Browser, my free multi-platform EML viewer written in JavaFX, is now available for download. No big new features but a lot of small ones, including some user requests, as well as bug fixes and other tinkering.

• Specify individual files (in addition to folders) directly on the command line, or via drag & drop. Note that MIME Browser must already be running for drag & drop to work since it’s a Java JAR file, not a native executable.
• Save all parts of a MIME message to a user-selected folder. MIME Browser tries to guess a good unique file name if one isn’t recorded in the message.
• Saving an individual part uses correct file extensions for text & HTML, and the save dialog defaults to the original file name.
• MIME header fields are now shown in TextArea controls that take up more screen space but allow selecting & copying text, and more importantly feature a scroll bar when the field exceeds a single line.
• An overdue “About” dialog with version number, release date, and links to email, official website, and the included ReadMe file.
• For developers: The Javadoc class reference now includes UML diagrams, courtesy of yWorks UML Doclet.

These are just highlights – please see the WhatsNew file for the full change list. The screenshot below shows the new controls, described in more detail in the updated ReadMe file.

Reception & Future

As mentioned, some changes were suggested by users. When I first built MIME Browser for my own use and as a JavaFX learning project, I had not imagined that anyone else could possibly be interested in a quaint offline email browser. Turns out I was quite wrong! MIME Browser has been downloaded over 300 times since the end of July, and I received a surprising number of comments both here and by email. Thanks everyone for the kind words, and rest assured I take note of all feature requests although I likely won’t implement all (or even most) of them. Here’s a quick update on wish list items that didn’t make it into this release:

List columns for MIME header fields (subject, to/from, etc.). That would be quite useful but requires reading every single MIME message before the list is composed, which I’m not currently doing unless full text search is enabled. This is potentially slow, and also requires a new configuration dialog to select columns. I may do this but it’s a lot of work…

Delete messages from within the application. I definitely won’t implement any “hard” file deletion, as I’d rather avoid angry emails from people who just accidentally deleted an irreplaceable message. Sadly, Java does not support recycle bins so I’d have to use the Java Native Access library which would quadruple the distribution size, just for that one feature. Probably not going to happen. An ugly workaround (at least on Windows) is to delete any desired files from within the Save dialog.

Combine multiple messages into a single report. This would be limited to plain text for the main message bodies, as I’m not going to integrate PDF or DOC generators. Besides, report generation is tedious work, so I think I’ll leave this one to commercial products.

JavaFX Tip: TableView

Lastly, here’s a tip for fellow JavaFX developers concerning a small but annoying cosmetic issue. The folder list is implemented as a TableView, and the first column (for the file name) should fill all space not occupied by the other columns. That proved surprisingly difficult to get right across all Windows DPI settings. The JavaFX TableView evidently scales its spacing at a different rate than the actual Windows DPI progression, perhaps for aesthetic reasons. So whatever root em factor I used for the first column, it would be either too wide or too narrow on some DPI settings, and by quite a big amount too.

The solution I ended up with is to dynamically size the column once the TableView has been laid out and its actual width is known. This is the case only after show() has been called on the primary stage, so that’s when I subtract the other (fixed and known) column widths from TableView.getWidth. However, that’s not quite correct yet since we also must account for the width of the scroll bar… and JavaFX provides no public API for that, nor for determining the “client” width of a control. You could find the scroll bar width by digging into the undocumented private styles of TableView but I really don’t like such hacks, as the structure and names might change at any time. So instead I just subtract one root em which seems to work out okay. (Do let me know if you find a case where it doesn’t!)

2013-12-15: I opened a JIRA feature request for a public API to determine the visible client size of parents that might show scroll bars or other private decoration.