Community
Participate
Working Groups
My case is: 1) On the Git Remote UI there is the Fetch button in the main toolbar 2) When it is clicked I need to gather credentials (for repos cloned via ssh) I could open a dialog but regular dialogs look heavy and non-webby. I thought a dialog or some kind of a pane could slide out from the Fetch button. Then when credentials are passed, it would slide away. I think we could even make this pop-up pane part of the command definition. The same issue is with any remote Git operation like clone, push. Susan mentioned that it could also be useful during Move/Copy operation.
I hacked up a "choice menu" in the command framework so that the move/copy target proposals could be presented as if they were part of the command menu. This is something kind of similar, where we want the info needed to appear as part of the menu, or at least nearby.
part of this should work should include bug 338887 and bug 334190
I think the effort here should be on styling the dojo dialogs to be lighterweight, as well as positioning them near the dom node that launched them. I'd like to see all dialog opening funneled through a utility method so we can get common positioning and other support in one place. I was hoping this would also allow us to make decisions such as using a simple div instead of a digit.Dialog. But currently our dialog templating is tied to use of dijit.Dialog so this will require some further investigation.
Removing milestone. For all dialogs that have only one edit box (and window.prompt) we are changing to the lightweight edit box (eclipse.util.getUserText). I believe that we have changed over all prompts and dialogs to use this utility, but if anyone I'm cc'ing knows of any remaining one-liner dialogs, please try to switch to eclipse.util.getUserText. For multiple control dialogs, we want something similar to eclipse.util.getUserText, where the info being collected gets inserted into the DOM (not popped up). Inserting new input fields (vs. popping up something) has the advantages of: - user can still use the clipboard, access page data while the collection "box" is shown - user can use the browser convention to traverse the fields (accessibility). If we replace dijit dialog with some new lightweight modal pane, we have to reinvent traversal, etc. In general we really want to try not to grow any new dijit.Dialogs for this release and get away from them in the next release (or use them when a sledgehammer is needed but not for all data collection).
I have released a first cut at a slideout that collects parameters on commands. Right now it only works for toolbar items. I have to see how it is going to work for menu items (we probably want to insert the parameters into the menu vs. the slideout...) Currently the new file/new folder/new project commands, and editor goto line, are using the slideout. The remaining work here is to implement a similar mechanism for menus. Bug 358767 is where the work is happening for how one defines command parameters.
For menus, we will likely add a submenu with an input. This will look/behave a lot like the current "choiceCallback" mechanism, so we'll need to reconcile whether these are two different API or the same mechanism. For choices, we need to callback to compute the choices before invoking the command with parameters, so the callback is still needed, but we might want to rename it/change the API so that it fits in better with the parameter story.
Fixed with 6be63243be245acf704c424576d49291c2cc16a1. What we do: - for toolbar commands, we use the parameter slideout. I think this meets Szymon's original request. (Note that bug 365802 is the work to actually use this infrastructure in the git commands.) - for menu items, it seemed wrong to use the parameter slideout. If you are way down deep in the navigator list, you don't want to have to go back up to the top slideout area. I had hoped to popup a secondary menu with the dialog input, or perhaps even embed an edit box in the menu like gmail does. However, dijit menu doesn't support this and I was reticent to go hacking a lot of extra menu behavior in there. So for now, I decided on dijit Tooltip dialogs since they are at least lighter than the regular dialogs. We may end up revisiting this presentation if these tooltips play poorly on touch devices.
