Add "Add Feature Collection" button, buildout menu tooling #231
Conversation
* Buildout types for utils * Update ee_plugin/utils.py
…function and updating UI elements to use it for localization.
alukach
force-pushed
the
feature/menu-buildout
branch
from
d137034 to
34d9236
Compare
| @@ -112,36 +112,54 @@ def initGui(self): | |||
| parent=self.iface.mainWindow(), | |||
| triggered=self._run_cmd_set_cloud_project, | |||
| ) | |||
| add_fc_button = QtWidgets.QAction( | |||
There was a problem hiding this comment.
Nice! I'm wondering if when we should implement the sub-menus to avoid having a long list of functions at the top level. We can punt beyond this PR.
There was a problem hiding this comment.
I'm wondering if when we should implement the sub-menus to ...
Not sure what you're saying here.
There was a problem hiding this comment.
Basically, have an "EE Tools" or something like at the top level and list the specific forms available under this sub-menu. In a similar way to how other menus work in QGIS:
| # Add actions to the menu | ||
| for action in [ | ||
| ee_user_guide_action, | ||
| None, |
There was a problem hiding this comment.
Is none used for some whitespace or something? Wondering if we should extract this to another function that potentially takes a list of actions, and figures out the formatting. With the sub-menu logic, we could also maybe use a dictionary that maps to the sub-menu/level desired? Again, we can refactor after this PR.
There was a problem hiding this comment.
Yeah, this is something that I was unsure about. If you look below, you'll see:
if action:
menu.addAction(action)
else:
menu.addSeparator()So basically, None represents a separator. That feels like an awkward convention but wasn't sure what would be better. I also am unsure that we want to keep the plugin menu and toolbar menu completely in sync as we are doing now.
ee_plugin/ui/forms.py
Outdated
There was a problem hiding this comment.
Nice! I'm wondering if we would like to have a single file per form to avoid them being to clustered in the future. Is listing all these files under the ui folder a good idea? That's the approach I took in #229.
There was a problem hiding this comment.
It could also be under a new python package called forms in terms of project structure 🤷
There was a problem hiding this comment.
I think separating the forms and possibly their handler into separate files seems like a good idea.
There was a problem hiding this comment.
@zacdezgeo what do you think about 864a1e5?
There was a problem hiding this comment.
looks great! Probably a nit, but can we add the form prefix to any form to help differentiate from the other UI files and have the forms listed next to each other when we add more?
This commit attempts to establish a new pattern where every form is written as a separate module in ee_plugin.ui with a form and callback function.
alukach
force-pushed
the
feature/menu-buildout
branch
from
5123411 to
3e76ba0
Compare
... TODO ...