It was suggested that I release my face-expression editor to open-source. I agreed on condition that an adequate team of volunteers stepped forward to assist the process of making it a general-use product. Sad to say, the response was too weak to justify proceeding to open source, so I have decided to keep the thing private for now. I’ll try again at some point in the future. In the meantime, though, I spent the last eight days rewriting the code to make it cleaner, easier to understand, and more flexible. I expanded the window size to permit the display of both the big editing face and the smaller final display face:
I confess that there’s a lot of wasted screen real estate below both faces. It turns out to necessary for some infrequent situations. I’m thinking about how to correct that, but for now I figure that the only user of thos editor, Alvaro Gonzalez, has a big enough monitor to handle it; the current window size is 1300h x 1000v.
I faced some interesting difficulties while preparing this version. I had decided to finally replace my use of assigned Constants and simple Arrays with the more hip Enums and Maps. After screwing around with both approaches, I eventually decided that the older, dumber way is still preferable. Some people just can’t get new ideas down their craws.
I was unable to properly encapsulate all the data. My goal had been to have a few classes that serve only to draw the final image, with a completely separate editor system that wraps around the drawing classes, and the drawing classes are never aware of the editing classes. It didn’t quite work out that way; I had to incorporate some data structures for the editor into the drawing class. This arose from a trade-off between programming clarity and full encapsulation. I had established a simple rule for nomenclature: every data structure that was used for the editing image on the left had the word “Big” included, and every data structure that was used for the final output face on the right had the word “Small” included. Thus, I had rightBigX and rightSmallX, bigVerticalOffset and smallVerticalOffset, and so forth. This nomenclature makes it much easier to track what’s going on with the software, but I felt it necessary to include all such data structures in a single class; only that way could their relationship be clear to the programmer.
No, it would not have worked to make two instances of the same class, one big and the other small, because their properties are calculated differently. The code would have been peppered with if-statements: if (this.isBig) then do it one way else do it the other way.
Anyway, it’s done for now; Alvaro is evaluating its new functions and will get back to me with change requests. In the meantime, it’s back to Siboot.
