Okay, I know I’ve said it before that I was getting tons done. Well, I’m about to have graphical proof!

I just got event passing working on my code project. It’s awesome. Now I’ll just be making resource concepts using templates and boost concept check, and things will be groovalicious!

*moments later*
Ah. So this is what bites for now. I’ve got a lot of resource concepts in the code (besides additional libraries I’ll allow the user to plop down inside the program dir). XMPP hosts, directly connected users, disk IO, graphical contexts, and also memory storage (primarily for events and mostly discrete data). The thing is, they all dole out various resource share types in order for me to get everything to connect smoothly. Really, I do that because it makes threading much easier by designing read-only and easily parallel code to just work at the highest speed, while allowing other types that need write permission (and thus mutex/blocking) to also still work. Some resources are also plain ol’ monitors, with their own worker threads (you pretty much have to do that for net IO), and so they need to create shares that are really just fancy looking thread-safe buffers.

What am I getting at? Well, the worst thing I could do is design OO to just wrap around everything. That would turn it into class/object pea-soup. Design patterns are always stumbling blocks when every problem you are solving is really separate and unifying any two resources under a pattern will typically lead to a golden hammer scenario (suddenly, you gotta make everything a nail or else it won’t work). Rather than tie myself down with all that junk, I decided to just design concepts using boost’s concept check. All’s well, but still… frustratingly enough, I have to create about 4 classes per handler to make everything work out, because my pointer storage will allow virtual function tables and all, but you still have to make first a base class (to build the VTable on) and then you have to make a template that inherits, which will also let you store share pointers in it. But don’t forget that the handler needs to design a template for the holder, which will concept check the incoming share. Now to make things even sillier, this all won’t work unless you then create a share class that caters to that concept. Still… if you put in all the infrastructure… suddenly… it just works. And the design is rather static… you literally only need to make an empty call to a function or member in the concept to add to it. And you only need to add virtual functions if it’s completely necessary… and usually they just call new concept functions. So, once in place, it’s not going to be hard to expand. Still, it gets a little tedious to update three classes to add a feature (the concept, template, and base).

Whatever, though. I’d hate to try just doing reinterpret casts and all the other madness that you have to go to just to get the same functionality without type-safety. And the concepts generate nice error checking… and the VTable sure is dandy. It lets me partially specify special cases of the template class to revert to the base class functionality or just completely add new and bizarre changes if I so desire (at the cost of adding… you guessed it… another object/class).

Still, I’m hopeful that the thing won’t be too huge a pain in the end. And the idea is to reduce feature changes… and mostly just make it easy to add as many resource share types as I want without the fear that something will break, leak, or take a hundred additional changes just to support it.

The bottom line: OO will always be evil. And I really just gear my UI to be as ignorant of it as possible (UI + OO + adding features = painful death). The downside of it is that my executable code is getting REALLY big… even with -O3 and lots of added stripping to the release binaries. And geez… I still gotta add the individual resource shares once I make them transport data trivially (hopefully tbb will make tuning the CPU usage of each worker thread painless).

We’ll see. For now… I’m optimistic. I SHOULD have a real alpha before classes start. Why? Because I’m confident that if events are working (the part I thought would take forever), data generation to follow the events is merely brainless function calls and byte pushing. I hope. I hope I hope.

OH! and using OpenGL plus nvidia’s lil’ IMGUI toolkit has made the UI side of data representation and threading almost TOO easy to pull off. I love that so much more than any other type of GUI. I can’t tell you how much I hate retained GUI’s, because of all the work to keep track of EVERYTHING on the screen.

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.

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

Hey all!

I thought I might as well prove I’m still alive here. I bet wordpress is getting an itchy trigger finger for deleting me from inactivity, right?

Well, here’s somewhat of a plan I have for getting things done.

I’m rewriting my brush code for my paint program… it’s pretty hilarious to think this way, but I thought I’ll turn my stroke buffer into a parallel datastructure using TBB (threading building blocks). It’s ridiculously easy to do with that library, and you can’t argue with the license. Free is free is free.

I’ll do what I can to give up details on that without giving out too much particular intellectual info. That is, I want to help others start using this library. I might even make an expansion on a structure and post it here.

Also, I’m still in the process of adding adobe’s GIL to the project. Who knows, maybe they’ll like my project enough to give me a few features I might ask of them (More details on that later)

All in all, someone at the arts department at USF seems interested in the project enough that I’ve got a tremendous amount of steam pumped back into the whole thing. I might publish an svn view here if anyone wants to get an idea of how much work I have ahead of me… and lordy, if anyone wants to help me with windows coding, that’d be great. I have OSX leopard and XP, but no vista. And I’m not about to try to install that monster on any of our home computers.

Also, I’m investigating the possibilities of making my first networking module based on SCTP… and later doing a UDP version. TCP is going to be a little… too wonky in some circumstances, so I need to reengineer the brush stroke adapter classes so that I can more easily send a ’stream’ of stroke data. The format right now is very much chunk oriented, and using TCP will put a lot of zaniness on the client (the server always has it easy with just memcpy and wot-not).

Hoody hoo! back to work! I’m learning more about SQL and I might also be learning flash very soon. Again. *sigh*

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)

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.

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.

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.

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)

Wellp… I dunno how or why, but I find myself wanting to rant. I’ll do my best not to, but I’d like to voice something about CGAL (and hopefully later when I have time, I’ll voice my concerns on their mailinglist…). I’m mostly doing this for people who might google this and wonder about it, or just to get some feedback. I’m trying to use the KDS in CGAL, and it’s making me want to cry.

Right now, when I look at the Delaunay Triangulation (the 2d one, that is) kinetic structure, I flat out cannot figure out how they are using edges from either the documentation or the immediate code. This makes the visitors and recent edge goodies a little difficult to harness. Now, right off the bat, I’ll confess I’m not using the library in a normal fashion, but wow. This is weird. I think they are using the edges as STD::Pair objects, storing a Face and an integer for the edge label of that face, thus forming an ‘edge’. I guess?

Well, what I want to do is manipulate the structure and nudge it like any good ol’ KDS, but then as updates occur to the edges, I’m trying to form an RNG (relative neighborhood graph) from the edges and update it as well. But, it doesn’t call for an all out KDS because I’m really only loosely using the RNG and it’s overkill to make it into a KDS. See the problem forming here? I’d really love to just get these “views” or “observations” at the structure of the triangulation from the visitor… but it’s becoming a serious pain. But… they have it… so it SHOULD be usable… right? I mean, I want a DCEL structure, to be honest, but the structure they are using is a little hard to comprehend. Sure, I can generate meshes and such from the KDS, but those will be constantly changing, so the KDS will cause a lot of problems for the simulation’s overhead.

Correct me if I’m wrong, but this seems like the armpit of the KDS right now (accessing the structure on specific events), and so I don’t want to criticize the team behind CGAL or the KDS stuff it has (it’s really cool junk!). You know, it’s probably something obvious that, due to my lack of experience, is going right over my head. But wow… I hope they’ll explain it one day… I’m writing this here and not in the mailinglist since I sort of want to submit a bug-report… but then, I’m pretty sure it’s not worth them changing anything. The ‘weird’ programmer must typically hack and burn his own trail. So I guess I’ll just post this here, and any interested parties can discuss. If I find anyone coming in here trying to use kinetic data structures in CGAL and they find issues with the edges and triangulations and visitors as well, then perhaps I’ll bug the CGAL people… till then, I’ll just post any updates I have on the issue here.

Well, I have to go now. My sister’s stinky chihuahua is groveling at my feet. I need to see what his problem is… or perhaps feed him to the neighbor’s cat. Yes… that’s what I feel like doing now… lemme just get some ketchup (cat’s like condiments… right?) and some tunafish… I’m sure I’ll work something out.