Bugzilla – Full Text Bug Listing
| Summary: | Implement split editors | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Eric Moffatt <emoffatt> |
| Component: | Client | Assignee: | Eric Moffatt <emoffatt> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | curtis.windatt.public |
| Version: | unspecified | ||
| Target Milestone: | 9.0 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Eric Moffatt
OK, now that we have something we're starting to capture some of the issues surrounding this functionality. Directing commands to the 'active' view is already being worked on by Silenio but here are some of the questions that we'll have to answer going forward (for this comment I'll call the new thing the 'aux editor', if someone has a better name bring it forward): 1) How do we show the file / path that the 'aux editor' is showing? The main editor gets a bread crumb) 2) How do we allow users to open files in the 'aux editor' ? The current implementation of Ctrl+Shift+'f' will only ever affect the main editor since it displays its info as links which get directly handled by the browser. 3) Do we want the main and aux editors to be symmetric ? When working in a split editor mode should both panes show the same info and have the same functionality ? Here's the result of me and Silenio talking about the above issues (Silenio, feel free to correct any misunderstandings): There seems to already be a discussion of moving the 'breadcrumb' into the editor's pane (to recover the vertical space used in the current layout). To us this seems like it would solve many of the issues: 1) It allows the file path of the aux editor to be displayed 2) It allows a place to an host editor-specific 'open file' UI 3) It maintains the symmetry between the two split panes. We need to get together and determine whether this will be sufficient and, if not, what else needs to be done... We're also going to be using the 'splitter' code to host the split editors. This has an issue in that there's already a splitter in the markdown editor and there's already a mechanism to change *that* splitter's orientation. If we have Anton's current UI of a dropdown for the editor 'mode' (normal, v split, h split or Pip) then this may not be a usability issue as much as one involving the saved state info for the splitter. Note that the current code is in the branch 'emoffatt/SplitEditors'... OK, here are some of the takeaways from today's UX call, please correct anything that I misinterpreted: Editor layout: Decided: We should put the breadcrumb at the top of each editor Tentative: We could add a 'Search' icon to the same area as the breadcrumb to allow for 'Open File' (Ctrl + Shift + f) behavior. Note that we could also handle Ctrl + Shift + h here as well. URL: Tentative: We should have a URL format that will define both the path for the 'aux' editor as well as that of the main editor. Nav Clicking: Decided: Clicking in the navigator should open the file in the currently 'active' editor. Handling Markdown Editors: This is an open area for discussion. The issue is that this editor already contains its own splitter for showing the preview, potentially causing the UI to become cluttered. Tentative For now we just don't treat them differently but we should talk further about this concept (i.e. perhaps 'preview pane' should be a new editor concept in its own right a la the 'aux' editor ?) . A side note about the navigator handling. While there seems to be general agreement that clicking a file in the navigator should open the clicked file in the currently active editor (does anybody disagree with this?) there are valid concerns that this will require a fundamental change to the current design philosophy of using URLs for navigation and allowing the browser to perform the operation. Currently the entries in the nav are *links*. If we want to implement the 'open in active editor' heuristic then this will have to change. Note that this is very far-reaching in that it should also affect any other click-to-open scenarios as well. One approach to this would be to drive things outwards from the two editor's 'setInput' methods: - operations that used to be links are changed to call 'setInput' on the currently active editor's InputManager - 'setInput' constructs the appropriate URL and sets that URL into the browser (so that a refresh gives you what you're currently seeing). This was implemented in Orion 9. |