Ok, you will be laughing, and I do feel stupid, but none of it worked, and I did find the onscreen keyboard, but there is no print screen key...

Anyway I made a photo with my phone, it is not that good quality-wice, but you can see what I am about to explain...

Only on IE:

When you add an object (any object - drum of cymbal) the image is round with nice smooth corners, but as soon as you will touch it with the mouse the image corners become... LIKE it is a GIF again... - They are all pixelated.

Note the big cymbal in the corner is untouched, the rest of the objects were moved on the stage...

Look closer at the corners of all the images and you will see the difference.

This shouldn't be a big problem since this is just the setup engine.. once saved and redisplayed in the (unwritten) viewer the images will be static and hence clean-edged. I'm going to guess this is a quirk in the library I'm using for making the images draggable, and hence is rather trivial in the grand scheme of things. At some point I might go mining for the glitch, but for now it's pretty low priority..

question - does the alpha channel black out like that if you move them using the position buttons only?

ie8/vista actually.. I would still like to get another confirmation from someone here though, preferably someone with FF or opera installed to compare results between the browsers

[edit to add:]

minor update, v0.3.3.1a - corrects a numbering glitch introduced when the throne methods were updated (numbers on items and numbers in list did not match).

Throne now obeys z-index.

Base coding written for renumbering items on stage when the list order is changed, but not yet implemented. - done.

This also makes it possible to move the number itself on the image it belongs to so that it doesn't get buried under other items. I hope to have these changes working in the next build. I'm not going to worry about scaling the bass drums just yet, I'll get the pedals happening before I get into the kick dimensioning matter.

It's coming along nice tho, it's getting big but still very fast. None of the delays/lag seen in the flash alternatives...

version 0.3.4aRefinements to positioning in the editor, including the ability to reposition the number relative to the image it belongs to. Future updates to image and number positioning should include a "move by" field instead of the default 1px.

Version 0.3.5a - this one returns the actual data string(s) that will be saved to the server.. there will be minor revisions (eg the addition of pedals and cleaning up the GUI), but this is pretty much the last major revision of the client side script before Version 1.0 Beta.

Ergo, we need to start thinking about the server side program which will save and redisplay from saved data. The only difficulties I see relate to authentication, we will want it to use the dsa cookie for that and, alas, my experience in that area = null. Also, my PHP experience is minimal, I work mostly with PERL.

Flat file is easier for me, done that lots of times, SQL will take me longer since I have never actually used it for my own apps... If we use SQL we will have to build the tables to store the data displayed in the textarea box on the test page, and again that is completely out of my experience (I'm a hobby-coder, completely self-taught.. lol). So for this part I will have to research the SMF system to see how the api works. Viewing setups doesn't need auth, since they will just be basic pages with fancy css (or maybe XML), but saving and updating existing setups will obviously require member auth.

Authentication is not a problem for me, and I would not recommend using SMF cookie for that because it is constructed in a very weird way... something similar to: SHA1(SHA1 username + (SHA1 password + salt)+salt+userlevel) or something similar...

We can do it much easier using the main DSA cookies.

MYSQL is also not a problem for me, I would need to see the flat DB file to create the needed table structure.

Pearl can access mysql by itself so I guess I am missing where did you plan for PHP to come in...

I mean the script can just read the strings from MYSQL instead of flatfile on its own. - Or am I missing something??

The script now has a save button which as of yet does not actually save.. but it does send the values for the design to the server where they are used by another page to redisplay the kit as originally designed.

I'll add pedals and make it easier to add other things (like top-view gongs and such), while Pasha works on the part that sticks the data into the database..

You bring up a very good point, I was thinking about that earlier.. the script that builds description has to be adjusted to replace line feeds with html breaks if the user's intent is to be respected.. that will resolve that issue, ensuring false delimiters cannot exist (I need to parse description to replace or escape pipes too, as well as filter out arbitrary code that might be entered like links and such).