Sugar induced socializing

A sketchblog by Dudymas

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

Filed under: Creativity — dudymas @ 10:22 pm

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)

 

CGAL documentation March 15, 2008

Filed under: Computing, Review — dudymas @ 7:01 pm

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.

 

More programming hilarity March 8, 2008

Filed under: Creativity — dudymas @ 5:48 am

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.