Neat API thoughts February 1, 2009

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.

Debugging and such January 15, 2009

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).

Awesome command line utility June 5, 2008

Okay… while I am not a huge CLI buff (I’m getting there… ), I know that this has “new future fancy command line utility” all over it.

These guys over at Cheat have ingeniously put wiki support into the common CLI. While it’s new (and thus experimental) I’ve really found this a joy. You can grab stuff that’s not caught on a –help call, but is nestled too deep in a manpage/infopage to be worthwhile searching. And by grab, I mean grep.

The nice thing about it is how easily you can edit and update the pages. What I hope for in the future is that this’ll have more ‘wiki’ like features. That means linking cheatsheets and allowing terms in a cheat sheet to have pages written up on them.

Also, there’s no real… ’security’

Like, I saw a typo in the cheatsheet for bash, so I edited it (for guffaws, I thought), and lo and behold, it sent the update to the main website. egad! So, I am assuming they’ll hopefully put security up soon if it becomes big. Either way, this is puh-puh-powerrrrrful.

And it seems everyone using it is rather terse and in general these tidbits save a lot of time.

Eventually they should also put up separate page version depending on your architecture (case in point, because I have darwin right now, I’m not exactly… ahem… going to use all the same commands)

How it worked out May 5, 2008

Well, I went through, and found out that I was, while it wasn’t too hard to implement, going to be reinventing the wheel too much with lightbox2 . I found that it has been painful, however, to add lightbox to the site. A rather large 200 Kb footprint… not so easy on me since I’m already loading a lot with spry (Spry data is hefty. It makes up for it with the complete and total cleanliness, but still… ickypoo!). I’m going to rebalance the load on the server by throwing up some thumbnailers and eventually I’ll get to a level at which I can make the page also gracefully degrade from JS for all you textual/cellphone browsin’ peeps. Later, if I feel masochistic, I’ll put in some code for AIR and the like so that you can load it on an iphone. It totally won’t be worth it for now, however. And ack… what a pain. The added size in JS files. Does prototype HAVE to be so big?

I tried using lytebox, but no beans. It simply chokes on the SPRY, is what I’m thinking is happening. Otherwise, I could cut out a lot of the excess. :-/

I’ll go into aptana and try to debug lytebox later (it’s still on the server), and see what I come up with. It probably won’t be pretty… but it would be worth it just to reduce the script overhead.

Yet another terrible idea in AJAX May 3, 2008

So, I’ve been reading a lot more now and have started goofing off with mootools and mochikit. And yet, I fall back to spry. And so now I’ve got this ludicrous scheme of js include juggling to try out.

Spry is awful good at filling in data.

MooTools has compact effects.

Mochikit pwns the DOM.

But. I need all three features… I need to handle xml data rapidly and compactly (there’s a lot of data! tightly nestled in dense xml to save on transfer time), I need effects that aren’t going to kill CPU’s or require lots of includes, and I need to chuck DOM modifications out as I change the focus of the web application. :-/

It was nearly doable to put mootools into Spry and throw around some DOM hacks, but as I’ve been going through it, I have to agree… this is becoming a ton of unmaintainable code. Something that reeks of ‘google google google’ and when I did, Mochikit seems like a great solution. But, ah. That’s the crux. Should I get script crazy? Ick. Right now, I’m more or less loving mootools, but the mochikit is the straw to break the camel’s back. Either way, I’ll get back to this blog on the progress of my projects if I decide to go through with it. As you can guess already, the RSH hack simply didn’t work out. It’s for… I’m not sure… something like google mail or something the like. Otherwise, I’m just better off doing my own cheap URL anchor hacks by my own wit. I can’t bash anyone for using RSH, but it’s a pain if you don’t need the whole thing, as far as I can tell.

If I were to splurge and put everything I wanted on the page, it’d probably be about 500k of code, and about 24 k of content. :-/

