Add comment formatting via a feature call

[jdanish]

Right now the different comment styles are handled via code that requires a re-build. Ideally we'd have some defaults but be able to add others from a feature call so it can happen all in a gem-step project.

Bonus if we can see the options similar to the enum function.

This is also a bottom level of priority for this time period.

[benloh]

Given the three issues...

• 752

• 751

• 758

  ...we probably want to consider implementing all of this as a new comment keyword that accepts a type and text?

A few complications:

• multiple lines -- currently script lines are only allowed on a single line. They do not wrap. Would line numbering be messed up if we allow long comment lines to wrap? Or does the js rendering handle that?
• enumerated types -- given #758 we need to dynamically define types.

If we're implementing enums, then we may as well do that first.

[benloh]

@jdanish Currently you essentially have five different comment styles:

1. explanationCommentHeader
2. explanationCommentBody
3. changeCommentHeader
4. changeCommentBody
5. commentKeyHeader

If we introduce project-customizable comment styles, would your comments map to one of the existing types (relatively simple)? Or are you wanting the project settings to be able to define arbitrary styles (can get really hairy if we're defining custom color, bgcolor, and font-style via the project setting UI, and EVEN messier if project settings are defining css)

[jdanish]

I think ideally we’d want something defined by the project. But we could agree to limit it to foreground and background color if that’d help?

If we are going to map to styles I’d want to create a few more to be safe and then let’s see how it goes. Would that work?

Joshua

On Aug 20, 2023, at 1:12 PM, benloh @.***> wrote:

@jdanish https://github.com/jdanish Currently you essentially have five different comment styles:

explanationCommentHeader explanationCommentBody changeCommentHeader changeCommentBody commentKeyHeader If we introduce project-customizable comment styles, would your comments map to one of the existing types (relatively simple)? Or are you wanting the project settings to be able to define arbitrary styles (can get really hairy if we're defining custom color, bgcolor, and font-style via the project setting UI, and EVEN messier if project settings are defining css)

— Reply to this email directly, view it on GitHub https://github.com/theRAPTLab/gsgo/issues/758#issuecomment-1685343907, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKGCKSEVRSK4TVR5QW2MKDXWJAOXANCNFSM6AAAAAA2ETIRTE. You are receiving this because you were mentioned.

[benloh]

A few more questions:

1. Who will be making these comment style changes? Just researchers? Or also teachers? Students?
2. How often would you make these changes? Just once in a blue moon?
3. Will customized styles be shared with across a lot of projects?
4. Is it important to have a UI (e.g. project setting edit UI) for making those changes? Or can we just use a TOML settings file? For example, we can just add a generic _commentstyles.toml file to art-assets (or perhaps in the main codebase if it should be common toall) for specifying a common set of comment styles (the ones you've already defined), and then add a project-specific styles, e.g. wetlands_beavers_story.styles.toml file to add project-specific customizations?

[jdanish]

I’ve lost track of which approach you are taking, so to make sure I am getting this right, the idea is that there would be:

1) Some named CSS style someplace 2) Only researchers would edit those 3) The list of names will somehow be available to kids / teachers 4) The kids / teachers can reference them

If that is the case, then I think we can have one set of styles per install.

If you are saying it could be done via the script, like in global, then likely we’d want some default styles and override them by project. I imagine that’s a lot more work though, so am OK with the approach above.

On Aug 21, 2023, at 1:41 PM, benloh @.***> wrote:

A few more questions:

Who will be making these comment style changes? Just researchers? Or also teachers? Students? How often would you make these changes? Just once in a blue moon? Will customized styles be shared with across a lot of projects? Is it important to have a UI (e.g. project setting edit UI) for making those changes? Or can we just use a TOML settings file? For example, we can just add a generic _commentstyles.toml file to art-assets (or perhaps in the main codebase if it should be common toall) for specifying a common set of comment styles (the ones you've already defined), and then add a project-specific styles, e.g. wetlands_beavers_story.styles.toml file to add project-specific customizations? — Reply to this email directly, view it on GitHub https://github.com/theRAPTLab/gsgo/issues/758#issuecomment-1686760727, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKGCKWVDX3LRI46Q2LLYVTXWOMVFANCNFSM6AAAAAA2ETIRTE. You are receiving this because you were mentioned.

[benloh]

Sorry about the confusion. As Sri and I were working through the details of the implementation, we realized there were a few things we could do to both simplify the implementation and make it more powerful. We're still working through the exact design of the implementation, especially since there is a whole set of related issues, but getting a better sense of how it might get used will help us flesh it out.

I think the key clarification is that only researchers are defining the styles, and kids and teachers are just the users. Followed by the ability to select predefined styles by kids and teachers (this would be a part of the comment-editing in wizard view revamp).

Thinking this through some more, I think what you're looking for is something like this:

• Support the definition of new comment styles that define: a. a match string for the type (e.g. ✏️ LETS CHANGE) b. defining whether that style is a bookmark or just a generic comment c. some kind of style definition (whether it's a css class definition, or a single color definition with headers and footers, tbd)
• Change the wizard edit view to allow: a. Selecting a predefined comment style b. Editing the comment text

The main question is how should those styles be defined? Is it correct to assume that re...

"we'd have some defaults but be able to add others from a feature call so it can happen all in a gem-step project."

...the important point here is not that it's a "feature call" but that you can change styles on a per-project basis without recompiling?

If that's the case, then main questions here have to do with where and how the styles get saved: a. Are we defining the comment styles on a project-by-project basis where each project has to define their own styles? (I'm guessing NOT) b. Are we defining a default common set of comment styles and augmenting the default project set with a few custom styles? (I'm guessing YES). c. Are we defining a default common set but also need to have a secondary set that is shared across different projects (e..g all the beaver projects use a similar set of comment styles, but the water quality projects use a different set) (I'm guessing this isn't as important? But if it is, it can have a big impact on usability, e.g. we have to figure out how to share/copy and paste styles either by using some kind of settings file, or providing a UI for copying/pasting across projects).

[jdanish]

In reference to your summary, yes that sounds right.

Thinking this over now that I see all the details, I think let's just assuming a set of common styles for the entire install, so IU has a set of styles for all projects. Period.

Ideally it won't require a recompile but if it does we can even work around that for the current funding. I think we'd rather put all the thinking about complexity elsewhere.

[benloh]

Thanks.

Just to make sure I understand. "IU has a set of styles for all projects" -- so VU shares the same set? Or does VU have it's own set?

And, just checking assumptions about "recompiling"...currently the comment style definitions have been moved out of SharedElements.tsx and put into a single file common-utilities.ts. I will probably also move the css style classes out of gem-ui.css and either figure out how to inject those classes into common-utilities.ts or via some other mechanism so that all the styles are programmatically defined in a single place. It should be much more easy to change for someone like you or Morgan. But it is not quite user-friendly for a non-technical user.

e.g. the current definitions look something like this: comment-utilties.ts:47

COMMENTTYPEMAP.set('🔎 QUESTION', {
  style: 'explanationCommentHeader',
  isBookmark: false
});
COMMENTTYPEMAP.set('✏️ LETS', {
  style: 'changeCommentHeader',
  isBookmark: true
});

You can also imagine we might migrate to something like this:

COMMENTTYPEMAP.set('🔎 QUESTION', {
  color: '#ed8b01',
  isReversed: true,    // for header white text on colored background
  isBookmark: false
});
COMMENTTYPEMAP.set('🔎', {
  color: '#43a873',
  isReversed: false     // for body colored text on white background
  isBookmark: true
});

...so you'd still have to modify code to set the styles, but now you can easily create as many arbitrary styles as you want, and do it all in one place. But you still have to recompile (e.g. run npm run gem) to update the changes. Is that sufficient? I'm not sure I'm quite understanding the need to avoid recompiling, unless you're thinking we are electron-ifying the app?

[jdanish]

Sorry, I was thinking of MEME when I said that. Recompiling is fine. Rather, it is ideal not to have to commit changes to gsgo, so ideally this would be in the art-assets folder or similar? Then that handles any case where IU and VU decide to have differences?

[benloh]

Got it. Thanks. So that does suggest that we want to introduce a common _commentstyle.toml file to art-assets so that you can define styles for the whole art-assets repo and to do so in a way that allows diferent sets.

How are you currently handling art-assets for IU vs VU? Are they on different branches? different folders? Do we need a more sophisticated way of handling the different projects?

[jdanish]

Right now we use different branches if / when we need to, but we generally can use the same branch since we are actually working in different models currently.

We do not use different folders. It is easier for folks to use a different branch than to find and change the local settings file to switch folders even though both should be easy.

I think using git or moving folders by hand is fine by now, so while it might be nice to have sub-folders and other things long-term, this all works great for now, and putting a single comment style file in art-assets sounds good.

[benloh]

Implemented with #763