Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds block and sprite (in sprite pane) highlighting capability. #861

Closed
wants to merge 9 commits into from

Conversation

Projects
None yet
6 participants
@TheLogFather
Copy link

commented Jul 17, 2015

This extends the current concept used with the broadcast/receiver menu items "show senders/receivers" to provide a more general capability to highlight sprites that contain certain things, as well as even the individual blocks within those sprites.

Three examples are included (see pics in next comment for demos):

  1. extends the "show senders/receivers" menu items (renamed "highlight senders/receivers") to also highlight the relevant blocks in the highlighted sprite ("clear senders/receivers" also renames to the standard "clear highlights", used for all other highlights too);

  2. adds item "highlight variable" to variable getter menus (along with the standard "clear highlights") which highlights the sprites that use the variable (only current sprite, if it's a local var), and all the blocks in those sprites which use it ("set", "change", "hide/show" and getters);

  3. adds menu item "highlight callers" to custom block definition and callers (suggestion for better text?) which highlights the current sprite (since no global defines so far!) and all the uses of the custom block.

It's not hard to think of other cases where it would be useful to highlight which sprites use certain things, and where those blocks are in the scripts...

(Note this PR also fixes some exceptions caused by hacked blocks, such as #815)
Sorry it's only against v437 (hence conflicts) - started this a little while back, only just got around to finishing it off, but hopefully it'll give the concept reasonably well...

Hope that all makes sense! -Any questions, let me know.

Adrian
Adds block and sprite (in sprite pane) highlighting capability.
This extends the current concept used with the broadcasting menu items "show senders/receivers" to provide a more general capability to highlight sprites that contain certain things, as well as even the individual blocks within those sprites.
Three examples are included:
1) extends the "show senders/receivers" menu items (renamed "highlight senders/receivers") to also highlight the relevant blocks in the highlighted sprite ("clear senders/receivers" also becomes the standard "clear highlights", used for all other highlights too);
2) adds item "highlight variable" to variable getter menus (along with the usual "clear highlights") which highlights the sprites that use the variable (only current one if it's a local var), and all the blocks in those sprites which use it ("set", "change", and getters);
3) adds menu item "highlight callers" to custom block definition and callers (suggestion for better text?) which highlights the current sprite (since no global defines so far!) and all the uses of the custom block.
It's not hard to think of other cases where it would be useful to highlight which sprites use certain things, and where those blocks are in the scripts...
@TheLogFather

This comment has been minimized.

Copy link
Author

commented Jul 17, 2015