So, back to chunking solutions into the air in the hopes that I find a quick fix for various things.
In the end, I’ll hopefully have a good looking comic browser of sorts for my site. You know… with chapters, page turns, searchability, and xml fetchery fu (if I see another comic that has buttons that just change a single image by reloading the whole page… again… I’ll cry). Keywords might have to wait.

DOM and me (and our marriage counselor, Aptana Studio) May 3, 2008

A budding relationship. By budding, I mean I need to send flowers and pray there isn’t a shotgun wedding. Herein lies my tales (so far) of taking a server I have no control over, and turning it into a ‘half’ AJAX web-service. I’ve been recently messing with the DOM, and besides having half of what the w3c says going straight over my head, I’ve been making progress. Sorry… let me rephrase that:

Hacking the DOM is like begging for ie and ff2 errors and bugs. To be honest, it’s deadly and you should be very careful with it. For now, let me just say that *cough*hugemegaGHEYadvert*cough* I’ve been loving Aptana studio. It has an immediate listing next to each crazy DOM feature, listing compatibilities and warning you about which things will fail vs which will succeed on various browsers. And it’s been a lot easier and fluid than dreamweaver, which I guess has somehow… gotten too clunky? Well, either way, it’s now been made much more viable to hack at the DOM with Aptana telling you why some of that stuff is scary. If you can combine this with a decent knowledge of how to build coherent conditionals (those awful ” ? : ” blocks are what I’m talking about), and you’ve got a very good way to crush these problems as you hack away. Plug in the debugger, watch the pretty activity meters and funky console output color your page, maybe enter a few commands to make sure things are straight. Now go back, hack some more, put in conditionals, do the debug runs, rinse, lather, peanut butter, repeat. (I also recommend coffee to avoid segmentation faults)

So, I need to really review Aptana more harshly on this, however, because this process is centrally two-fold… hack first, but then you need to debug and test what you do. But the debugger is hard on the browser. I mean, it’s not all just a bunch of farting rainbows and happiness… but take a moment to enjoy that dream for a moment. Lil’ more. Kay? Great.

Okay, so here’s some beef with this system. I’ve been messing with Aptana on macOSX for a good bit now too (about two days. Yes… two days. … Stop laughing. I’m serious!). While I’m a total novice at AJAX and DOM hackery fu, I’ve noticed some consistent bugs (meaning: easy to get around, but annoying) when it comes to using firebug in tandem with Aptana’s debugger. Firefox just loves to choke. So, when you’re busy hacking this stuff up, I definitely suggest that you also try using a pseudo setup of Spry’s debugger (pretty easy to include… it has a frustrating interface, but it works rather swell for things) and the firebug debugger. The reason is that I’ve found re-loading and restarting the debugger has become… paaainful for firefox to endure. The best bet for your money is to use aptana to code up some junk, do a quick debug run, then do finetuning and tweaking and anything that might be just a bunch of mostly stable, small changes with the spry debugger or another onpage debugger. This seems to really keep things finely greased and unflinching. Of course, you sacrifice the debugging features from Aptana… but then, their debugger really fails at small tweaks, and even firebug, I’ve found, tends to bloat a little and slowly screech things up a bit. Borking is normal debugging order, but I’ve found that an on-page javascript debugger seems to really cut down to brass tax much faster when you don’t need too much sophistication.

Otherwise, this Aptana studio fellow has been really brilliant and a great spinoff of the Eclipse IDE format, which I’ve thoroughly enjoyed *cough*moreBIAS*cough* but that still doesn’t make it foolproof for what I’ve been doing. I can’t quite square away what could be making firefox so unstable. I don’t hear a lot of other people getting the same issues (yet… maybe I’m looking in all the wrong places), so I suggest that you play around and see if you don’t get the same issues. If only it worked on safari, I could definitely nail it down. I have a few more extensions to check out and see if they’re causing problems, but otherwise, a whole ‘restart’ of firefox every other debug run has been my only major complaint.

….

