Regarding Screen1, I went looking for the tooltip for Open Screen at
http://ai2.appinventor.mit.edu/reference/blocks/control.html#openscreen
and found a warning in the Library, but not in the smaller block tooltip.
Extending the tooltip with an extra sentence or two might suffice.
This pops up in the help group maybe once every few weeks.
It's probably not worth the complication.
Thank you for your reply! That's funny because I actually checked the tooltip of the block before I replied to you, but I didn't check the docs hehe.
It just feels weird to me that users are even allowed to create memory errors or push screens to the stack in the wrong way. Couldn't AppInventor just close the current screen when it opens a new one, and allow developers to simulate a screen stack using the .BackPressed event? I guess there are probably complications that prevent that 
It shouldn't be too complicated to remove Screen1 from the dropdown. Since it's static anyway I can just filter it out =) I'll update that documentation & tooltip you pointed to while I'm at it!
Thank you again for the info!
That would also involve having a mechanism to save state. When you open a new screen, the current activity still stays in the stack with all of its component states, global variables, etc. It's only unloaded from memory if the system needs it. What you're proposing is more like how the Companion app works, because when you switch screens it clears out everything and draws the new screen.
Probably what we need more is to just mark opening Screen1 as an error. The problem being that you would just be able to stuff "Screen1" into a variable to hide it from the static error checker in the blocks editor.
We may also want to introduce a block with different semantics "switch to another screen" which opens a new screen if it isn't already open or switches to an existing copy if one exists.
Could it be that there are cases where a user needs to have two instances of the same screen open? I can't think of a specific type of app requiring that.
But having that in mind, may be you can implement this change or a similar solution: When the block "Open Screen" is used, App Inventor would check if there's an instance of that screen already open, then use that and go to that screen in memory instead of opening a new one. Otherwise just act normally and open the screen.
And create a new block called "Open Another Instance of Screen" for the case where it might be necessary to open the same screen more than once.
You did a great job @BeksOmega. 
I tested it and it is a great improvement especially for new users. But even experienced users could benefit. No need to type in filenames, permissions etc.
I can imagine that for a new user this limited flyout could be a problem. They are getting to know the blocks so they should see the whole block. Maybe a new setting
to enable or disable the limited flyout.
Thank you for taking the time to give it a look! I'm glad you think it will be an improvement =) I think this was a summer well spent!
Good idea! I'll add a comment to the PR asking what the dev team thinks of it =)
Thank you again for giving it a look and providing feedback. I really appreciate it!
Hello! This is probably going to be my last post on this topic because GSoC officially ends for students on Aug. 31st 
I'll still be sticking around until all of my changes get merged into production though. Currently we're over half way done with the code review on my project, so I'm confident the changes will get in!
If anyone is interested in reading a summary of my summer I recently published my GSoC Final Submission. This is meant to help my mentors give me my final review, but I think it also provides some nice details about the technical stuff I worked on =)
Thank you all for your amazing and insightful feedback on my project! And thank you for an amazing summer
Thank you very much for your contribution😃
Another opinion on work space is you can add a text box on workspace section the user can type a word in it and it will show related blocks automatically in front of work space so no need to search where is the block though ctrl +f can search it can only highlight we need to go to it instead the inbuilt search option with two buttons next, previous can make work easier so please create such search option
All can be done manually.
But it will reduce work right
To get to the assets blocks
I have to choose one of the components in my project and get it there. Would it be possible to generate this block if I drag and drop one of the files from the media pane?
@Peter, that's certainly an interesting idea. In theory it's possible but it will take a bit of work to make it happen.
Hi Peter! Thanks for the suggestion, I think it sounds like a cool idea! As such, I filed an issue to track it. If you have any further things you'd like to add, feel free to leave a comment there.
can we actually do something like this if we wanna make our own?
If you follow Beka's link above to her final GSOC writeup there is a link from that page about how to add your own helper blocks for components (which should include extensions). Note that while her work has been merged into ucr, it won't be publicly available in the production version of App Inventor until sometime mid-July when our next release goes out.
Yep! Like Evan said, this should work with extensions. I tested it before putting up the PR, so unless something in App Inventor has changed since then it should be good. Extension compatibility was one of the priorities for the project =)
Here is the documentation for adding helper blocks (all kinds) to your component. And here is the document specifically for static dropdown blocks (which are a bit more involved hehe). Best of luck! If you have further questions about it feel free to message me or post a new message in the extension developer category
Oh and if you make somethig cool with it, send me a link once the helper blocks are in the production version of App Inventor! I'd love to see what people make
Best,
--Beka
the main thing is where is the OptionList and Default annotation inside common
