Drum Setup Application Development

[PASHA]

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.

[Reno]

ewwwww....   have I mentioned that I hate IE?   lol

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?

[PASHA]

Ok, give me a min, I have to restart in PC to try that...

[PASHA]

Yes it does work well if moved from the editors buttons - if you dont touch the actual image on the stage, and move the images only using the editors buttons, the images do stay smooth 

[Reno]

interesting... I just got someone else to try it with dragging, and it worked fine for them. This might be a compatibility issue with wintendo running on the mac platform..

[PASHA]

Maybe... Did they try it on ie8/xp??

[Reno]

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

[Reno]

version 0.3.4a
Refinements 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.

[PASHA]

Very cool!!

[KenSanders]

More kudos guys.

[Reno]

A noticed glitch when using IE6 (and probably IE5).. the number vanishes when moved beyond the image border (which is transparent and square). I don't know if IE7 or 8 has this problem.

[PASHA]

Confirmed the number disappears in both mods on IE8/xp...

[Reno]

thanks Pasha, if it were just a legacy issue I might ignore it for a while but since it affects current supported versions it is a 'must fix'.

[Reno]

It should be fixed now..  and, as an added bonus, the number can be moved by simply dragging it (fine position controls work too)..

[PASHA]

http://cyaorocks.com/dsa/

[just wanted to have the link on this page ]

Yep it does work great! - Love the fact that you can just drag the number to a preferred place!!!

It does work good in both modes in IE, but there is 1 small glitch...

Try this:

Open a new empty stage.
Add one cymbal and move it to the center of the stage.
Open the editor and using the controls move the number to a new location.
Now drag the cymbal to a new position on a stage.

The number will snap back to the position it was on the cymbal prior you have changed it via the editor.

PS: From what I see it is not a browser issue... as the behavior is the same on all browsers.

PPS: the strange thing is that it works fine if the number is moved via the mouse drag...

[Reno]

Good find, Pasha.. your ability to find bugs is a huge asset to this project!

number snap-back fixed. :-)

[PASHA]

Yeah Right 

I think it is the opposite way around!

I think that your ability to fix them as fast as you can, is a MUCH bigger asset to the project!

[Reno]

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.

I'm open to any and all suggestions here..

[PASHA]

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??

[Reno]

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

This thing is almost ready to go.

[PASHA]

Well it actually does save already...

PS: Reno I have changed the "-" value back to line break, as we discussed before, but that does not solve the problem...

Script breaks if user inputs a line break or | in description...

I think we should change the data-separators to a longer preset values something like: 157_tbs instead of | and something similar for line breaks...

I dont have any other ideas how to workaround this issue...

[Reno]

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

[PASHA]

Yep just keep me in on the changes so that I would be able to reflect them in the save script. 

[Reno]

No doubt, last thing we need is to clobber each other's work.. lol

[KenSanders]

You guys are amazing.  I am excited about the debute of the results.

I eagerly wait with total antici.....................







pation.