[Tyhm]

...um. Okay. With my way, one could do the orbiting-moon problem with one line. With your way, it requires hiding and showing two seperate images - because you can't change an image's index, but you can change an image's layer. Therefore, sorting by layer makes a LOT more sense than index - you can edit the heirarchy with changeimgvis, you can't edit the heirarchy at all if it's bound to the indexes. If you have img 0 over img 1, and you want to put img 0 just behind img 1, my way you just changeimgvis, your way you have to hide 0 and show 2...it's just way too much of a headache.

Babbling. I was up for 38 hours straight yesterday.

We have your implimentation and my implimentation. If Stefan uses your implimentation, the only way to sort by layers is to juggle indices - a REALLY ugly problem. If Stefan uses my implimentation, you can easily sort by indices - you just set the layer to be layer+(index/maxindex). Further, what if you want to reverse it, so instead of index 0 being the top, index 0 is the bottom - what if Stefan does it in a way inverse to what you were hoping? Your way, you have to change your image indices, everything gets ugly. My way, just change the formula to layer+1-(index+1/maxindex). Simple. Elegant. Doesn't even require a single command addition to the already rapidly expanding lexicon - just change changimgvis from int to float. Boom. Done.

They can both be done my way, they can't both be done your way, is my point. It's a good idea, but I stand by my implimentation on the grounds of expanded usefulness and simplicity.