Scratch

Or a seperate table... One for the image info itself - user, canvas size, publicity, Id, then one for all the image elements.

Boy I'm gonna have to brush up on my PHP image creation.

What do you feel we can and or should do about  nesting? For example, should an online/offline sensor be an element that can house two sets of elements? Should a random element be able to house several (currently 10 in the API) images/elements? Nesting sounds like it could really increase the dynamicness of images, but it also sounds like a path fraught with problems....

Perhaps child elements could refer to a parent element ID as one of their attributes, and the parent element could refer to the child elements in boxes specifying conditions. So for example an online/offline element could have a list of elements in a "condition1" column, and another list in a "condition2" column. Similarly the random element could do this with 10 or so condition columns, though I loath the idea of that many condition columns... Otherwise we could go back down the decoding route where there is one conditions column and the element lists condition numbers and the containing ID's

#1:1,2,3,4#2:5,6,7

could then be relatively quickly decoded to:

Condition one: show elements 1, 2, 3 and 4
Condition two: show elements 5,6 and 7
No more conditions for this element.

Last edited by sparks (2012-06-20 16:53:46)

LiquidMetal wrote:

Will the current, no-login-required method still be possible (including the new features of the API)?

I don't think I'll be updating the current API to support any features we add to 2.0, but I don't think I'll remove the current service.

LiquidMetal wrote:

I'm confused.  Are "skin sets" here to mean groups of pictures?

The idea has sort of evolved a bit since I posted that. I think the idea would be that the entire interactive image could be made public so that another user can use it too.

That's a good point, I'd better add a whitelist filter to the existing API. Or remove the service, I'm not sure yet.

You know your current siggy? How it is four API images stuck together, each can display one interactive element? Well the new "entire interactive image", will be able to have more than one element, i.e. you can replace the four API images used to make up your signature with one. When I say individual image, I don't mean an image being used by the API, I mean the finished API image with all its interactive elements 

Yeah, I think that makes a lot more sense, and is easier to do!

I'm thinking that we're going to need one URL attribute, since the image can obviously have only one link.

You have your last exam today, don't you? Good luck!

Last edited by sparks (2012-06-21 05:39:35)

sparks wrote:

Yeah, I think that makes a lot more sense, and is easier to do!

I'm thinking that we're going to need one URL attribute, since the image can obviously have only one link.

You have your last exam today, don't you? Good luck!

The URL attribute I included in the diagram is for the image location, not the link 

My last exam was indeed today, and it went pretty well. I can maybe expect an A 

sparks wrote:

Excellent! And yes, I got that it was the URL to the image, I was sort of mentioning on one side that there should be one link attribute similar to the canvas in that it is one element that can't be deleted (but disabled).

But why is it needed? Won't the user create the BBCode himself?
EDIT
Oh, do you mean the URL that will point to the image?

Last edited by LS97 (2012-06-21 15:07:07)

sparks wrote:

Erm. The url to accompany the image. Or, if they wanted, just the URL. so the url could be generated to link to their nth newest project or a random URL or something. It wouldn't technically have to go with the image, but if we do them together they can belong to one project. When you click create it can create the image URL an the link URL.

I still don't understand, but I'll just let you do that and watch 

sparks wrote:

You know the current API's link system? Link to n'th project, random link, that sort of thing? Well when someone makes an image with this GUI, they may want a link with it. Since we have a canvas element, the link could be part of that element's attributes.

Oh! Yes! Definitely 

sparks wrote:

Hmm, what's the next step then? Should we start on the page, or start looking into PHP image rendering or something?

EDIT: I think we're only an hour apart timezone wise. Are you home tomorrow? That might be a good day to make a start!

Yes, England is one hour away from Belgium in terms of time. It just so happens I'm leaving for a tennis match soon, and then having lunch at a friend's house, but I should be back by 5 o' clock at the latest, which means your 4:00.

Why don't we go along and start with the API anyway?
I imagine we'll need a testing server for this too.

sparks wrote:

I was torn between working directly on blocks.scratchr.org and setting up a permissions page that lets you view and edit files belonging to the API project and setting up a test server. However, its probably easier to set up a free server. 000webhost to the rescue! (Yup, I like their sites too!). I'll set one up and get the details to you somehow. I might make a start on the site graphics as well, but I probably won't start on the JS just yet (it scares me).

I think you have my email. If not, contact me through the mod share help form (but don't send the details right away, wait for my reply since there's also another support operator)

sparks wrote:

No, I was surprised but I don't seem to have it. I've contacted you on the modshare site now 

You have to disable IP security in Customer Details, as we live in different countries.

Oh, I didn't get round to starting on the graphics somehow. Sorry. I still need to orangeify it.