Bugzilla – Full Text Bug Listing
| Summary: | "orion.edit.command" should expose more editor function | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Pradyut Sarma <pradyutksarma> |
| Component: | Editor | Assignee: | Project Inbox <orion.editor-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | eclipse.felipe, mamacdon, simon_kaegi, susan |
| Version: | 0.3 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Pradyut Sarma
Hi Susan, do you have plan for "orion.edit.command" ? I think the current support was fine for the initial samples, but we can do better in future releases. I think the services that allow for UI contributions (toolbar/etc) should be separated (and discussed in a different problem report). The "orion.edit.command" should redefined to have a service for task, for example "orion.edit.command.text" allow to get/set a range of text "orion.edit.command.selection" allow to get/set the selection and caret "orion.edit.command.scroll" allow to get/set scroll "orion.edit.command.model" map char offset to line index/line index to char offset "orion.edit.command.annotation" add a annotation to the editor etc The user would use combination of services to perform an action... There is also notification that the editor could send, like selection changed and text changed, that a plugin could subscribe to (I don't know if/how the service/registry handles that). Does the above makes sense to you ? (In reply to comment #0) > Hi, > > The client API, "orion.edit.command" currently helps users to contribute an > action to the editor toolbar when a file is open within the editor. > > Query1) What I want to do is to relate an action to a particular file type. For > example, the "FORMAT JS" action probably wouldn't make sense for a HTML file. I > would like to limit the appearance of that action to a file with .js extension. > Can I do that now already? I added this request to bug 337766. We have a similar concept in the orion.navigate.commands extension, so it makes sense that you could use the same kinds of validation properties to decide which files your action applies to. > > Query2) Also, can i use the same command to contribute an action to the toolbar > without any editor being open? Basically, I want to contribute an action to the > toolbar similar to the "New Folder" or "Link Folder" actions that are not > linked to any file. How do I do that? I'd like to understand what the command does in order to talk about where it appears. Can you open a separate bug explaining the case? Currently the actions in the toolbar are associated with the folder being viewed in the navigator, and in general the actions on the toolbar apply to the entire page. We don't currently have an extension point for those actions. (The internal command framework lets pages contribute commands there, but we haven't yet opened that up to an extension.) All we offer today is commands associated with files or folders. These actions appear either in the actions column adjacent to the file, or the "More" menu in the toolbar, which applies to the checked selections. See bundles/org.eclipse.orion.client.core/web/orion/fileCommands.js?line=679 (In reply to comment #1) > Hi Susan, do you have plan for "orion.edit.command" ? > > I think the current support was fine for the initial samples, but we can do > better in future releases. Yes, at a minimum we need the navigate.command and edit.command to be more similar where the concepts are the same. The only plan I had so far was in bug 337766. > The "orion.edit.command" should redefined to have a service for task, for > example > > > "orion.edit.command.text" allow to get/set a range of text > > "orion.edit.command.selection" allow to get/set the selection and caret > > "orion.edit.command.scroll" allow to get/set scroll > > "orion.edit.command.model" map char offset to line index/line index to char > offset > > "orion.edit.command.annotation" add a annotation to the editor > > etc > > The user would use combination of services to perform an action... > > There is also notification that the editor could send, like selection changed > and text changed, that a plugin could subscribe to (I don't know if/how the > service/registry handles that). > > Does the above makes sense to you ? It makes sense that a plugin might need access to most of the editor API, but I'd like us to evolve it as needed by real plugin developers/use cases. For the case of commands, I've tried to limit how much of the internal flexibility is exposed to the plug-in developer, on the assumption that plug-in writers need small API to basically redirect folks to their page/function. The editor case is definitely different, in that the plug-in is enhancing the function on the existing page. So I can imagine that there would be a larger API around extending the editor, but it'd be nice to prioritize these with use cases rather than expose the API as we know it. (perhaps you already have the use cases in mind...) Since Pradyut's query #1 is added to bug 337766, and query #2 is really a new bug, I'm retitling this bug to discuss Felipe's ideas. (Pradyut, hope you don't mind me hijacking this bug) Hey Susan, For Query#2, I will open a new Bug request and will explain the scenario in greater detail in it. For Query#1, Yes. I agree to what you have proposed in this thread and Felipe's use cases too are very important to be fulfilled for the editor to be really extended and consumed. And oh, BTW, I don't mind the hijack ;o) Feel free to re-scope and discuss. Thanks and Regards, Pradyut. (In reply to comment #3) > (In reply to comment #1) > > Hi Susan, do you have plan for "orion.edit.command" ? > > > > I think the current support was fine for the initial samples, but we can do > > better in future releases. > > Yes, at a minimum we need the navigate.command and edit.command to be more > similar where the concepts are the same. The only plan I had so far was in bug > 337766. > > > The "orion.edit.command" should redefined to have a service for task, for > > example > > > > > > "orion.edit.command.text" allow to get/set a range of text > > > > "orion.edit.command.selection" allow to get/set the selection and caret > > > > "orion.edit.command.scroll" allow to get/set scroll > > > > "orion.edit.command.model" map char offset to line index/line index to char > > offset > > > > "orion.edit.command.annotation" add a annotation to the editor > > > > etc > > > > The user would use combination of services to perform an action... > > > > There is also notification that the editor could send, like selection changed > > and text changed, that a plugin could subscribe to (I don't know if/how the > > service/registry handles that). > > > > Does the above makes sense to you ? > > It makes sense that a plugin might need access to most of the editor API, but > I'd like us to evolve it as needed by real plugin developers/use cases. > > For the case of commands, I've tried to limit how much of the internal > flexibility is exposed to the plug-in developer, on the assumption that plug-in > writers need small API to basically redirect folks to their page/function. > > The editor case is definitely different, in that the plug-in is enhancing the > function on the existing page. So I can imagine that there would be a larger > API around extending the editor, but it'd be nice to prioritize these with use > cases rather than expose the API as we know it. (perhaps you already have the > use cases in mind...) > > Since Pradyut's query #1 is added to bug 337766, and query #2 is really a new > bug, I'm retitling this bug to discuss Felipe's ideas. (Pradyut, hope you > don't mind me hijacking this bug) Hi Susan, I have created a separate bug for Query 2 here https://bugs.eclipse.org/bugs/show_bug.cgi?id=359541 Thanks and Regards, Pradyut. > > Query2) Also, can i use the same command to contribute an action to the toolbar > > without any editor being open? Basically, I want to contribute an action to the > > toolbar similar to the "New Folder" or "Link Folder" actions that are not > > linked to any file. How do I do that? > > I'd like to understand what the command does in order to talk about where it > appears. Can you open a separate bug explaining the case? > > Currently the actions in the toolbar are associated with the folder being > viewed in the navigator, and in general the actions on the toolbar apply to the > entire page. We don't currently have an extension point for those actions. > (The internal command framework lets pages contribute commands there, but we > haven't yet opened that up to an extension.) > > All we offer today is commands associated with files or folders. These actions > appear either in the actions column adjacent to the file, or the "More" menu in > the toolbar, which applies to the checked selections. > > See bundles/org.eclipse.orion.client.core/web/orion/fileCommands.js?line=679 Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html |