I said that before I actually made it, and I think I could make it a lot better now.
i know just that can be in the when hat block
then why did you tell me to use that project, I knew about that project after I created mine.
did you look at my next post?
here's another for
when || clicked :: control hat
[scratchblocks] when 🛑 clicked :: control hat [/scratchblocks]
: this post I made
also, I think the atan2 workaround should be removed, since we already have this block. to get it, right-click and then select relabel on the () + (), () - (), () x (), or () / () primitives. after all, this is a topic about Workarounds for blocks Snap doesn’t have, and not Workarounds for blocks Snap does have
that workaround was probably posted before they added that
Hi, I still think like there should be a way to have custom "Head" Block as well and also "Close" block.
there's the generic when <> block
when <> :: control hat
Channeling Jens: The fact that something is arguably a natural extension of an existing feature isn't enough of an argument for us to implement it; we have to be shown that you have an actual use case -- something you can't do with the existing mechanisms. Cap blocks, for example, are just a piece of syntactic sugar; they don't let you do anything you can't do with a stack block.
(He says that to me all the time, because I too like to see formal completeness. But, time is short, and our task list is long.)
I need to agree on this, yeah time is short, but what are the things you need to implement?
Can you show your task list?
If they did that - there'd just be more time wasted on discussing it instead of doing stuff
Hmm, but discussing about the feature that's going to be added is better, and I feel like it's better to discuss the pros and cons of the feature they're going to implement and asking community whether they like to see the newer feature getting implemented. And maybe I could help them by code too.
This isn't a democracy And its not even a benevolent dictatorship
Jens does what he likes and SOMETIMES listens to Brian
As Brian says - stuff like this would be great to make Snap! formally complete but there are a lot of other, more day to day features that would make Snap! better/more accessible/useful
We can have discussions on a particular point - this is great of course, but having a discussion on what the priority/task list is wouldn't be productive because the community is so diverse.
The team know what everyone wants - they also know what they want and it'll get done as and when time permits.
What I've I done/do when I'd like to see a feature made available is to try making a prototype solution - either by custom JS blocks or hacking into the source code on my own fork
No, that's only partly true. He tries hard to solve users' problems, when there's a real problem, such as projects disappearing. Sometimes the underlying problem is political rather than technical, but gives rise to technical requirements; right now what's at the top of our list is that school districts have to have us sign contracts in which we guarantee the confidentiality of student data, and right now we can't do that partly for bureaucratic reasons (we can't sign contracts on behalf of the University of California, so we have to negotiate with their lawyers) and partly for technical reasons (we can't allow student's class projects to be published, and right now we have no way to distinguish those).
That's not to start a discussion; I promise, we know what we need to do. It's just to (partly) answer the question about what's on the list.
(And there isn't really a "the list"; there's Jens's list and my list, and they're different. And no, those aren't up for discussion, as @cymplecy says.)
P.S. But that doesn't mean not to make feature requests. It's especially useful if you show us the project that you can't finish because of a missing feature.
(I wrote too soon)
I'm still working on the project as we speak. Reload the project.
Oh, it gets broken with the stage scale. I'll work on it some other time.