Draft: feature editor prototype #236
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
helper text updates
form text field tests
persist edits to feature
date time field state
* make values focusable (and copyable) when isEditable = false. * organize color defaults for BaseTextField --------- Co-authored-by: Soren Roth <sor10874@esri.com>
To consume fix to snap-to-north
This test app contains a feature which has a feature form definition -- necessary for displaying a feature form.
Need to set this to use in the editor.
App is also responsible for identifying features
By stopping tap events until the editor stops again.
Rather than waiting until the end of editing. This doesn't actually make any difference right now; eventually it might be useful for the form to see a more up-to-date geometry in case some fields of the form rely on the geometry. This isn't as reactive as it could be. The geometry is only pushed after each geometry editor interaction finishes, but not "live" as the interaction is happening. I don't know if we could really achieve that without a lot of effort at the API level.
Just for point features, for now...
To match the sketches we have in our prototyping issue.
I tried to make it that the bottom sheet can be pulled from the bottom to open, but I don't know how to do that. The Compose doc suggests using a button so we can go with that approach instead.
If we run this code when the geometry try is not point or multi-point (I have only tested with lines and points, but presumably applies in other cases), `getSymbol` gives us a symbol that doesn't display (or maybe null) so it messes up the symbology of the editor.
To see how the form elements updates as the geometry is changed, without recreating the form (as is done when you have to swap between form and map view. Also updated the edit icon :)
So that form fields that use the geometry (e.g. showing length of line geometry) will update as the geometry is updated (note that it's not a completely live update -- it only happens when the `geometry` event fires on the geometry editor, so after each interaction completes).
And other small changes (c)
We need to access it to see things about the editor such as undo/redo state.
The sizing logic is not great with this toolbar. If the two sub-toolbars (the "control one" -- stop, discard, att/geom -- and the geometry one) have different numbers of buttons then the whole thing will shift around. I think we will need to do something more complicated to fix that. Possibly getting an intrinsic measurement of the width of the control toolbar and using that as a minimum width of the geometry toolbar, in combination with making it scrollable.
Apply feature symbology to the geometry editor for simple cases.
sorenoid
force-pushed
the
feature-branches/forms
branch
from
6cb93b7
to
10504ef
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an initial prototype of the feature editor component.
I have tried to mimic the architecture of the feature form component (and its microapp), and basically wrap the feature form in a containing component that also has a toolbar that controls a geometry editor.
My main architectural concern is that the feature editor may need to be able to see the state of the Map or (Composable) MapView for later enhancements. So maybe the feature editor itself should take in a MapState (rather than abstracting the MapView stuff away using the
maplambda as it does currently). However, maybe that's making the feature editor component unnecessarily large and heavy -- maybe doing that can be avoided. Maybe we could leave it the way it is now and if required change it later without too much trouble (i.e. let's not speculate about it now; let's change it if a problem actually arises)?Members of the Bistromath and Apollo teams: feel free to look over this code and add any comments or start any discussions you would like. Remember that we shouldn't have deep technical discussions here because this PR is publicly-visible :)