Enable user to add multiple projects

When deleting a block, the current UI displays the deleted block in the workspace and gives the user the option to save that deleted block again. It successfully deletes the block from storage, but this UI design is not intuitive -- should automatically display an existing block instead.

(made an issue to address later.)

Update tree based on addition of new libraries

To be called when the set finds/wants to clear/reset the instance

Update tree based on addition of a toolbox

Use a boolean returned from the methods which add components to project to determine whether a component has actually been added, then use this as the condition for adding a component of that type/by that name to the tree. This is just to make sure the tree only reflects what is actually added. Example/expected case in which an object would be passed to the ProjectController but not added is a naming conflict; thus, this TODO essentially just requires that addResource (in ResourceSet) is modified with the appropriate return//has the proper checks (presumably to be added in isValid)

The scrollbar in the Preview area appears above the new block popup dialog. Should not be visible when the popup is visible.

Apparently NWJS on MAc usurps the first menu item as the application menu. This mean all the file options are currently under 'nwjs'

Relatedly, we need to figure out how to override this menu name.

By convention, the last item in the file menu is the action to close the app.

On mac, this is the first menu (where file should be second).

Deleting a block that is not the last block created clears the workspace and throws Uncaught TypeError seemingly resulting from the rootBlock necessary to display the workspace being set to null. Other operations (such as creating a new block, saving, etc.) cannot be completed until loading a different block to the workspace, and the block will not be removed from the Library Tree until a new block is created.

Error not present in feature_tree nor in popup feature branch.

Goal: Create Menu Bar.
Structure:

• File
  • New...
    • New Project
    • New Project
  • Open...
    • Open Project
  • Save All
  • Save As...
    • Web
    • Android
    • iOS
  • Import
    • Import Toolbox
    • Import Blocks
• Edit
  • Block Name (Brings up popup to rename block)
  • More will be added as we get closer to this issue.

Blockly supports adding separators between blocks in the toolbox blocks (with categories, or without).

Consider adding a block to represent this separator in the available toolbox blocks.

In trying to load modules from other files (e.g. use FileManagerController in app_controller.js), node's require() function is not working, nor is JS's import { Object } from 'file_location'.

Currently, all files in src/ are loaded through script tags in the HTML file. In the future, should be able to use import to limit scope of imports.

Main bugs: Uncaught SyntaxError: Unexpected token import, when trying to do

import { FileManagerController } from 'src/file_manager_controller';

and

Uncaught Error: Cannot find module 'src/file_manager_controller' when trying to do

const FileManagerController = require('src/file_manager_controller');

Goal: Import outside toolboxes (.xml) or block groups (.js) from outside directory.

• Through File > Import > Import Toolbox / Import Blocks
• Account for when a toolbox (.xml) mentions a block that does not exist in block definition. If a block in an .xml file is undefined, (1) warn the user if they want to add the toolbox with undefined blocks, (2) if they say yes, add in a filler block definition that they can edit later on.
• If a user imports a .xml file that has more than one undefined block, they have the option to either not import it at all or generate stubs for all of them.*
• Ask if they want to copy into the project (create a copy within the project’s directory)

Note:
*This option will be improved for ease of use in future iterations; intermediary step for now.

Currently, clearing the block library destroys the tree instance then rebuilds it. Could be made better.

• Clicking button loads the develop page in the app window, with no affordance to go back.
• Redundant to future Menu help menu options.

Do we want the warning to fire when we change editor views? Do we opt for a smoother flow of warning upon an attempt at closing the application? If so, how do we give useful information about where the unsaved changes are? How do we reconcile multiple facets of the project being unsaved? Does that flow even make sense, or should people simply be expected to save their components and be inconvenienced otherwise? How can we improve upon the warning that comes up when there are technically unsaved changes, but you didn't make changes in the first place? (I'm referring to, in the current web DevTools, when you open the block editor and immediately try to close it and/or switch tabs; I find this unhelpful/annoying, as I don't care to keep technically unsaved changes I never made)

Along the lines of determining what constitutes removal of a block from a project, determine to what extent the user should be able to choose how a block is removed form a project (e.g. does removal mean removal of all its descendants in the workspace contents), and what any interface elements concerning these decisions would look like.

Goal: Be able to create a new project.

• Upon clicking New > Project, user will be faced with a popup about naming your project.
• Then, transition to creating your first block (new block popup).
• Start clean workspace with one starter block.

Some time after we support string tables as a project resource type #16, we should consider automatically generating string table entries for all user-visible messages in a custom block.

This might solve the expectation presented in this forum message, when they thought build.py should create such entries from custom block definitions.

Create the BlockLibrary class, in the process eliminating BlockLibraryController and moving all controller functionality to ProjectController

