Bugzilla – Full Text Bug Listing
| Summary: | [Edit] Opening a file should activate compare editor | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Pawel Pogorzelski <pawel.pogorzelski1> |
| Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | daniel_megert, Kevin_McGuire, Szymon.Brandys |
| Version: | 3.5 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
| Bug Depends on: | 278005 | ||
| Bug Blocks: | |||
|
Description
Pawel Pogorzelski
Build id: I20090522-1710 I was describing the state in text compare. Java compare works in a different way. I don't agree. In opening (or double-click) must activate the editor which is marked in the Open With command. See bug 277679 why Java compare is different. Suggest to close as INVALID. >In opening (or double-click) must activate the editor which is
>marked in the Open With command.
Typo. Correct is:
Opening (or double-click) must activate the editor which is marked in the Open With command.
(In reply to comment #2) > I don't agree. In opening (or double-click) must activate the editor which is > marked in the Open With command. Dani, is it your personal feeling about the issue or official UI guidelines? I'm asking because I could be not aware of a similar discussion already made. What I want to see when double clicking the file it's the content. I assume that if there's an editor already opened for the content then it will be activated. Consider the steps: 1. Open a Java file with a Text Editor 2. Open the same file with a Java Editor 3. Close the Java Editor 4. Java Editor is selected in Open With menu for the file 5. When double clicking the file Text Editor is activated Is it a bug in your judgement? For me it was a reason why the file was opened in Text Editor. If the user wants to see the content why couldn't we just activate the editor the user has opened some time before? CCing Kevin, he could add some value to the discussion. >Dani, is it your personal feeling about the issue or official UI guidelines?
"Open" opens (or activates if already open) the the last used editor or the default editor. Open With shows that editor by having a dot beside it. Since the compare editor is not an editor that directly acts on a file it is not in that list and hence must not be considered. That's how it works since day one.
Sounds reasonable. I'll wait for Kevin's input and decide what to do with the bug. I believe it's working correctly although I see nothing in the UI guidelines. Where I think the confusion arises is that the compare editor isn't open on A, nor on B, but conceptually on both. Thus it doesn't participate in Open With as other editors (as Dani noted comment #5) since it's input, the combination of files A and B (or the local and remote version of A) isn't something you can navigate to. While we're on the subject though: The one exception to this is the Synchronize view, where we do the wrong thing on purpose <g>. There, the Open With menu is about the local version, and we add a single "Open in Compare Editor" as a sibling menu to Open With. As I recall, we did this because we thought it confusing and restrictive for users to treat the sync elements as a combined local + remote. However, that was before we starting thinking about logical resources, and if I were to do it again I think I'd treat them as a proper sync element, and all you'd get is Open With->Compare. You'd then use the popup in the compare editor areas itself to get other editors on that part of the resource pair. One thing that is probably a bug: the Open With menu has a dot beside Java, but that's not the editor you get on double click. Dani? >One thing that is probably a bug: the Open With menu has a dot beside Java, but
>that's not the editor you get on double click. Dani?
This still belongs to the Synchronize view comment, right? The dot denotes the default editor which is used by the normal 'Open' action. Normally, views execute that action when 'open' is triggered. The Synchronize view has redefined this, so it's not really a bug. Changing the Open With menu content and default depending on the view it's shown might be confusing.
(In reply to comment #8) > This still belongs to the Synchronize view comment, right? Correct. > The dot denotes the > default editor which is used by the normal 'Open' action. Normally, views > execute that action when 'open' is triggered. True. Perhaps the way to express it is that double-click typically aligns with Open, and the dot in Open With says what Open does. So the problem is that there is nothing to indicate what double-click will do. > The Synchronize view has > redefined this, so it's not really a bug. Changing the Open With menu content > and default depending on the view it's shown might be confusing. I'm not sure I understood that last sentence. In any case, as I think more about this, the origin is that the sync elements are treated as local resources for the purpose of Open/Open With and that's not something I'd want to revisit now. Recommend we just close this bug. >I'm not sure I understood that last sentence.
I meant if we would add 'Open in Compare Editor' to the Open With command it would become view dependent and that would be confusing.
Agree to close.
(In reply to comment #10) > >I'm not sure I understood that last sentence. > I meant if we would add 'Open in Compare Editor' to the Open With command it > would become view dependent and that would be confusing. Yes agree. Dani, Kevin, thanks for your opinions. Closing as INVALID. Please let my provide a broader context on the bug. For some time the Workspace team has had internal discussion about the future of Compare. At some point we agreed that the way to go is to use two fully functional editors while comparing any files. Bug 278005 has been opened to track this. As I spoke with Szymon, in the current context (3.5) this bug is INVALID. However the idea of solution is correct given the planned future work in Compare. Thus, I'm reopening the bug an setting bug 278005 as a blocker. Dani, Kevin, hope you agree. I disagree. First, even with bug 278005 the compare editor would not be an editor for a single file. Second, the real estate of a normal vs. a compare editor is different. (In reply to comment #14) > First, even with bug 278005 the compare editor would not be an > editor for a single file. It works that way because we don't have support from UI. The compare editor should not be a part, it should be rather a container (visible or not) joining two parts of comparison. If we have nested parts, we would be able to use UI container to host the result of comparison and nested parts would be rightful editors (with separate editor inputs). However because this work is scheduled for 4.0, we can't do much about it right now. This bug and bug 278005 should be considered as planned work/investigation during 4.0. *** Bug 277697 has been marked as a duplicate of this bug. *** This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |