Activity in this project is starting to resurge after a somewhat long break. Up until last week it was up to the point where I had started on several things, but hadn't finished them, and still had a bunch of stuff planned for version 1.1. First of all, there was the support for the 256 color Windows system palette. My main problem here was finding what the standard palette was. I downloaded three or four icon Windows icon editos, and looked at the palettes they used for their 256 color mode, and they were all different. This wasn't such a big issue as it would have been on the Mac, since Windows icons can include a custom palette, but there would have been no point if several of the supposedly standard colors were actually dithered when displayed in 256 colors. In the end I got that what the Eudora team used as the standard colors (at least according to Arlo), assuming that they knew what they were doing. Actually implementing this palette wasn't that hard, since I already had support for the 4-bit windows one, so it was a matter of marking the 8-bit depth as supporting the windows colors too, getting the color picker picture (my color picking function takes a picture as its parameter, it doesn't care what colors are actually contained and how they're arranged as long as they're divide by a special colors (0x01, 0x00, 0x00)) and making the Windows .ICO loading function use these new colors.
Then I worked on finishing up the new icon browser (the Finder-like list of all the icon resources contained within a file). I had started to allow it to use the arrow keys to scroll through the list, but I wasn't actually scrolling down when the user went below/above the icon visible at the current scrolling level. Also, if a user double-clicked on an icon that was already open, it would open up a new window instead of bringing to front the current one.
Then I worked on adding a Windows menu. I didn't really see it as being necessary, usually people edit one or two icons, and don't need a menu to toggle between them. The main reason I did this was to have a place from where the colors palette (see next paragraph) could be shown and hidden. I realized that I needed a way to attach a menu command to a certain editor that was open. I decided to assign each editor an ID when created (it would be released when closed), and then store the ID inside the menu (menu items can contain a user defined reference number), so that when a menu is selected I can get the ID, look up the editor and bring its window to the front. One of the more tricky things here was that I wanted the icon editors and icon browsers to be separated by a divider, and I didn't want any floating windows to be listed. In the end I used the the window type attribute of the window class to differentiate between them.
Afterwards I finally started to work on the floating color palette, since this is the last big thing before I can release version 1.1. Mac OS 8.5 and above include built-in support for floating windows (well, technically anyway, practically the implmentation in 8.5 is completely broken, and only 8.6 and above works), but that would have been too steep a requirement, since the rest of the program works with 8.0 and above. However implementing floating windows on older versions requires some kludging. The main problem is that you have to have more than one window active (all the floaters, and front most document window). The standard Mac OS Toolbox functions, such as
SelectWindow automatically disable the other windows when they're called. You have to use lower level functions such as
HiliteWindow to perform window manipulation. Also, getting the front-most window can't be done with
FrontWindow, since the floaters are above everything else. This is where it become very advantageous that I had decided to use classes for each window (I have a
MWindow class, and the icon editor, icon browser and floaters are all derived from it). I added some static functions to the MWindow class (so that they didn't require an instance to be called) to replace all the standard Toolbox functions that I had used so far. I also had to add additional calls since the floaters have to be hidden when the application is put in the background. The current status is that I have a floater which can be hidden or shown at will, and actually behaves as a floater. It doesn't have anything in it yet (it just beeps when clicked on, as a simple test that it can handle events).
As I was testing the floater implementation, I discovered some positioning problems. For the icon info dialog that's displayed, I set the "Center on parent window" bit. The parent window is determined as the window that was previously in the front, but the system does this for me, so it has no way of knowing that I don't want the floater to be considered as the actual front-most window. I added a
CenterOnParent function to the
MWindow class, so I used that to manually align the info window. However then I discovered that this problem extended to the "Do you want to save" dialog too, but here I can't tweak the position by hand, since I use a system function,
StandardAlert to generate it. In the end I guess I'll have to rewrite the function myself, to make it center properly. I kinda had to do this anyway, since I couldn't use it to display the "You don't have the Appearance Manager installed" alert (the function is a part of the Appearance Manager), so things should be quite beneficial.
On a separate note, it greatly amuses me to see that Icon Factory are finally releasing the Pro version of their IconBuilder product (competition to my earlier 32-bit icon insertion tool, theirs is a $49 Photoshop plug-in vs. my $10 one-shot utility), with supports 48 x 48 icons and Windows importing and exporting. They promised this in Q2 1999, so they're a bit behind :p And of course, Iconographer has had these features since it was released (mid September 1999), along with a $15 price tag (their Pro version will cost extra), Photoshop integration, Mac OS X Server importing, etc.