The only actual programming that I've done so far is to make sure that the menu titles are highlighted properly when hierarchical menus are selected. Until now, selecting something such as Edit: Select: All would not highlight the Edit title as expected. It turned out that the Menu Manager was trying to hilight the title of the Select menu, but since it wasn't in the menu bar (being a submenu of the Edit menu), nothing would be seen. Right now I hilight the title by hand, because I haven't been able to find a way to get the parent menu's ID.

Somewhat more interestingly, I finally got the mockups and plans for what the Apple people (which from now out I ought to refer to as Matt (the UI designer, altho at Apple's he's just a lowly icon designer) and Arnaud/Arno (programmer, he designed the Icon Services in Mac OS 8.5, and I guess he's in charge of the icon stuff in Mac OS X, the second spelling of his name is to give a clue to the non-French speakers on how to pronounce his name).

What Matt has in mind goes reasonably well with the ideas I had for the next major release of Iconographer. This mainly includes going to a palette based interface. However, while I had thought of splitting everything up into floaters, trying to mimic Photoshop as much as possible, he's decided to down-play Iconographer actual editing capabilities, and instead treat more as an icon assembly tool. The main window will now be the Worktable (as opposed to the Drawing Board, as it is now, BTW, these terms are his, not mine). In the Worktable, all of the icon/mask sizes and depths will be visible. Double-clicking on one would open it up in the editor app that the user has chosen. Whether this is Iconographer's internal editor, or Photoshop, it's up to the user. There is also a separate floater for the previews and the icon states (in Mac OS X the user will be able to determine exactly how the icon looks when it is selected, openened, when another file is dragged onto it, etc.)

A couple of days ago I realized that since he's separated the editing portion (which is pretty much the current functionality) from the rest of the features (which will be mostly new additions to the current app), I could do what he's proposing as a separate app, which could optionally integrate with Iconographer. I'm not sure if this how the final (i.e. publically released) version will be, but at least during the development process this would make sense. Then I could keep adding features and releasing new versions of Iconographer in it's current state, while at the same time doing what Apple wants without having to maintain two separate codebases. If I use a common base (which is really the point of MFrame), then merging the two later on shouldn't be that hard.