search bar in costume/background/sound box

[brianharvey]

I just added all the Scratch costumes (minus the ones they restrict), backgrounds, and sounds. It works, except that there are a lot of costumes, so it's hard to find the one you want. So there should be a search bar in that window.

[jmoenig]

Oh no! @brianharvey didn't you get my urgent email cautioning you to please not upload SVG costumes at this point?

Next time, I'd appreciate if you didn't push this straight to the production site, but instead let us test it at some safe place first (like the dev url)

[towerofnix]

At least you didn't upload things like the Scratch cat and such which are trademarked or whatever. Legal licensy stuff isn't fun!

But getting a +1 from the ST would probably (read: really) be a good idea..

[brianharvey]

The urgent part seems to be under control. Now back to my feature request...

[jmoenig]

Yep, agreed! 👍

[brianharvey]

@liam4 We had gotten explicit permission when we stole the Scratch 1.4 media library (minus the cat, which was then the only restricted one), and we're friends enough that I figured that was still valid. (I believe there's no problem legally because all of 2.0 is free (as in freedom) to modders apart from the trademarked characters.)

But, believe me, staying on good terms with them is important to us, not for some tactical reason but because, you know, we're friends!

[brianharvey]

@jmoenig Actually, we really want something like the category-tag system Scratch uses, to reduce the overwhelming size of the costume collection. Another possibility would be just a costume-family feature, so that, for example, the 13 different anina* costumes would appear in the initial costume menu as a folder icon with one picture of anina on it, and clicking would let you either import all at once or open the folder and let you look inside. The four, I think, fonts would each be a folder. That would cut down a lot on the size. The way it would work is that the COSTUMES file would list the folders but not individual costumes that are in folders, so that the dialog would go back to popping up quickly.

Actually, it's not clear to me why COSTUMES is a useful thing (as opposed to reading the directory as we used to do). LIBRARIES is useful because we want relatively verbose explanations of each library, but COSTUMES is basically just {costumefile} {tab} {costumefile-minus-extension}

[cycomachead]

Because before we were abusing Apache's index.html files. Parsing HTML is slower and messy and liable to break if the server config changes and makes Snap! much less portable. Also, the files allow for translation and presentation of names which aren't just the file names. {costumefile-minus-extension} is mostly true but oversimplifies canonicalizing things like hyphens and capitalization.

[cycomachead]

We can also do things so that the dialog doesn't need to load all files before presenting them or we use something like 80x80px thumbnails (or whatever the size should be).

[brianharvey]

Hmm, I made the COSTUMES file with a couple of Emacs keyboard macros, not by careful canonicalization. They have some costumes named gobo and others named Gobo, I think. (I merged the new ones with our existing set, so maybe some are obsolete.)

But okay, I'm convinced about COSTUMES. But sad, because it would be nice if we could make the family-folder structure just follow actual subdirectory structure in the Costumes directory!

But I suppose you guys are going to argue for using tags instead of hierarchy anyway. :)

P.S. Who is going to bell the cat about this thumbnail thing?

[cycomachead]

If thumbnails are an acceptable solution then I can work on this -- it shouldn't be too hard. We probably want to figure out how this works for sound files / if they have a problem.

[cycomachead]

We can still implement a hierarchy with COSTUMES. In fact, it's easier to do so, because we can encode the hierarchy in one file and then it can just be loaded once.

[jmoenig]

I'm fine with any hierarchy / tagging mechanism you guys come up with! I guess we should also modify loading the resource meta data asynchronously while we're at it.

[cycomachead]

I guess we should also modify loading the resource meta data asynchronously while we're at it.

Yeah, we should load pretty much everything async..

As far as a hierarchy -- what problem are we trying to solve? Loading speed or finding things? If it's loading speed, I feel like we should try to solve that properly by making that fast. If it's finding things, I think a set hierarchy is probably better, but how many costumes are we taking?

[jmoenig]

Well, I'm seeing several more or less complete alphabets, and those tend to show up first whenever a kid might just be looking for a monster :-)

[cycomachead]

Oh...I didn't realize we hadn't reverted everything.

Oh god...this is bad.

[jmoenig]

Wait! we didn't revert anything. Your sorting changes only affected projects, right?

[jmoenig]

Just to repeat this once more: In the future let's please not push stuff directly to production, okay? Let's play with changes in a separate "dev" or "test" or whatever you want to call it environment first.

[cycomachead]