and of course, I haven’t really tried anything else with Aptana other than Spry. Every time I start a new test project… I already heartily thumb away on google, sifting the pages about all the other free AJAX libraries… and I think I’ll start seeing if the debugging goes smoother with them.

This is a really lousy review, and hardly touches upon Aptana… but then, I don’t have time to go through and just talk about everything. I think it’s better that way… let other people talk about it more.

Thoughts? Angers? Icecream? Maybe you thought this was about marriage and started to wonder what country I’m from and which Babel fish server I used to cough this page up? Comment and hopefully I’ll be around to mod/add anything spam karma wants to be touchy about.

Elite Spry Ajax hack #1 and 2 March 22, 2008

Well, while this is not for the faint of heart, I found a cool trick that I bet a lot of people might like to see… And no no… it’s not so much “elite” as it is “asinine”, but since when did ANY hack not connote that? I’m pretty sure the #1 way to win a job interview for a coding job is to walk in with a shirt that says:
“For all your bug attraction needs, use “Mr. Clever Hack” the all purpose coding spray”

*ahem* Disclaimer aside, let’s go on

So, I have effect clusters that are similar to the cluster examples in the SPRY Cluster Sample page ( link ). But, I want it to work with images, and each image is differently sized, and to make it even crazier, the image is contained in a paged view, which means it will only be available at runtime… there’s no predifined, static declaration system that would work short of making a whole new xml document and maintaining it with my images (ICK! who wants to do that?). Here’s how I did it, with a bit of CSS and Spry debugging help (the spry debugger will help you get a grasp on the harder things to manage).

Here’s the key concepts:
You can always have access to the height of the image if you keep it somewhere hidden (which the cluster allows). So I just nest another Div inside the div for the image… I called one “#Comic_Display” and the other “#Comic_Image”. Just make sure that these are UNIQUE (hence the ID’s), or you will have trouble figuring out which image to get a height from (ie, if you had fifteen divs called “Comic_Image”, you’d have to go through a lot more work to access the pertinent image dimensions).

HACK #1: Using spry to access an element from the client side

This handy line will allow me to, at any time, see the height of the Comic_Image div.

Spry.$$("#Comic_Image")[0].clientWidth
Spry.$$("#Comic_Image")[0].clientHeight

Of course, the $$ function grabs the DOM element via the css id it has (so make sure it’s unique!).

Notice that [0] which is going to be pertinent only if you have more than one “#Comic_Image”. This is also cool because if you did have multiple images, you now have a way to iterate through them via the array index so that you can average the dimensions (that way you could maybe find a way to normalize the images).

After you choose an index, client width and height are the functions that grab the display size of the image. You’ll want to test this on your platforms. If this hack doesn’t work, you might have to find a different way to get the width…

HACK #2: Making the clusters change their properties (this has a lot of setup, so bear with me)

If you have the spry debugger on a page somewhere, try making a “new Spry.Effect.
Every size effect ends up having these member variables:

startWidth
startHeight
stopWidth
stopHeight

To change our effect inside the cluster, we just need to refer to it, and command it like so:
EffectReference.startwidth = somewidth;

Let me show you my exact way I pulled it off… then you can chortle quietly at my horrific coding mannerisms and peeves (oh the joy).

