{"id":1102,"date":"2022-12-28T20:35:13","date_gmt":"2022-12-28T19:35:13","guid":{"rendered":"http:\/\/heppg.de\/ikg\/wordpress\/?p=1102"},"modified":"2022-12-28T20:51:41","modified_gmt":"2022-12-28T19:51:41","slug":"snap-integration-with-scratchclient","status":"publish","type":"post","link":"https:\/\/heppg.de\/ikg\/wordpress\/?p=1102","title":{"rendered":"Snap! integration with scratchClient"},"content":{"rendered":"\n

Some work was performed to integrate Snap! with scratchClient. Here a preview of current results.<\/p>\n\n\n\n

Snap! is a viable alternative to scratch. Scratch 1.4 on raspberry pi is quite fast, but latest implementation is buggy. Full screen display for example is no longer working. Scratch 2 was based on flash and is not recommended; scratch 3 has again a different extension method and investigation is on todo-list. <\/p>\n\n\n\n

The complexity of Snap! blocks is a hurdle for a school environment. Can be handled partially by making blocks invisible. For the menu entries some work needs to be done to hide \/preset some of them to avoid confusion for the kids in school.<\/p>\n\n\n\n

Snap! sources can be downloaded from https:\/\/snap.berkeley.edu\/ . It runs from the file system; serving from a local web server as python tornado is easy.<\/p>\n\n\n\n

The system context is as with the legacy scratch1.4, 2 integration: have Snap! started, have scratchClient running and the config definitions from the xml config files are exported into Snap!.<\/p>\n\n\n\n

Current implementation is proof of concept which concentrates on communication using websocket and configuration setup. Plan is to have a dedicated snap-scratchClient implementation and not to integrate this with legacy scratchClient. This reduces test effort and allows for easier rework of event distribution and web page handling.<\/p>\n\n\n\n

Snap sources will be provided from a local tornado server; the data communication also goes to this tornado instance. <\/p>\n\n\n\n

When Snap! is started, then scratchClient library needs to be loaded. <\/p>\n\n\n\n

\"\"<\/a>
Menu entries.<\/figcaption><\/figure>\n\n\n\n

The library list is adjusted by the server. For demonstration purpose only scratchClient- and catch-errors is provided. The server has a whitelist\/ blacklist for libraries provided. This is part of the ‘reduce complexity’ effort.<\/p>\n\n\n\n

\"\"<\/a>
Library list provided by server.<\/figcaption><\/figure>\n\n\n\n

The initial blocks are opened in a category ‘scratchClient’.<\/p>\n\n\n\n

\"\"<\/a>
scratchClient library blocks.<\/figcaption><\/figure>\n\n\n\n

The command ‘scratchClient start’ initiates the websocket communication to the server and downloads the block definition for current adapter. Based on configuration in scratchClient additional blocks are created.
It should be possible to start the communication with the library import; this needs further investigation.<\/p>\n\n\n\n

The ‘connected’ reporter is boolean connection state; ‘message’ is providing last raw websocket messages for debug and will be removed.<\/p>\n\n\n\n

\"\"<\/a>
Palette created from scratchClient configuration.<\/figcaption><\/figure>\n\n\n\n

Unfortunately there are no ‘hat’-blocks available which could react to events sent from scratchClient. Only way to handle this was to preload the broadcast-event names into the event hat message list. <\/p>\n\n\n\n

Technically this is achieved by creating a hidden custom block which uses do_broadcast blocks with the event names.<\/p>\n\n\n\n

<\/p>\n\n\n\n

\"\"<\/a>
scratchClient event preloaded into the broadcast hat.<\/figcaption><\/figure>\n\n\n\n

Help text for the blocks is provided by the server, current implementation is generated from scratchClient xml configuration.<\/p>\n\n\n\n

\"\"<\/a>
Help Text created from adapter XML.<\/figcaption><\/figure>\n\n\n\n

The screenshot shows a mix of information from xml configuration and some text from the server.<\/p>\n\n\n\n

<adapter class='adapter.test.TestAdapter' name='TestAdapter'>\n\t\t\n    <description>A test adapter. Provides Output update every some seconds.<\/description>\n    <description lang=\"de\">Beispiel f\u00fcr eine Konfiguration. Der Adapter l\u00e4uft ohne externe Referenzen und versorgt Werte sporadisch.<\/description>\n\t\n    <input name='low'>\n\t<broadcast name='led1_OFF'\/>\n\t<broadcast name='led1_AUS'\/>\n\t<broadcast name='led1_off'\/>\n    <\/input>\n...<\/code><\/pre>\n\n\n\n
The configuration snippet shows adapter description for different languages.<\/p>\n\n\n\n
New Features: I18N<\/h2>\n\n\n\n
Translation support is implemented from start. <\/p>\n\n\n\n
The adapter xml configurations can be extended with translations. Snap! block definition can be multi language and log messages of the server can be translated.<\/p>\n\n\n\n
Work to be done<\/h2>\n\n\n\n
All the backend implementation needs to be done. scratchClient configuration loading, instantiating of the adapter. Event distribution between the scratchClient modules. Web page redesign of course. And documentation update.<\/p>\n\n\n\n
A schedule is not yet available.<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Some work was performed to integrate Snap! with scratchClient. Here a preview of current results. Snap! is a viable alternative to scratch. Scratch 1.4 on raspberry pi is quite fast, but latest implementation is buggy. Full screen display for example is no longer working. Scratch 2 was based on flash and is not recommended; scratch […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,47],"tags":[],"class_list":["post-1102","post","type-post","status-publish","format-standard","hentry","category-scratchclient","category-snap"],"_links":{"self":[{"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/1102","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1102"}],"version-history":[{"count":3,"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/1102\/revisions"}],"predecessor-version":[{"id":1114,"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/1102\/revisions\/1114"}],"wp:attachment":[{"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1102"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1102"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/heppg.de\/ikg\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1102"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}