Hey, I just checked out what Casey had to say o’er at mollyrocket.com about API’s. I’m definitely coding things up to that. I guess I’m a little late, seeing as how many of the best entries are over three years old now… *pheh*, but better late than never. And the PIMGUI stuff on the forums there just hit me in the nick of time, when I was about to give up that idea.
So, like I might have mentioned before, besides this being a networked doodling program, I want this sucker to have serious loving for the developer in mind and at heart. If you want to make a brush, filter, or import/export script for the tool, then dev plan will start with the command line interface in the program. So, it’ll look like adobe photoshop to some degree, but the idea is that you want to start out typing commands into a command line (I’m thinking it’ll be a text box near the bottom of the screen, which can be resized like in blender to let you edit the script like a file as well) with, like… let’s say you wanted to design a convolution filter. Right now, I’m going for python right at the start. Assuming that still be the case when the beta comes out (the alpha by no means will have any of this working. It’ll be a demo of networking and some plugins), then you might make a selection like this:
Bill = Select(“#FF4500″);
which would put a selection mask for any pixels with an rgb value of (0xFF, 0×45, 0×00) and put it in a reference variable named ‘Bill’ for the currently selected canvas context. I think I’d prolly for now just make all selections mere grayscale 8bit masks (that could be easily changed), and then you’d type in stuff to either grab pixels with that mask, manipulate the values, and put them in a new layer, or otherwise. I think it’s pointless to say anything else about the python API for the code since it’s so far off (I haven’t even started imagining how the top-level interface will integrate it, but it’s going to be fun, and probably not work fully for another year since I only have myself alone on this project), but hopefully it’ll be half as full-featured as the tools in matlab, but a jillion times the speed.
From there, you could precompile the python (which would be spat out in a log file so you could copy and paste the parts you like), and share it with people for feedback. From there, there’d be easy ways to make a few compiled libraries in C or C++ (maybe even objective-c, if I feel especially inspired one day).
The theme would be from there that I’d increase granuality, reduce coupling, and ultimately you’d control every step, atomically, of the process that data goes through… from mouse or tablet to the stroke buffer to the rasterizing/vectorizing code, to the data-sinks, to storing it to disk. All of it has to be open. And the nutty thing would be that since the whole api is built around peeling away and inserting, you could easily leave holes in the process or back-doors to test further python code for debugging or feature addition as you go.
The idea is that I really really want this to be academically friendly, and the C++ code should start with high retention and even higher coupling, so that at the start of things, you might only need to make a simple callback function that looks at pixels in an open format and lets you manipulate simple character or floating-point values.
It’s my hope that this’ll encourage people to do all sorts of cool stuff, and sandbox the whole thing. You could, with just the rudimentary heirarchy I have right now, maybe build an entire game which takes in tablet input. It wold definitely work horrifically, since I haven’t really made any mid-layer API which would let you more easily pipe things to and from, say… a video processor. So you’d end up doing 90% of the work for some very trivial things… so don’t you dare complain if you want to try to do something like that.
The only tools I’m going to provide are those that make it easy to make four primary things:
A simple Immediate-mode GUI for a tool of yours.
A very in-depth, completely crazy brush tool of whatever making.
Somewhat freeform filters and signal processing scripts.
Storing data and drawing it however you like, to any device you’d like.
Argh. I hate how ambiguous this all sounds, but as much as it sounds like I haven’t done any work, I’m pretty far with the core API.
But wow… crossplatform is currently my new wall. And So I think the first thing I’m going to finish is either:
a) Retrofitting a temporary, open Immediate-mode GUI library
or
b) Coding some very basic widgets that draw to a context within windows of each platform (windows, mac/BSD, and linux)
I never knew how easy it is to see what you want to do, have it all charted and all the CSE crap finished (growth analysis of all the various retention strategies and interfaces and so on), but still be completely dead because of all the GUI and OS head-butting that happens during implementation.
I’ve got to say, if I lose my head, I might just git r dun with OSX first. Then, I’ll migrate slowly to windows. But oh man… man oh man… if only I could just… do what blender did. That immediate-mode widget stuff is hawt cha cha (when it works, and you know how to keep it simple).
I think I’ll go look at the blender sources and slobber for a while longer.