As multiple libraries are added to a project, prompt the user for the desired name and assign it appropriately.

Goal: Make left toolbar have two tabs. One is for block group navigation, the other is for toolbox navigation.

• Tab 1: Blocks
  • Group blocks (the groupings will be directly transferred to .js files for generators)
• Tab 2: Toolbox
  • Group blocks into toolboxes (allows duplicates across toolboxes, will be directly transferred into .xml files)

Note: Drag and drop to move blocks between groups/toolboxes will be completed in further iterations.

Rename this structure for concision.

change add for the resource sets to simply call add (the new name for addResource)

Upon refactor of ProjectController, give AppController a ProjectController (only, removing this.project in app_controller.js)

When clicking on block elements in the file tree, console throws an error:

Uncaught TypeError: this.openBlock is not a function

Clicking should display the corresponding block in the workspace. (This was working previously in individual branches but has become a bug in develop.)

Add libraries as root nodes for groups of blocks.

Will blocks be deleted by definition or by type? What is the protocol for blocks with the same name but different definitions or vice versa (depending on choice)? Will these ambiguities be prevented in naming?

(I'm leaning towards deleting by type and making more stringent naming restrictions based off of definition)

Goal: Make it so that you can open project through metadata file, or directory that contains it

• Make entrypoint the metadata file, always named metadata.js or metadata.json in topmost directory right in project folder.

Note: More functionality will be added in future iterations. This issue assumes the user has a correctly structured project directory with a metadata file.

When switching to Block exporter or Block Factory tabs, you can still see the top part of the file tree navigation UI near the bottom of the page. Probably a bug with CSS or tab switching. Should not be visible when switching tabs.

Currently is strings, needs to be changed to objects. Same for methods of Sets.

See google/blockly#756
and https://blockly-demo.appspot.com/static/demos/blockfactory/index.html#xd6zrv

Change block library import/export file type. Currently downloads XML file of the factory editor blocks. Should download the generator stub and JSON definitions and use those to import block libraries from file.

Goal: Make it so that you can save whole project on one button click

• Save block groups into separate .js files
• Save toolboxes into separate .xml files
• Focus on downloading web first and then work on Android and iOS once web is fully working

Note: Priority in making the download function work with multiple files. Placement of download button is arbitrary; will be moved to menu bar in future iterations.

The updatePreview() function under block_editor_controller.js uses eval() to evaluate manually inputted block definitions in order to display the user-defined blocks in the preview. Remove the use of eval() in parsing and displaying user-inputted block definitions.

Refactor devtools codebase structure to follow:

Main changes:

• Creating individual Project, Library, Toolbox, Workspace classes (part of the model)
• Clarifying the difference between views and controllers throughout the application
• Centralizing the application around three main MVC files from which there are other sub-files (see diagram).

Re-add template images as non-editable workspaces for each example block type.

Presumably if a user seeks to create a new block they intend to save it to their library.

Add different menus for library vs block nodes

Handle cases in which Project names are empty//add testing for various special character, etc.

Help in a window without an address bar, back button, search, etc. is probably not what the user expected. We should intend to implement all those features.

Goal: Extend block definition editor to support fields such as mutators id, extensions ids, and context menu enabled.

Currently, the block editor doesn't allow creating mutators directly in the application. More fields should be added to the devtool to allow for this functionality.

Where the TODO for this issue is noted in navigation_tree.js is where switching tabs based upon the tree will go. You can gather which view you should be getting based off of the type of node, whichis stored in its unique ID (IDs are unique because names are, and each ID is in the form '_'). Also note that the type of node can be gathered by its parent, since the tree now has user-facing Library, Toolbox, Workspace Contents, and Workspace Configuration sections for organization. Ask me if you have any questions//inform me of how you'd like the method to get the node type structured.

Check if name already exists (for duplicates) or if name contains special characters (escape if so) for names of Toolboxes (and toolbox categories), Workspace elements (contents and configurations), and BlockDefinitions. Checking should be done before adding a new resource element to the model.

Allow projects to manage Blockly JSON string tables, similar to those found in msg/json/. Such a string table would export to the correct place for each platform, and be used for all block previews (possibly allowing the user to change the language of the preview).

Related:
#1169 Support for multiple string tables in web Blockly.

When assigning a new blockLibraryController upon load, use its name from the last session rather than assigning 'blockLibrary'

Create the metadata for project, as a result (probably) changing (at least) the following methods currently contained within project.js:

• saveBlock()
• removeBlockFromProject()

and adding methods for the following (short tentative list) functionalities:

• getting the data/data maps for Toolboxes and Workspaces

Move to JSON

Currently the toolbox and workspace is edited in the same view. Create another tab that separates the workspace factory view into two separate views. Necessary for refactor.