You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am currently looking at the editor for the replace field and was inspired by Notion.so which led me to the flutter package appflowy-editor which seem very much in line with something that would fit but needs some heavy modification to be adapted to our usecase. Looking for help in first designing a high level roadmap and then developing it. First step is to decide if we should develop it as part of this repo or as a Flutter package in a fork of appflowy-editor. Please join the discussion with your thoughts and ideas.
Current behaviour:
Inspelning.2024-03-05.160348.mp4
Design (WIP)
The editor pops out from the right-hand side of the screen on top of everything else covering about half the screen. It is navigated to by either pressing the edit icon in a replace_field. When there, you are presented with an editable text field where writing the character "/" opens a pop-up at the caret (cursor) where the user has a choice between all types of variables and all types of form fields. Choosing an element then gives the user some way of configuring it and once done is represented in the text either as {{variable_name_here}}/[[form_name_here]] or alternatively if it can be figured out how an inline widget.
In this design both the replace_field, vars_field, and forms_field allow the user to edit vars and forms. Either vars_field and forms_field should be removed or made to present an alternative way to edit vars and forms where those are the sole focus providing a preferable way to handle more advanced vars and forms configuration
To-do
Stage: Discussion
Issue
Status
Decision
Comment
Base it on AppFlowy-editor or not?
❌
Whether the feature should be based on AppFlowy editor, something else, or be built from the ground up.
Package or not?
❌
Whether the feature should be developed in this repo or as a package in a separate repo.
The text was updated successfully, but these errors were encountered:
Update: currently working working in lib/match/replace on branch feature replace-field-editor to see if i can create a custom menu similar to the one shown on "/" when writing "@".
Update: currently not working since the rewrite but will port progress from old version and then finish it. Current target is simple text-editor with [[foo]], {{bar}}, and $|$ each automatically getting colored a different color each as well as the keys { and [ expanding to {{}} and [[]] respectively and reversing to { or [ if immediately followed by backspace.
UI replace_field editor
Hello everyone and anyone!
I am currently looking at the editor for the replace field and was inspired by Notion.so which led me to the flutter package appflowy-editor which seem very much in line with something that would fit but needs some heavy modification to be adapted to our usecase. Looking for help in first designing a high level roadmap and then developing it. First step is to decide if we should develop it as part of this repo or as a Flutter package in a fork of appflowy-editor. Please join the discussion with your thoughts and ideas.
Current behaviour:
Inspelning.2024-03-05.160348.mp4
Design (WIP)
The editor pops out from the right-hand side of the screen on top of everything else covering about half the screen. It is navigated to by either pressing the edit icon in a replace_field. When there, you are presented with an editable text field where writing the character "/" opens a pop-up at the caret (cursor) where the user has a choice between all types of variables and all types of form fields. Choosing an element then gives the user some way of configuring it and once done is represented in the text either as {{variable_name_here}}/[[form_name_here]] or alternatively if it can be figured out how an inline widget.
In this design both the replace_field, vars_field, and forms_field allow the user to edit vars and forms. Either vars_field and forms_field should be removed or made to present an alternative way to edit vars and forms where those are the sole focus providing a preferable way to handle more advanced vars and forms configuration
To-do
Stage: Discussion
The text was updated successfully, but these errors were encountered: