Is there any primitive function to show up a bubble for a custom block?

[s_federici]

I would like to show up a bubble with an error message when one of my custom blocks is used in the wrong way.

Is there any primitive function (that is a function in the

block) that does that? Or, can someone suggest a Javascript to add a block with this function to Snap?

Thanks in advance

[bh]

I'm not sure what you're asking for when you say "a bubble."

If you're asking to make your message look just like the error messages from primitives, then yes, it's err_error(msg).

If you want a sprite-like speech balloon, just use SAY, except that that won't survive your program stopping, so I guess you'd have to clear the stage, SAY the message, capture it with the PEN TRAILS block, and then display /that/ before you stop.

[s_federici]

@bh

If you're asking to make your message look just like the error messages from primitives, then yes, it's err_error(msg).

Yes! I was sure you already had it.

Thanks a lot Brian!

NOTE: are you planning to document this block other than the comments in extensions.js?

[ego-lay_atman-bay]

I don't think they are, since it's only meant for developers. Normal users should just use the library blocks, instead of the primitive (extension) blocks.

[s_federici]

I thought Brian's philosophy was "everything that is in there must be usable by all users"

Not taking into account that, if you are a developer of extensions, you could be interested in a comprehensive documentation.

[ego-lay_atman-bay]

Of course it can be used by all users, it's just better if casual users use library blocks instead of extension blocks, because it's easier to understand what is going on.

[s_federici]

@ego-lay_atman-bay

it's just better if casual users use library blocks instead of extension blocks, because it's easier to understand what is going on.

Of course. They are hidden enough (you have to enable an option). But if you want to try them (the two blocks are documented in the manual) you should be able to understand the meaning of its parameters.

[bh]

The thing is, stuff we put in the manual is (with rare and extravagantly documented exceptions) stuff we are promising will be true for a long time if not forever. We are explicitly not promising to users that any particular PRIMITIVE option will be true tomorrow, let alone forever! We know who our extension writers are, and can negotiate with them individually if something changes.

[s_federici]

@bh

We know who our extension writers are, and can negotiate with them individually if something changes.

I see. Can I ask then 1) to add functions to the primitive block when I need them and 2) to be in the communication queue when something is changed about it?

[cymplecy]

Going back the beginning - I think we got distracted when you asked for a primitive block

But the library error block gives the same end result but in a nicer, friendlier package

[s_federici]

Thank you

[steve_harvey03]

I thought Brian's philosophy was that (this is paraphrased) "everything toggleable in the GUI should be toggleable in the program itself"

[s_federici]

@steve_harvey03

I thought Brian's philosophy was that (this is paraphrased) "everything toggleable in the GUI should be toggleable in the program itself"

[bh]

@steve_harvey03

"everything toggleable in the GUI should be toggleable in the program itself"

You left out the "and vice versa." ;~)

This is a longstanding disagreement between Jens and me. He doesn't believe in Eisenberg's Law (or even in me calling it that). So we have an uneasy truce wherein you have to enable JS to use that library, and any changes you make, even to values that are persistent per user in the GUI, last only while the current project is loaded. And there is no guarantee on Jens's part not to change how a value is stored.

[bh]

@s_federici

I see. Can I ask then 1) to add functions to the primitive block when I need them and 2) to be in the communication queue when something is changed about it?

Umm you can certainly ask; in fact, you have just done so!

There isn't a queue in the sense you mean it; we correspond with individual library authors individually, and the conversation isn't all one-way.

This is really a question for Jens, but I'll throw in my 5¢ anyway: I'd be reluctant to give a blanket prior approval to anything you might suggest, but would entertain specific proposals as they come up. The reason not to give blanket prior approval is that inevitably the number of pseudo-library primitives would grow without limit, not that any specific one would be horrible. We really want you to be able to do anything in Snap! itself, without recourse to JS, and if there's something you can't do, we should think about whether there's an alternate way to achieve the same ultimate purpose.

[steve_harvey03]

@bh

This is a longstanding disagreement between Jens and me. He doesn't believe in Eisenberg's Law (or even in me calling it that). So we have an uneasy truce wherein you have to enable JS to use that library, and any changes you make, even to values that are persistent per user in the GUI, last only while the current project is loaded. And there is no guarantee on Jens's part not to change how a value is stored.

Is that why there's no "unpause/resume all" block? I found it rather odd that you had to unpause a project from the button itself instead of having a dedicated block to do that. I was going to make a separate post about that, but I found it appropriate to mention here.

[bh]

@steve_harvey03

Is that why there's no "unpause/resume all" block?

I don't understand how it would work. By hypothesis, the project is paused! (Yes, you can run scripts while paused, but I think only in response to a user action.)

[s_federici]

@bh

I don't understand how it would work. By hypothesis, the project is paused!

Same question here

[snapenilk]

it would make sense if individual threads can be paused

[bh]

@snapenilk

if individual threads can be paused

Hmm, first class threads... I feel a headache coming on...

Edit: Although continuations are already kind of first class threads! A pause block that takes a continuation as input, that could work I guess.