abstract tools UI from tools functions to allow for alternative UIs
See original GitHub issueWe have a general need to brainstorm new UI designs for tools as more tools are added. Maybe nested menus or a modal for more tools, as the menu runs out of space?
But to explore this, I’d like to propose that we separate the tools UI from the tool functions themselves.
By abstracting the tools UI from tools functions, we’d allow for alternative tools UIs to be attached instead of default Toolbar; an alternative to the above syntax might be to pass in the toolbar as a parameter, like:
var altToolsUI = new SomeOtherToolsUI();
img = new L.DistortableImageOverlay(
'example.jpg', {
tools: altToolsUI,
corners: [
new L.latLng(51.52,-0.10),
new L.latLng(51.52,-0.14),
new L.latLng(51.50,-0.10),
new L.latLng(51.50,-0.14)
]
}
).addTo(map);
…with the current toolbar as the default if it’s not set.
Or, we could do:
img = new L.DistortableImageOverlay(
'example.jpg', {
corners: [
new L.latLng(51.52,-0.10),
new L.latLng(51.52,-0.14),
new L.latLng(51.50,-0.10),
new L.latLng(51.50,-0.14)
]
}
)
.addTools(altToolsUI)
.addTo(map);
Then, the actual functions like Scale and Rotate and others would remain in this file:
while the UI would bind to those functions in this default toolbar or another UI:
Ideas welcome here!
Relates to #112 which allows for separate Rotate/Scale tools.
Issue Analytics
- State:
- Created 5 years ago
- Comments:17 (17 by maintainers)
@jywarren @sashadev-sky I think we can migrate this over to #170 now. Please have a look!
Thanks!
@jywarren Ok I am going to add this as another todo on the multiple image select PR I have open. That way when I finish implementing functionality I will remember to open the issue. Is that ok?