I define my cluster constructor like so: (look at the spry sample page for hints as to what this does… you really almost need to know nothing about what this is doing… just pay attention to a trick here:

var comicSqueeze;
//this will hold a reference to our effect so we can change it

var my_cluster = function(element, wid, hei)
{
	Spry.Effect.Cluster.call(this, {toggle: true});
	this.name = 'my_cluster';
	///
	//Assume there are already several clustered
	//effects in here, for simplicity, I'll only show one
	///
	var resize_ver = new Spry.Effect.Size(element, {width:wid, height: 10, units:'px'},
			{width:wid, height: 1000, units:'px'},
			{duration: 500, toggle: true, finish:
			function () {
				contentTransition=false;
			} } );
				//this finish function allows me to reset the
	this.addNextEffect(resize_ver);	//transition state. You'll want to put this in
				//your last effect in a cluster that might be
				//clicked several times on accident...
	comicSqueeze = resize_ver; //using this little diddy, we can have a handle on our comic squeezing
}

Now then, that’s fine and dandy, eh? This function creates a cluster (I assume you know how to attach it to your own cluster class, right? Just comment on this article if you want help), but it isn’t dynamic. Yet, it does use the global “comicSqueeze” to give us a reference to the resize function.

Now, everytime we need to transition, I use this classy function: (assume I’ve already declared and initialized my cluster with the call “clusterList = new my_cluster(“Comic_Display”,a,b);” where a and b can be arbitrary heights or widths.)

function transition(){
	if (contentTransition){//this keeps the user from knocking our cluster out of whack
		return;
	}
	else {
		contentTransition = true;//ensure that we are the only ones starting a transition
		comicSqueeze.stopHeight = Spry.$$("#Comic_Img")[0].clientHeight;
		clusterList.start();
		return;
	}
}

See the cheap trick? So, I just use my handle “comicSqueeze” to change the height by looking up the client height. Simple trick, but the possibilities are pretty high and mighty.

I’ll stop talking about my handles so you people can stop holding your ears in offense. Have fun, and comment if you have questions (I must admit, it’s a very unorthodox trick to get the clusters to update)

More programming hilarity March 8, 2008

While all my other projects stew and simmer with a myriad updates and includes from the latest brews over at boost.org, I’ve found myself having to code a computer geometry project. It’ll be a particle engine that uses Relative Neighborhood Graphs, and it’ll be hilarious. My professor is convinced we cannot make a geometry project into a screensaver. As such, my practical reasons behind the particle engine are ’simulations’. Currently, I think I’m going to simulate crowds of people under attack by zombies. It will rule. And while I might get a horrific score, my presentation shall rock boxers like b-grade sci-fi flying saucers on fishing lines. I’ll ALSO be posting updates on that if and when I get a chance (besides the AJAX work and other things).

A big note: for all those reading this saying “Wha? You haven’t posted a real ‘update’ on anything… really”. I just gotta say, I don’t like wasting people’s time (stop laughing! I’m serious!…. almost)… and so I’m going to wait until I get something concrete with pretty pictures. You’ll see what I mean. Eventually.

Arrrgh.

Goodness Grief… AJAX and ASP and SQLServer February 22, 2008

Good and bad news.

I got a job!

But It’s with SQLServer 2000, and I want to do Ajax.

I’ll hopefully be bringing you some cool hacks that will make web development easier…

For instance, I know that if I work on it, I’ll be able to get an ASP class that turns SQL queries into well-formed “For XML Explicit” queries. Of course, I want to make it a class because the admins claim they’ll be getting sqlserver 2008 sometime soon (of course, they also had planned to get sqlserver 2005).

Also, I’m currently using spry, and so I’ll be trying to make that rather dandy too. I think that the number one debug issue I have is detecting malformed XML from the sqlserver, so I’m going to be making template xml pages, so that my AJAX will quickly throw out a “Oh snap, one of these things is not like the other” error. Mainly, that’s going to be heavy and slow things down a lot, so I’ll code that later when I start hitting more bugs as I grow my database… that way I can load it and it’ll hopefully integrate with the spry debugger (that thing is spiffy).

What this all means for this blog is that, as I figure stuff out, I’ll hopefully log it in here.

Up next: getting RHS to make my AJAX create bookmarks and a history for the web browser… and somehow get it to work on everything (except safari. As it is, I’d rather ‘explore’ than go on a safari. And lizards are neato. So, I’ll be prejudice and also the incompatibilities that I overheard about DHTML and safari were… cooky sounding. Anyone know if I’m off base to exclude safari?).

Also, I’m going to be making some strange uses of SPRY that… might break it. I’ll post if something goes awry.

proof I am not dead September 14, 2007

woo! giftart for someone: