Well, the project is going so so. I need to basically make an heirarchy of debugging tools in order to add so much stuff. I mean… sure. I have a working backbone. It’ll grab any event you can fire it. Store it. And also throw it out to any data sinks you can manage. Now I need to make a canvas datasink, a network transfer sink, a network source, tablet input source, and a mouse input source. After that, I need to give them a few brushes to control. This project is nuts. Why am I enjoying it so much?
So, I’m going to make a dummy brush (basically a monitor pattern, where it sits on the datastruct that hold the strokes from various things and feeds those strokes out to consumers), a dummy brush type (something that interprets that data for any consumers that need more specific data about the strokes), and a dummy data sink (something to actually request data from the brush).
Those three parts need to be in place before I can do anything with unit testing. From there, I just… well… code whatever I want. Raster brushes. Vector canvases. Double ended queues of strokes. TCP, UDP, or raw packet data sinks. HTTP data sources. Whatever. The user interface will be a whole nudder story, however. It needs to use this system once it’s got enough arms and legs to walk (Lets say a raster canvas, raster brush, and a tablet data source… bare minimum. I don’t need to create undo on the canvas if I just make it a data sink… the brush can undo itself manually, even though it might be less efficient than having the canvas manage undo levels and such).
What I think I’ll do for the top system is make the whole thing a different heirarchy… based instead on the user. There will be brush factories… but a singleton for the user’s own brush. There will be canvas factories. There will be much more floaty structure, which also means that debugging won’t require so many pieces before I can begin doing final tests, get an alpha ready for windows and mac and linux, and other goodies will be around.
Why am I revealing so much about the system? Well, for now, I’m sure of one thing… I want the whole system to be pluggable. The end product will let you drop dll’s (windows) or dylibs (mac and linux) to add new sources, sinks, and brush types. Maybe even brushes, if someone really wants to work with hard core stuff like that… but for now I will stave that.
Eventually, I’ll come up with some clever ways to make python routines to a few of the methods that Adobe GIL provides me, and then the paint program will have a python prompt, so that if you want to build a brush, you can start by typing out basics… saving what you did, testing it on other computers. Later, you can put compiled python into the plugins for the program, and it’ll run those like real brushes. Then, when it seems ironed out, you can code the whole thing in C or C++ (I won’t be too picky, I hope… although it’ll take me a bit to come up with a way to allow both C and C++ workout together).
The neatest part about the whole thing is how easy it is to duplicate the backbone onto any sort of thing, and as long as you have a unified system for specifying plugins and such, you can have a webserver that has a flash script constantly acting as a data sink, and then you can a OS level preview app that can read updates from disk and display them on your desktop without even having to download the whole program. That’d be neat, and very handy for a few things.
All in all, I’m reusing so much code it’s making me sick… but at least the bugs have been easy to fix so far. Keep it simple… keep it simple. I keep telling myself.
More updates when I can, but right now, everything is ugly ugly CLI outputs, which none of you want to see, I’m sure. Once I have more ironed out, I’ll definitely show some real shots of the interface. It is going to be snazzy, and will have an Adobe Photoshop look alike interface. That’ll be sweet. And I’ll hopefully be able add an incredibly flexible printer data sink, so that you could even mimic various popular printer specs… like taking an image, creating 32 bit channels out of all the colors using your own custom set of parameters for interpolating or interpreting colors. I think a few of you might know what I’m hinting at… mwahahaha. But it’s far too early in the works to speculate what could be.
I’ll be signing off now. I hope to really really give the world an awesome utility… and it’ll do it’s darnest to a) Not replace any existing work (It won’t replace photoshop, flash, synfig, gimp, inkscape, etc.), and b) it’ll try to improve the availability of everything as much as possible (It will let you work in tandem with software such as photoshop, flash, et. al . online. Across any OS. In real time).
The coolest part is ahead. Because I already have two tablets, so if my fam is willing, I’ll let you know when I have a windows PC drawing on a gimp xcf, and it showing up on a mac psd, and you can watch it via the little linux pc I have acting as a webserver (it’ll only have enough oomph to post a jpeg preview once every 10 seconds or something like that).
From there, I’ll code a canvas that, thanks to the way data sinks work, will have both a tile cache undo history and a stroke undo history (making it use both intelligently will be the tricky part… but I think I can make a linear algorithm that’ll deduce the best choice… so given n tiles + n strokes involved, it can make a greedy choice. But I’m unsure until I finish the math and such).
