exlted / pencilcode-rewrite

A ground-up rewrite of Pencilcode and Droplet

Pencilcode-Rewrite

A ground-up rewrite of Pencilcode and Droplet

pencilcode-rewrite's Issues

Blocks in general need to be scriptable

As noted in #2 the rendering needs to be generalized in some way. However, blocks should probably be scriptable, we'll provide the basic block types built in that should work out of the box (Block, nestable block, multi-nestable block) but any specialized block should probably be defined in the same location that the rendering code is defined, might even be able to be in the same file as the palettes and just have a single "loader" section of our code that parses out the file and passes the data to where it belongs.

Build an interface for a parser to pass information in that will build blocks

As we want the parser to be as separated from the renderer as possible, we need a primary public interface to pass information into and take information out of for the parser to build the file and give us blocks to build

Nested Blocks need to be stable

Nested blocks are currently the only blocks that can be made in the test environment here, Nesting seems to work relatively well, but it needs to be more stable.

Design the Active Document system

We will need something to manage the state of the active document that isn't the renderer. This may be the primary go between of the parser and the renderer, but it is more likely going to be the go between of this section, Parser, Renderer, Document, and anything that implements this API backend.

Fix the dragging

Right now, the blocks are held fast at the "top left" corner by the mouse, they should instead move by the delta of the mouse and possibly lag a little behind (for aesthetics sake)

Decide on a back-end parsing system to implement

Since we are going to need a parser, we need to decide on one to use. The original Droplet used Antlr, that might be an option. Whatever we use, we need to heavily document the process that is needed to turn a generic parser into the block-based parser that we'll need.

Deliverables for this issue will be
-A parser that will produce an output that allows us to create "blocks" for a language (C, C++, Java, Python)
-Documentation for the process that changed that parser from how it was found
-A test (read minimal and simplistic) system to create blocks from a file in the language of the parser

Add Better Rendering for when you are typing

Currently you can type in blocks... it just doesn't look like it when you click on them, when a block is marked as "writable" it should show a "text box" with a flashing cursor

Design the import file

My current thoughts are that a palette should control the blocks that appear in the (as of yet non-existent) block-list, the styles of all blocks (using a pre-computed CSS-like system) and the design of all blocks, at this time I'm not sure what the file format should look like, but if all three of those are going in a single file it'll end up being pretty large so we might split those out into three separate files then.

If it's all in one file it almost certainly needs to be JSON or XML to make parsing simple

Bonus points if we can make a palette to help us make palettes in the future!

Genericize block rendering code

Blocks need to be better at their rendering, right now the code is an absolute mess and a bear to write. It would also be nice to be able to make the Paths be data-driven rather than hard-coded

Design an interface for the parser to take input from the renderer when the "document" changes

The "Active Document" is stored in it's own system, and it has to push data back to the parser to verify and get the new blocks back into the renderer

Add animation to the blocks

Let's make the blocks look pretty, this is a larger scale project and will be sitting around a long time. Right now, I think that adding a "stretching" animation for nesting blocks to "engulf" the block being nested into it would look great