Here are a couple of screenshots I took that show examples of the highlighting...

  1. Right-click on the variable gives the usual menu (shown near centre), but now with the "highlight variable" item. After clicking that item it highlights, in the sprite pane, the sprites that use the variable (global in this case), as well as all blocks within the sprites - set/change/hide/show & getters. (Highlighting is preserved when switching sprites.)
    highlight-var-demo

  2. Right-click on a caller (or definition) gives the usual menu (shown middle-bottom), but now with the "highlight callers" item (could do with better name?) Highlights callers in sprite, as shown.
    highlight-demo-callers
    (Of course, above caller-highlighting would go alongside "go to define script" menu item in PR #797.)

Could be a useful tool, I think...

@griffpatch

This comment has been minimized.

Copy link

commented Jul 18, 2015

Love it
On 18 Jul 2015 00:20, "Aka DadOfMrLog" notifications@github.com wrote:

Here are a couple of screenshots I took that show examples of the
highlighting...

  1. Right-click on the variable gives the usual menu (shown near centre),
    but now with the "highlight variable" item. After clicking that item it
    highlights, in the sprite pane, the sprites that use the (global) variable,
    as well as all blocks within the sprites. (Highlighting is preserved when
    switching sprites.)
    [image: highlight-var-demo]
    https://cloud.githubusercontent.com/assets/7702458/8758803/abe0ab88-2ce0-11e5-8d8a-d765f9aedd4a.png

  2. Right-click on a caller (or definition) gives the usual menu (shown
    middle-bottom), but now with the "highlight callers" item (could do with
    better name?) Highlights callers in sprite, as shown.
    [image: highlight-demo-callers]
    https://cloud.githubusercontent.com/assets/7702458/8758924/97afbf08-2ce2-11e5-8971-08dd1cdd15d3.png

Could be a useful tool, I think...


Reply to this email directly or view it on GitHub
#861 (comment).

TheLogFather added some commits Jul 21, 2015

TheLogFather TheLogFather
Block-highlighting for all...
Adds generic "highlight this block" and "clear highlights" menu items for all blocks which don't have custom highlight menu items.
The first highlights all occurrences of the current block, with some (questionable!) exceptions, such as list & variable blocks only highlighting other matching blocks which also have the same var/list; maths operator block with dropdown only matching those with the same function; switch costume only matching those with the same costume, etc. (See long comment for complete list...)
@heyseth

This comment has been minimized.

Copy link

commented Jul 21, 2015

Would love to see this implemented!

TheLogFather added some commits Jul 21, 2015

TheLogFather TheLogFather
Add missing distinction for stop block highlighting, and include "att…
…ribute of sprite" block in long comment list.
TheLogFather TheLogFather
Adds "highlight define" menu item for custom block callers.
Supercedes new "define" menu item (PR #797), since this also jumps to the define block.
@TheLogFather

This comment has been minimized.

Copy link
Author

commented Jul 21, 2015

A couple more demo pics to go with the newer commits, showing the generic "highlight this block" menu item for a parameter block and an operator block.
highlight-demo-params

Note in the second case that it's designed to highlight only those operator blocks "[function v] of ( )" that have the same function as the current block - I suspect that'd be the preferred way to do it for that one (rather than highlighting every occurrence with other functions)...?
highlight-demo-operator

I've also made variable blocks, list blocks, switch costume blocks, and numerous other blocks, work in this kind of way (so they only highlight matching blocks which also have the same var/list/costume/etc.)
Some of them make sense (the above operator blocks, stop blocks, etc.), but some may not be the best choice. However, they're there since it's easier to remove them than to add them.

@@ -509,6 +509,11 @@ public class BlockMenus implements DragClient {
}
m.addItem('help', block.showHelp);
m.addLine();
if (highlightItems) {
m.addItem('highlight this block',genericHighlightSameBlocks); // "highlight same blocks", "highlight all like this"...?

This comment has been minimized.

Copy link
@TheLogFather

TheLogFather Jul 21, 2015

Author

Or "highlight these"? Or even just "highlight"...?

@heyseth

This comment has been minimized.

Copy link

commented Jul 22, 2015

Perhaps change the highlight color from 0xaeff00 to 0xE0E000 so as to be the same color as highlighted sprites and the stage. Also the blur is a little too much for me, maybe bump it down from 4 to 3?

@TheLogFather

This comment has been minimized.

Copy link
Author

commented Jul 23, 2015

@Thepuzzlegame: I chose to make it not yellow for various reasons. One being that it gets a bit lost for blocks that are within yellow control blocks. Also, to distinguish it from the glow around running scripts. And it's also more similar in appearance to the sprite pane highlight than the values suggest - especially when it 'mixes' with the blue frame for the selected sprite/stage. (But I still think I'll tweak that one slightly to make it match the block highlighting - rather than tweaking the block highlighting colour.)

As for the blur level, I find it's maybe a tad strong on default size. But it also starts to get a little feeble when zooming in (i.e. making blocks look bigger). I've been considering giving it a degree of dependence on the script pane scaling, so I'll try that and see how it looks - and how it performs (don't want it to cause any significant slowdown when changing it like that...)

@TheLogFather

This comment has been minimized.

Copy link
Author

commented Jul 23, 2015

BTW, @Thepuzzlegame, I meant to ask whether you're just looking at the pics above or if you've actually compiled this and tried running it yourself?
The reason I ask is because the pics have the scripts view zoomed out one level, which makes the blocks smaller compared to the blur - for normal script zoom level you may have a different opinion about the amount of blur...
EDIT: here's a new screenshot with scripts at normal zoom level, so you can compare:
highlight-demo-senders
(I've been toying with the idea of cycling between highlights, hence the extra "previous/next highlight" menu items which are not in anything I've committed here. It's useful, but it's starting to make the menus a bit long - looking at doing it through little "<" and ">" buttons instead, maybe appearing down by the zoom buttons when things are highlighted.)

@heyseth

This comment has been minimized.

Copy link

commented Jul 23, 2015

@TheLogFather Now that you explain it I get your reasoning for not making the block highlight yellow (although I do think it is a good idea to tweak the sprite/stage highlighting to match the block highlighting). I had previously gone ahead and compiled and run this and the blur at normal level was a little too blurry for me. As you've said, consider looking in to having the blur level change with the script pane scaling. I think your idea for the "<" and ">" buttons is great :)

What do you think of having in the right click menu for the scripts panel the option to clear highlights? (I've implemented this locally)

Loading image...

TheLogFather
New widget to cycle through highlighted blocks in current sprite.
When cycling to a new highlighted block, the scripts pane moves to the appropriate position, and the highlighted block 'blinks'.
The widget is similar to -/=/+ zoom widget, with "<" and ">" buttons, as well as a small central button to clear highlights (encircled 'x', like the one to delete costumes). Widget works through a new HighlightWidget class, and some new PNGs iin the assets (clearOn/Off, prevOn/Off, nextOn/Off).
The menu items 'next/previous highlight' also perform the same function (except that it moves to prev/next highlight from the block clicked, rather than the next/prev from whichever was the last highlighted block to blink).
Lots of highlighting code also moves around into (hopefully) more suitable places.
@TheLogFather

This comment has been minimized.

Copy link
Author

commented Jul 25, 2015

Screenshot showing highlight widget (near bottom-right):
highlight-demo-widget
The widget only appears when there are highlighted blocks in the currently viewed sprite/stage. The central circular part performs the 'clear highlight' function (and so also makes it disappear).
Note that this commit also makes sprites remember their last script pane position - meaning that when you select a sprite in the sprite pane, the scripts pane will be scrolled to the same place it was last left (rather than being reset). -That is, unless it has highlighted blocks, in which case it will go to the first such block (really ought to make it also remember if the user had previously jumped to a highlighted block, and then selected a different sprite - then it should go back to that highlighted block instead of the first).

@heyseth

This comment has been minimized.

Copy link

commented Jul 25, 2015

@TheLogFather Looking good!

@TheLogFather

This comment has been minimized.

Copy link
Author

commented Jul 25, 2015

Thanks - I think it's coming together.

There are a couple of fairly major changes I need to make to it, though...

  1. Sort out the order of highlights. At the moment, it goes through the blocks in the stacking order, which means that, although it goes through highlighted blocks within a stack from top to bottom as you'd expect, it goes through different stacks in a way that seems quite haphazard. I'm planning to make it go through the stacks in more of a top-to-bottom then left-to-right kind of order in the scripts pane, which would feel better when cycling through the highlighted blocks, I think.

  2. Merge it all into v438 - more specifically, into the version with the much better refactored block-rendering branch merged. It looks like that will affect a number of things here, so there's some work to do for that...

@heyseth

This comment has been minimized.

Copy link

commented Jul 25, 2015

Well, good luck ;)

TheLogFather
More sensible order when cycling through highlighted blocks.
Tweak algorithm for jumping to a block in scripts pane, so it jumps a minimal amount if block is not far out of view, and doesn't jump at all if the block is (mostly) already visible within view.
@TheLogFather

This comment has been minimized.

Copy link
Author

commented Jul 31, 2015

Well, that's (1) basically sorted (though the coding could do with some tidying up, I think - there are probably better ways to achieve some of the things it does, but I've got no previous experience of using actionscript, so I'm kinda making things up a bit here!)

Next job is to update to v439 and see what needs changing to fit with that, then also the refactored block rendering...

@TheLogFather

This comment has been minimized.

Copy link
Owner

commented on a49c46f Jul 31, 2015

Oh, oops - forgot to sort out tabs... :/
Ah, well - next time...

@towerofnix

This comment has been minimized.

Copy link

commented Aug 12, 2015

This is awesome and I hope to see it implemented in the future. :)

