Skip to content
This repository has been archived by the owner on Feb 1, 2020. It is now read-only.

when you drag a block away and it becomes a comment, then change to Text mode, commented block is gone #26

Closed
dmalan opened this issue Aug 26, 2016 · 11 comments
Assignees
Labels
Milestone

Comments

@dmalan
Copy link
Member

dmalan commented Aug 26, 2016

before:

blocks

after:

text

@dabbler0
Copy link
Contributor

This one's tricky. The "comment" thing that you get when you drag a block into space was a Code.org idea -- it's not really a comment, instead just a scratch space where you can assemble stuff in two dimensions instead of being bound to the left side of the screen.

We talked a bunch about how we might incorporate them into the program itself, and decided that because we wanted a strict bijection between text and blocks, we didn't want to include the free-floating blocks in the program because it would need some coordinate metadata, which was no good. So it's just a temporary workspace for kids to assemble blocks in weird orders if they want or view code snippets side-by-side.

Code.org recommended that we wrap them in the comment symbol to show that they wouldn't be part of the program when it ran. Not sure if that's confusing -- I think it would be more confusing not to have them, though.

@dmalan
Copy link
Member Author

dmalan commented Sep 30, 2016

Just to recap in-person chat, if a user has orphaned blocks in blocks mode and tries to switch to text mode, should first be prompted to confirm with, e.g.:

You currently have n blocks that aren't connected to the rest of your code. If you switch to text mode, those blocks will disappear. Are you sure you want to switch to text mode?"

@dmalan
Copy link
Member Author

dmalan commented Sep 30, 2016

Best to listen for body.unload and tab closing so as to prompt the user too. Or, instead of former, store disconnected blocks' state in C9 storage.

@dabbler0
Copy link
Contributor

I've hooked into close and toggle, and done a prompt on body.unload for now. @kzidane do you know how I would add extra session data to be preserved between reloads, like c9 does with Ace editor scroll data/unsaved edits?

@dabbler0
Copy link
Contributor

@kzidane Thanks!

@dabbler0
Copy link
Contributor

@kzidane @dmalan Branch https://github.com/cs50/harvard.cs50.droplet/tree/floating-block-restore has a prototype for all the functionality we want, but will depend on a pull to core cs50/core#1.

@dabbler0
Copy link
Contributor

dabbler0 commented Dec 2, 2016

@kzidane @dmalan Update: the pull request to c9 core is c9/core#377.

@dmalan dmalan modified the milestone: v1.0.0 Jan 22, 2017
@kzidane
Copy link
Member

kzidane commented Jan 27, 2017

@dabbler0 I might have found a way to extend the state, that doesn't require changing ace's implementation, or PRing the core. Would extending the meta object work for you?

var doc = tab.document;

// retrieve current state
var state = doc.getState();

// extend state
state.meta.droplet = 42; // could be any value

// inform state's changed?
// state.changed = true; 

// update state
doc.setState(state); 

cc @dmalan

@dmalan
Copy link
Member Author

dmalan commented Feb 5, 2017

@dabbler0 what do you think about @kzidane's proposal?

@dabbler0
Copy link
Contributor

dabbler0 commented Mar 5, 2017

@dmalan @kzidane This should be resolved now; uses document.meta instead of depending on the pull to core.

@dabbler0 dabbler0 closed this as completed Mar 5, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants