This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
|Summary:||Support reusable editor tab|
|Product:||platform||Reporter:||Petr Nejedly <pnejedly>|
|Component:||Text||Assignee:||Petr Nejedly <pnejedly>|
|Severity:||blocker||CC:||dsimonek, mentlicher, mmetelka, rondruska, saubrecht, vv159170|
|Issue Type:||ENHANCEMENT||Exception Reporter:|
|Bug Depends on:||94604|
|Bug Blocks:||35586, 95039|
API and implementation
Description Petr Nejedly 2007-02-06 11:58:27 UTC
In order to support source browsing w/o cluttering the UI with many editor tabs, we need to provide an API for opening editor in tab-reusal mode. Opening an editor in tab-reusal mode would mean: 1. In case the editor is already opened, just switch to it. 2. If there is a tab-reusal editor opened already, replace it with the to-be-opened editor and switch to it. 3. Open a new editor and mark it for tab-reusal. 4. If the editor is modified, unmark it for tab-reusal.
Comment 1 Petr Nejedly 2007-02-06 12:00:06 UTC
Linked the dependencies, mark as started (I have proof of concept implementation that tries to simulate issue 94604).
Comment 2 Petr Nejedly 2007-02-06 12:13:08 UTC
*** Issue 90395 has been marked as a duplicate of this issue. ***
Comment 3 Petr Nejedly 2007-02-07 14:31:43 UTC
I'm proposing to add Line.SHOW_REUSE constant for Line.show() method and change the implementation of Line.show() so that it adheres to the abovementioned semantics. I'll attach a diff with changes both in API and implementation, and the apichanges as well. The implementation partially depend on issue 94604 (due in 6.0M8) for "nice" behaviour. I can emulate the behaviour so the API and somehow working implementation is ready around M7 for waiting API clients, but the implementation might move the tab position on editor reuse.
Comment 4 Petr Nejedly 2007-02-07 14:32:39 UTC
Created attachment 38175 [details] API and implementation
Comment 5 Vitezslav Stejskal 2007-02-08 01:47:56 UTC
I think the change is looking good, just a few things: VS1: (nit-pick) Could you please javadoc all params of openAtImpl? I know the method is private, but since you have chosen to write javadoc for it you should document all its parameters. VS2: Will it be possible to forcibly change the reusable-editor, ie. unmark the existing one and open a new one? Here is the usecase: You've browsed through some files and then you realize that the file you are currently looking at is actually important and you want to keep it around, but you also want to browse further to another file. This is pretty common situation I think and the solution for it could be the same as what web browsers do - 'Open Link in New Tab'. We could enhance navigation actions in the editor module to support that, but we would need to tell openide/text to stop using the current reusable-editor, leave it as it is and open a new one. Is this a reasonable usecase? Is it addressed somehow or can we address it please? The following questions do not concern the API, so the answers are not really important for the review, but I'll ask anyway. VS3: Shouldn't the decision whether the reusable-editor can or cannot really be reused be done at the time when somebody really wants to reuse it instead of making this decision at the time when the file in the reusable-editor is modified? Making the decision later could probably streamline the browsing even more - eg. you browse to a file, fix a typo in javadoc, save the file and browse to another one, for example. VS4: Will it be possible for a user to distinguish the reusable-editor-tab from normal editors in UI? Thanks.
Comment 6 Petr Nejedly 2007-02-08 11:24:56 UTC
-> VS01: copy/paste issue. @since tag doesn't belong there either ;-) -> VS02: Not currently addressed. I forgot to mention this change is going to be complemented with great improvements in editor history (ccing Mila in case he's not on the reviewers), so you can easily return to the file through a combo box. Also, as you realized,once you touch the file, it would stick. Should this became broader concern, we can either add new constant(_NEW_REUSE) or provide a semantic shift that e.g. if the currently reusable editor gets requested again in different mode (SHOW_GOTO), it switches to non-reusable. -> VS03: Good comment. I was thinking about this when implementing, but HIE recommendation was keep the file even after saved, so I implemented it the easiest way. Otherwise I'd have to keep a flag per editor or something. Talk to HIE if you feel strognly about this. -> VS04: Wasn't planned. Again, ask HIE, it may be nice if e.g. the reusable editor tab is slightly colored if that would be possible.
Comment 7 Jesse Glick 2007-02-08 23:40:15 UTC
Sounds good in principle. Will have to try it to see how well it works in practice.
Comment 8 Petr Nejedly 2007-02-09 08:16:11 UTC
Jesse, you can apply the attached patch and sed s/SHOW_GOTO/SHOW_REUSE/ in java/source/src/org/netbeans/api/java/source/UiUtils.java. This will cover Alt+G but AS-O as well though, which may be more that what want.
Comment 9 Vitezslav Stejskal 2007-02-09 08:21:18 UTC
-> VS02: constant(_NEW_REUSE) would be good. I think we will need it, see issue #95039.
Comment 10 Jaroslav Tulach 2007-02-09 09:25:12 UTC
Y01 Write a test.
Comment 11 Petr Nejedly 2007-02-09 11:25:32 UTC
-> VS02: OK, we need to iron out the semantics of _NEW_REUSE. Imagine the following situation: Two tabs: /reusable(1.java)] /selected(2.java)] user tries to navigate ("open in new tab") to 3.java. Should we A) unmark 1.java and open new 3.java B) replace 1.java with 3.java Both seem slightly wrong as A doesn't take the opportunity of reusing reusable tab (the user intention was in fact "keep this", not "open new"), while B is not opening in "new" tab). I'd personally vote for B, but as Dafe often says, I'm not a representative sample ;-)
Comment 12 Vladimir Voskresensky 2007-02-09 11:35:44 UTC
-> VS02. I think the behavior could be moved on client of this API. i.e. I vote for the browser approach: - In browser when you left click on link, usually current page is reused, but sometimes new page is opened (in our case - analog of "not saved editor" tab). - when you middle click - new tab is always opened, not any other "reusable" is reused
Comment 13 Jesse Glick 2007-02-09 17:21:33 UTC
An idea which may or may not be related, and maybe belongs more on nbui than an API review: Firefox with the Tab Mix Plus extension has the nice behavior that if you have a bunch of tabs open, and you are working in some tab somewhere in the middle, any requests to open a new tab will open it right next to the one you have selected, not at the end. This tends to keep related things together. (More precisely, for every time interval during which you do not switch tabs, all new tab requests are opened in sequence to the right of the selected tab. So a new tab may not be directly adjacent to the selected tab, but it will generally be nearby.) I actually don't so much mind NetBeans opening new tabs when I use Alt-G, as I mind those tabs being dumped way to the right of my (often long) tab list, so that I can't even see the original tab.
Comment 14 Vitezslav Stejskal 2007-02-26 04:21:13 UTC
I like Jesse's idea, it seems reasonable to open tabs 'nearby' the currently selected tab. But it looks orthogonal to VS02 and perhaps this whole issue, which is not to say that we should ignore it or loose it. -> VS02: Petr's example - I tend to think that A is a little bit more consistent, because the 'Open in new tab' will always do the same no matter where you invoke it. In option B if 'Open in new tab' starts in the reusable tab, the action will in fact unmark the tab and open a new one, right? But that's exactly what A does. -> VS02: Vladimir, I agree with you, clients (read editor) will have to handle middle clicks and/or add 'Open in new tab' action, but the openning itself is controlled by openide/text and the clients will need to be able to say that a file should be opened in a 'new' reusable tab (even if one is already opened and could be reused). VS05: Just a question: how is TopComponent cloning going to work for the reusable tab?
Comment 15 Petr Nejedly 2007-02-27 14:08:51 UTC
-> VS02: you're right, unless you think the user's motivation for choosing "open in new tab" was in fact: "Keep current tab open (no matter it it's reusable or not)". I'll try to describe the behavior in tests. -> VS05: If you make a clone, it certainly won't be reusable (you did explicitly spent too much effort on playing with the tab already). The original might be reused subsequently though. Switching to a clone is the same as currently - already open (one of them), keep the reusable marker on the originally reusable tab.
Comment 17 Petr Nejedly 2007-03-02 16:40:17 UTC
I have attached new patch that implements the enhanced API, contains tests and uses the semantics of REUSE_NEW proposed by Vita. Please review the patch/API.
Comment 18 Vitezslav Stejskal 2007-03-04 21:59:31 UTC
It's looking good to me. Thank you.
Comment 19 Petr Nejedly 2007-03-13 14:31:27 UTC
Committed while still using temporal TC replacement, so the reused editor window would "move" to the last position. (Still waiting for #94604) openide/text/apichanges.xml,v1.18 openide/text/manifest.mf,v1.16 openide/text/src/org/openide/text/CloneableEditorSupport.java,v1.30 openide/text/src/org/openide/text/EditorSupportLineSet.java,v1.4 openide/text/src/org/openide/text/Line.java,v1.5 openide/text/test/unit/src/org/openide/text/ReusableEditorTest.java,v1.1
Comment 20 Petr Nejedly 2007-04-06 20:51:50 UTC
Need to start using the new WinSys API (issue 94604).
Comment 21 Petr Nejedly 2007-04-06 21:14:21 UTC
Now it finally works as expected, no tab movement: openide/text/manifest.mf,v1.17 openide/text/nbproject/project.xml,v1.14 openide/text/src/org/openide/text/CloneableEditorSupport.java,v1.31 Whoever wants to be sure about correct behavior should depend on openide-text/6.15
Comment 22 jersonchua 2007-06-13 18:53:47 UTC
Is there a way to turn off editor tab re-use? I'm using "Go To Type"/Ctrl+LeftClick and prefer netbeans to open a new editor tab - just like in 5.5
Comment 23 Petr Nejedly 2007-06-13 20:27:57 UTC
For "Go To Type"/Ctrl+LeftClick, it was already disabled in trunk.
Comment 24 jersonchua 2007-06-15 14:31:17 UTC
Thanks pnejedly. Is there a plan to make this configurable?
Comment 25 Roman Ondruska 2007-06-18 14:56:04 UTC
Reusable tab option will be considered, but most probably per client (module) -- e.g. Debugger may introduce such option while other part of IDE not.