I haven't touched the server, but otherwise I agree. (I personally would go as far as to suggest never committing to master and not ever touching s.b.e directly, but that's a side story.) I thought BH (based on this thread) undid the changes on s.b.e but I see that they're still there. Including the fact that s.b.e != GitHub repo (which is generally a bad thing).

[jmoenig]

Well, I'm not worried about Github being separate to s.b.e. On Github we're often ahead while working on the next release, so that's fine with me. The part that scares me is when we think we're only changing a little thing, like adding a couple of - hundred - resources and then unexpected side-effects occur, such as a dialog box that someone in China created for just a few costumes suddenly taking longer to pop-up with a couple of hundred costumes, or with costumes now showing up in a non-intuitive order. Now, since this is already in production working on this contributed code suddenly becomes a top-priority instead of finalizing what's already in the pipeline. I'm not advocating a rigid "process management", just a little common sense when pushing new things directly into production :-)

[brianharvey]

I can undo it if you want. I don't have to remove the actual files, just revert the COSTUMES file.

[jmoenig]

Your call, you've got more exposure to kids and teachers :-) I'll try to get a handle on using SVGs imported via a url to actually work as SVG...

[cycomachead]

I only support reverting it because the current experience is REALLY bad trying to load all costumes. Trying to load everything isn't fun.

I'm not actually sure thumbnails would help tons but maybe they could a bit. It seems like we will need some hierarchy. I'll think more about this. I don't like any of the immediate solutions.

-- Michael Ball From my iPhone michaelball.co

On Dec 5, 2016, at 11:14 PM, Jens Mönig notifications@github.com wrote:

Your call, you've got more exposure to kids and teachers :-) I'll try to get a handle on using SVGs imported via a url to actually work as SVG...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[brianharvey]

I'm going to try just removing the alphabets to see how much that helps. Stay tuned.

[jmoenig]

I'm copying the current setup to the "dev" url, so I can play with the SVGs over there...

[brianharvey]

OK, done removing letters. The complete version is in COSTUMES-full in snapsource online (I haven't changed the repo). I think it's now quite tolerable, although there are still too many costumes. The menu is too complicated, still, but folders will definitely fix that.

[jmoenig]

Thanks! I just noticed: Did you also update the COSTUMES file in your commit to Github?

[brianharvey]

No, I didn't realize we had a COSTUMES file until after the push. When I make the BACKGROUNDS and SOUNDS files, I'll do another push.

[jmoenig]

Thanks! (I'm not entirely at ease with the current mechanism that specifies resources, and kinda floating around experimenting with things, running into browser caching issues...)

[cycomachead]

Yeah, there might be something better, but we should have something at least compatible with multiple servers.

Also, in terms of categories or hierarchies, I suggest we implement something similar to what scratch has done, but also include a search mechanism.

[nickedens]

As a teacher teaching this I was just thinking it would be nice to have all costumes of a particular costume type be easily grouped as 1 selection and imported into costumes as 1 selection. Practical example we have about 10 different spaceships each with 5 animations. Thats 50 costumes in our costume library and when kids want to add 1 ship they have to add all 5 costumes with the possibility of getting them out of order and then having to fix them. It would be much easier for them to select the ship and then it import all of the costumes related to that ship. So some kind of "import all" hierarchy would be great. At least in my world.

[cycomachead]

I think that use case makes sense. Another way to solve this would be to have method of selecting multiple costumes (like checkboxes) to import all at once. It wouldn't necessarily help if you needed to go back to find more.

I don't know if would make sense to also "Grey out" costumes you've already imported. I could see it being helpful but this starts to make adding a costume rather complex.

-- Michael Ball From my iPhone michaelball.co

On Dec 16, 2016, at 11:51 AM, nickedens notifications@github.com wrote:

As a teacher teaching this I was just thinking it would be nice to have all costumes of a particular costume type be easily grouped as 1 selection and imported into costumes as 1 selection. Practical example we have about 10 different spaceships each with 5 animations. Thats 50 costumes in our costume library and when kids want to add 1 ship they have to add all 5 costumes with the possibility of getting them out of order and then having to fix them. It would be much easier for them to select the ship and then it import all of the costumes related to that ship. So some kind of "import all" hierarchy would be great. At least in my world.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[nickedens]

@cycomachead the checkboxes or greying out wouldn't help me as much because the costume library would still be cluttered with what effectively is multiple frames of animation for 1 costume. I guess I may be looking more for us to be able to specify multiple images in the COSTUMES file as animation frames for 1 specific costume. Then only show the master costume and on import import all of the frames. More along the lines of sprite sheets I guess is what I am thinking except without the actually parsing of the sprite sheet.