@TheLogFather

This comment has been minimized.

Copy link
Author

commented Apr 15, 2016

I've been putting off working on this further until there was movement on the block render refactor, since that would have a pretty major impact on how this all works.
But if that's now closed then I'm not clear if I should now proceed further with this, probably clean it up here and there, take some feedback/ideas for changes and/or a bit more to add to it, etc...?

@jwzimmer

This comment has been minimized.

Copy link
Member

commented Jun 1, 2016

@TheLogFather, Thank you so much for working on this feature! The documentation and planning are really great - the screenshots showing how the feature works, the extremely thoughtful comments and conversation - just awesome work! : )
However, we're not going to add it to scratch-flash.
As we focus on Scratch 3.0, we're focusing on developing new features there, and we will consider adding this feature to our next major release.
We really appreciate that you have taken the time to contribute to Scratch! The scratch-blocks and scratch-vm repositories are great places for open source contributions right now... Hope to see you there. : )
Thanks again!

@jwzimmer jwzimmer closed this Jun 1, 2016

@towerofnix

This comment has been minimized.

Copy link

commented Jun 1, 2016

Btw, it's already partially implemented in Scratch 3.0:

Demo

See the "Glows" controls in the demo.

@TheLogFather

This comment has been minimized.

Copy link
Author

commented Jun 2, 2016

Yeah, had a feeling that a number of PRs would be heading in that direction after the S3 announcement.

Ah well...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.