I have seen a suggestion about x and y positions about variables:

move variable [variable v] to x:() y:() :: variables

change position of variable [variable v] by x:() y:() :: variables

(x position of variable [ v] :: variables )

(y position of variable [ v] :: variables )

But now I got an idea that reminds me of this I want a block (or blocks) that can change a list (not the contents of it, but the appearance and position), rather something like this:

move list [ v] to x:() y:() :: list

change position of list [ v] by x:() y:() :: list

move list () secs to x:() y:() :: list

change position of list for () secs by x:() y:() :: list

set list [ v]'s size to ()% :: list

set list [ v]'s size to length:() height:() :: list // Since the list can be grown or shorten.

change list [ v]'s size by ()% :: list

change list [ v]'s size by length:() height:() :: list

(x position of list [ v] :: list )

(y position of list [ v] :: list )

(list [ v]'s size :: list )

(list [ v]'s length :: list )

(list [ v]'s height :: list )

But you might be thinking:

But you can change a list's x and y positions, lengths, widths, full size, and etc.! We don't need these blocks!

Well, here are a few things I got to tell you.

First of all, what if you are creating a filter cloud chat or something. You see the chatting going on, but no list of active users. You go to see who is active and who isn't. What are you going to do, like every few minutes, go to “See Inside”, have to change size of the chatting list and move it, and then show the active users list so that you can see who is active and who is not, and then do vice versa all over again?

You can prevent that with these blocks.

You could just simply create a button that shows a list of users active on a filtered chat, and function it so that when it's clicked, the chatting list shortens and the active users list appears, and if you want to revert it, you can click on it again. Something like this:

when this sprite clicked
if <(active users list showing?) = [false]> then
change list [chatroom v]'s size by length:(-10) height:(0) :: list
show list [active users v]
set [active users list showing? v] to [true]
else
change list [chatroom v]'s size by length:(10) height:(0) :: list
hide list [active users v]
set [active users list showing? v] to [false]
end

// The reason I didn't set an x/y position for the active users list is that I don't need it to change positions. It will stay in one position the entire time, while hiding and showing.

These blocks could be used for many examples, such as dragging your inventory:

when this sprite clicked // Before asking, I would put a sprite behind the list so that it would pull along with it. 
repeat until <not <<mouse down?> and <touching [mouse pointer v]?>>> // You need to click the sprite, not the list, in order for this to work.
move list  [inventory v] to x:(x position) y:(y position) :: list
end

When you zoom out of an article like a book:

when I receive [zoom out v]
change list [book v]'s size by ((0) -(change of zoom))% :: list
...

// Including moving leaderboards if you are a mod/admin.

when I receive [move all leaderboards v]
if <<(x position of list [leaderboard v] :: list ) = (0)> and <(y position of list [leaderboard v] :: list ) = (0)>> then
say [You are all good!]
else
say [You need to move your leaderboard to a certain spot!]

I believe these would be useful for Scratch lists. I am also hoping to see cloud lists in the future too.

Supporters

@Charles12310 (me, of course!)
@FancyFoxy

I support these, but I think the (change list _ by _) blocks, I wouldn't add, since this could make the Data section hold a lot, especially if you're like me and feature millions of variables and lists in your projects.
There's workarounds for them too.

FancyFoxy wrote:

I support these, but I think the blocks, I wouldn't add, since this could make the Data section hold a lot, especially if you're like me and feature millions of variables and lists in your projects.
There's workarounds for them too.

Kind of. I mean, sure I could end up doing this:

set x to ((x position) + (amount))

// Instead of:

change x by (amount)

But I thought, “why not do both?”

(BTW don't use brackets when mentioning the block “change list by whatever” The editor will think you are using HTML (the bracket way), and text inside will not show. I know what you are trying to say since I quoted this post and the code appears.)

Charles12310 wrote:

FancyFoxy wrote:

I support these, but I think the (change list _ by _) blocks, I wouldn't add, since this could make the Data section hold a lot, especially if you're like me and feature millions of variables and lists in your projects.
There's workarounds for them too.

Kind of. I mean, sure I could end up doing this:

set x to ((x position) + (amount))

// Instead of:

change x by (amount)

But I thought, “why not do both?”

I just think that we could try to compress these blocks so the section wouldn't be filled with blocks.

FancyFoxy wrote:

Charles12310 wrote:

FancyFoxy wrote:

I support these, but I think the (change list _ by _) blocks, I wouldn't add, since this could make the Data section hold a lot, especially if you're like me and feature millions of variables and lists in your projects.
There's workarounds for them too.

Kind of. I mean, sure I could end up doing this:

set x to ((x position) + (amount))

// Instead of:

change x by (amount)

But I thought, “why not do both?”

I just think that we could try to compress these blocks so the section wouldn't be filled with blocks.

And how would someone do that?

Charles12310 wrote:

FancyFoxy wrote:

Charles12310 wrote:

FancyFoxy wrote:

I support these, but I think the (change list _ by _) blocks, I wouldn't add, since this could make the Data section hold a lot, especially if you're like me and feature millions of variables and lists in your projects.
There's workarounds for them too.

Kind of. I mean, sure I could end up doing this:

set x to ((x position) + (amount))

// Instead of:

change x by (amount)

But I thought, “why not do both?”

I just think that we could try to compress these blocks so the section wouldn't be filled with blocks.

And how would someone do that?

By removing the blocks that aren't entirely necessary.

FancyFoxy wrote:

Charles12310 wrote:

FancyFoxy wrote:

Charles12310 wrote:

FancyFoxy wrote:

I support these, but I think the (change list _ by _) blocks, I wouldn't add, since this could make the Data section hold a lot, especially if you're like me and feature millions of variables and lists in your projects.
There's workarounds for them too.

Kind of. I mean, sure I could end up doing this:

set x to ((x position) + (amount))

// Instead of:

change x by (amount)

But I thought, “why not do both?”

I just think that we could try to compress these blocks so the section wouldn't be filled with blocks.

And how would someone do that?

By removing the blocks that aren't entirely necessary.

I'm not gonna comment on that, cuz idk what to respond.

bump

change [bump v] by (1)

Dangit, 60 second rule. I did nothing to you. All I am doing right now is trying to bump a thread so that more users could notice it. Don't try to ruin my job.

bump (for the second time, ugh. Well, it isn't something I shouldn't be doing, since this is my topic, and I've seen other users do it with their topics, so don't judge me about it, he he…)

define bump
change [bump v] by (1)

bump

when green flag clicked
forever
if <[bump v] received? :: events > then
change [bump v] by (1)
end
end

Charles12310 wrote:

bump

change [bump v] by (1)

Dangit, 60 second rule. I did nothing to you. All I am doing right now is trying to bump a thread so that more users could notice it. Don't try to ruin my job.

Charles12310 wrote:

bump (for the second time, ugh. Well, it isn't something I shouldn't be doing, since this is my topic, and I've seen other users do it with their topics, so don't judge me about it, he he…)

define bump
change [bump v] by (1)

Charles12310 wrote:

bump

when green flag clicked
forever
if <[bump v] received? :: events > then
change [bump v] by (1)
end
end

Make sure you only bump every 24 hours, and only if the post is not on the front page.
sixty second rule, you're funny

FancyFoxy wrote:

Charles12310 wrote:

bump

change [bump v] by (1)

Dangit, 60 second rule. I did nothing to you. All I am doing right now is trying to bump a thread so that more users could notice it. Don't try to ruin my job.

Charles12310 wrote:

bump (for the second time, ugh. Well, it isn't something I shouldn't be doing, since this is my topic, and I've seen other users do it with their topics, so don't judge me about it, he he…)

define bump
change [bump v] by (1)

Charles12310 wrote:

bump

when green flag clicked
forever
if <[bump v] received? :: events > then
change [bump v] by (1)
end
end

Make sure you only bump every 24 hours, and only if the post is not on the front page.
sixty second rule, you're funny

ok

bump.

when green flag clicked
forever
if <[bump v] received? :: events > then
change [bump v] by (1)
end
end

when green flag clicked
repeat  ([24 hours v] a [day v] :: sensing )
do {
broadcast [bump v]
} :: control
or {
receive [bump v] :: events
} :: control
end

bump

60 second rule, do not appear when I click the “Submit” button, or things will go very, very, bad…

Not support because it adds too many new blocks. But it would be convenient. I think the solution would be to make it easier to use a sprite as a watcher.

walkcycle wrote:

Not support because it adds too many new blocks. But it would be convenient. I think the solution would be to make it easier to use a sprite as a watcher.

1. The data section of the blocks is probably one of the shortest block sections and doesn't have many blocks, unlike the others.

2. What do you mean, “use a sprite as a watcher”?

Charles12310 wrote:

walkcycle wrote:

Not support because it adds too many new blocks. But it would be convenient. I think the solution would be to make it easier to use a sprite as a watcher.

1. The data section of the blocks is probably one of the shortest block sections and doesn't have many blocks, unlike the others.

2. What do you mean, “use a sprite as a watcher”?

1) The data section also includes the variables and lists, which can get quite long in a complex project. Maybe we can cut the new blocks down to (according to the OP):

move list [list v] to x: (0) y: (0)::list
set list [list v] size to width: (100) height: (100)::list

All other blocks are workaroundable via these blocks.
2) To use a text engine (using pen, stamping, or clones) to create your own custom list watcher

Sheep_maker wrote:

Charles12310 wrote:

walkcycle wrote:

Not support because it adds too many new blocks. But it would be convenient. I think the solution would be to make it easier to use a sprite as a watcher.

1. The data section of the blocks is probably one of the shortest block sections and doesn't have many blocks, unlike the others.

2. What do you mean, “use a sprite as a watcher”?

1) The data section also includes the variables and lists, which can get quite long in a complex project. Maybe we can cut the new blocks down to (according to the OP):

move list [list v] to x: (0) y: (0)::list
set list [list v] size to width: (100) height: (100)::list

All other blocks are workaroundable via these blocks.
2) To use a text engine (using pen, stamping, or clones) to create your own custom list watcher

1. Okay, I was just mentioning it without any variables/lists being created.

2. I still don't understand.