I don't mean for it as a "like" button, just as a "oh, okay!" button. Though I see how it can be easily misconstrued and abused as such
👍
Ha ha.
does this include functionality of internal event listeners in the editor?
What would that mean? You have to already be running the main block in order for its environment to be available. Maybe if internal event listeners listen only when the main block is running, although I don't offhand see a use case. I'm interested in internal procedure definitions, not arbitrary scripts.
I feel like internal event listeners make more sense in custom hat blocks. For example, if you have a custom hat block that will react to when the mouse enters the sprite, but while the script under this hat block is running, it will set an upvar to false when the mouse leaves the sprite. That way you could create something like this.
Umm I guess. Anyway, this is the sort of thing we have to work out before making internal definitions a feature.
It's probably reactionary of me that I'm more interested in procedures than in events. :~/
There is a thread on the Github
And a minimal proof of concept project (JS). It announces the block/script under cursor via DOM/ARIA (screen reader must be enabled in the browser).
It's far from complete but can be used to tinker with - what to say and when.
Project updated to plain TTS and more contextual output - inputs, strings.
I don't have a screen reader installed but tried the proof of concept project. That is a nice start.
Yeah, that would require keeping internal events actively listening even when the main block isn't active. I'd rather have
... although I'm not sure this is a good fit for block variables because each instance of LAST KEY PRESSED will have a separate block variable KEY.
Could you instead make the event external with a connected script that changes the definition of the block to the key pressed, or does @sathvikrias want an internal-only way to do this?
when [any key V] pressed ((key)) @delInput :: control hat set [definition V] of block ((last key pressed :: sensing)@addInput) to (key)
Can you set the definition of a block to just a text string?
This is all starting to look too complicated for normal users. Maybe we should just have a LAST KEY PRESSED primitive instead. :~(
If you set the definition of a block to a non-script value, it creates sets the definition to report (. . .).
What happened to wanting users to create blocks themselves? lol. Remember the list processing?
My question is, why is no one using variables? Those were designed to keep a value until the variable is changed.
My guess is that they look too generic, and they can easily be manipulated.
Well, you can rename the variable to something that people wouldn't use, like __last key pressed (it's the double underscore prefix that people probably won't use), then stick it in you custom (last key pressed :: sensing) , then hide the variable through the "hide blocks" dialog (yes, you can hide variables).
You mean, global variables? That's kind of a step backward from block-structured (in the non-block-language sense) programming. I think we need something like block variables but there's only one variable shared among all instances of the block. I've never really liked the name "block variable" because to me that sounds like the new kind I'm suggesting. Maybe they should be called "class variable" (the new kind) and "instance variable" (the existing kind)?
Oh, and using TELL as in
to communicate with the block. You could say that only for class variables, not instance variables, unless we invent a way to point to a specific use of a block in a script.
Honestly I've always felt like that too, in fact, that's what I thought it was when I first learned how to use block variables.
I feel like "class variable" maybe gives the wrong idea what a block is supposed to represent, a function, not an object in oop (or at least on the surface, since adding internal definitions is basically is turning blocks into classes). I do feel like changing the meaning of "block variable" to what you're calling a "class variable", but also add "instance variables", since that I feel like that's pretty clear as to what it is.
"Instance" conjures up an OOP mindset just as much as "class" does! I don't think that mindset is so inappropriate when you're using blocks in this way, with persistent local storage, which is really what OOP is about.