Scratch3.0 二次开发——增加积木删除区域的标识交互

OumCc
1,679 阅读5分钟

携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第5天，点击查看活动详情

概述

Scratch3.0 二次开发系列，系列说明、Demo源码等请查看：《Scratch3.0 二次开发——开篇》

这次核心介绍如何修改 scratch-blocks 库 使其增加积木删除区域的标识交互

最终效果如图：

可删除区域的标识

需求分析

官方拖拽删除积木的标识不是很明显，如下图只有一个小手，对于年龄比较小的孩子交互提示不太友好（做大众化时还是要考虑全年龄段的用户 (￣▽￣)" ）

再细分一下需求如下：

  1. 用户拖动积木时，出现上图垃圾桶标识，提醒用户可以通过将积木拖动到该位置实现删除积木的功能
  2. 当用户拖动积木到可删除区域（垃圾桶标识的位置区域）时，垃圾桶变成一个“打开”的状态，更显式提示用户在该位置可以删除积木

实现细节

scratch-blocks 项目的前置准备请参考这篇：Scratch3.0 二次开发——支持隐藏积木选择区域

思路

从技术实现上拆解一下上述需求：

  1. 用户拖动积木时，出现上图垃圾桶标识，提醒用户可以通过将积木拖动到该位置实现删除积木的功能
    • 「 用户拖动积木时 」，即需要监听到当前是否处于拖拽积木的状态
    • 「 出现上图垃圾桶标识 」，即需要找一个位置显示垃圾桶标识，也就是说垃圾桶的显示、隐藏状态需要受控
  2. 当用户拖动积木到可删除区域（垃圾桶标识的位置区域）时，垃圾桶变成一个“打开”的状态，更显式提示用户在该位置可以删除积木
    • 「 垃圾桶变成一个“打开”的状态 」，即需要监听拖拽的积木进入了可以删除的区域

源代码

文中没有贴完所有源码，有需要的朋友麻烦上 scratch-blocks github 库 自取，有很多关键性的注释也附在源码上面，记得看看中文类型的注释（英文的注释是官方的，中文的注释都是我自己加上去的）

下文只贴一些变量、函数名，作为源代码中的“目录”，起到总览的作用，后续看源码的时候不至于迷路 （づ￣3￣）づ╭❤～

scratch-blocks 的 core/toolbox.js

在 scratch-blocks 的 core/toolbox.js 文件中：

// 相关变量：
this.trash_

// 相关函数；
init
createMxcTrash
showMxcTrash
hideMxcTrash
openMxcTrash
closeMxcTrash

init 函数中只有一行： this.createMxcTrash(); // 创建可删除区域，显示垃圾桶的标志

另外几个函数分别用于创建、显示/隐藏、打开/关闭（积木处于可删除区域时打开垃圾桶、否则关闭）

scratch-blocks 的 core/css.js

在 scratch-blocks 的 core/css.js 文件中，新增了.mxcTrash、.mxcTrash.mxcTrashOpen 两个样式 class，用于控制垃圾桶的位置、打开关闭时显示的图片

scratch-blocks 的 core/block_dragger.js

在 scratch-blocks 的 core/block_dragger.js 文件中：

// 相关函数；
startBlockDrag
endBlockDrag
updateCursorDuringBlockDrag_

startBlockDrag 拖动积木时，显示垃圾桶标识

endBlockDrag 拖拽完积木后，隐藏垃圾桶标识

updateCursorDuringBlockDrag_ 拖动到可删除区域时，打开垃圾桶；不在可删除区域时，关闭垃圾桶

scratch-blocks 的 media 目录

在 scratch-blocks 的 media 目录 目录下增加两份资源文件：

至此，就完成了这一次的需求实现 ✿✿ヽ(°▽°)ノ✿

当“一无所知”时如何定位到上述需要修改的位置？

这个专栏写了几期下来后，突然发现都是从宏观角度带着各位朋友具体到源码的修改位置，出发点是为了让大家可以快速定位到在哪里修改就可以实现需求功能。打个比方，有点像直接带各位到了藏宝地点，确实节省了很多时间，但也少了拿着地图一步步解密的过程中的乐趣~

一开始在下也感觉自己“很行”，觉得一两天就可以搞掂 scratch 的二开，然鹅看了几天下来后发现，连源码里面变量、函数命名的含义都摸不清头脑（英文单词都懂，但具体是做什么的？在哪里使用？怎么用？没有一点头绪）

被现实打倒后，只能回到现实重新站起来，收起觉得自己“很行”的想法（ 男人不能说自己不行(￣.￣) ），用笨办法一步步重新出发：

  1. 梳理 《Scratch 底层架构源码分析》 中各个部分、各个库的逻辑和里面的实现细节
    • 入口文件、加载逻辑、核心功能等
    • 第一遍看下来几乎是啥都没看懂，没关系，先留个印象，梳理大概的框架，然后每次遇到问题不知道从何入手时就再过一遍、再过一遍、再过一遍（有时一个小功能对照着源码和书籍刷了 4、5 遍才有那种灵光一闪的感觉）
    • 不用担心，等刷书、刷源码次数上来后，做梦都可以想起那些变量、函数名，到时就可以逐步缩小搜索范围，相对精准定位到需要修改的位置
  2. 快速试错
    • 这点很关键、这点很关键、这点很关键
    • 刷源码和刷书很多时候只是留个概念、留个印象，至于能不能做、改了会发生什么事情，还是要把代码跑起来才能直观检查
    • 依赖库中，scratch-blocks 是可以直接在项目 tests 目录下的页面里面看效果，有时可能要执行 npm run prepublish 命令后再刷新页面，但相对来说也比较方便
    • 其它依赖库比较多是要先 link 起来，然后跑 npm run watch（后续篇章中再详细介绍），然后再跑 gui 项目的 start 才能看到效果，不过也还好，机器好一点的话基本可以马上更新
    • 尽量不能用 npm run buid 完，然后再去 gui 中 start，这样步骤太多，而且每改一次就要 build 一遍，几次下来可能就已经忘了前面改过什么东东（有时可能要改很多地方才能定位到具体需要修改的内容）

一步一个脚印吧，有时“慢”就是“快” d(･｀ω´･d*)

avatar
文章
阅读
粉丝