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.
Open two files, A and B (in that order). Consider that you are working in file A but want to goto-source (alt-O) C (currently not opened). You do the stuff that you intended in file C and then close it (don't want to have to many open files). Now the editor will focus on file B since it is the closest file in the order of the tab panel. I would like the editor to remember that the previous file that had focus was A and select it. (running 6.0 dev on NextentaOS, but probably works the same on all platforms, ie. not a but but an enhancement)
*** Issue 95713 has been marked as a duplicate of this issue. ***
To me this is a defect, not an enhancement request. The current behavior is simply incorrect.
I am afraid that this will need fixing in windows system. I think the current behavior is a general behavior of tabbed containers. What we would need is to remember the sequence of all tabs as they were opened (moving tabs to the front when they get focus) and then use this sequence to find the tab that needs to be focused when the current one is closed.
This is not a defect, changing back to enhancement.
Current state is as designed: - when user closes the tab, nearest one is selected to prevent from visual 'jumping' of the scene - it's very hard for user to remember the sequence history of more then 3 items - can you tell me what was 5th previous editor document you worked on? Surely no. That's why the feature will look like "tab jumping error" and not like the real feature - no tabbed UI of the other apps that I saw has this implemented - recent history/sequence is tracked by winsys and displayed after pressing Ctrl+Tab. Much more useful and cleaner. I'm closing as wontfix and put designer Jano on cc to comment further if needed.
How do Eclipse and IntelliJ do this?
I have to disagree - I am using eclipse for more than 2 years and this netbeans "feature" is really annoying (eclipse remembers previously selected tab as well as cursor position).
Re. no tabbed UI of the other apps that I saw has this implemented: in Firefox you can install the Tab Mix Plus add-on, which allows you to select which tab to focus when the current one is closed. There are about six options, "last selected" is one of them.
If my memory serves me correctly, I believe that IntelliJ remembers the last opened tab, as does also for example Opera. I also find the current behaviour rather annoying.
OK, argument of concurent products is strong, I agree with reopening. However do you really want to remember last 1000 selected documents? I believe not, one would be enough. I re-read original thulin's use case and I think it is exactly the only one which would be reasonable to support: Remember only one previous (last) selected editor document to fix use case described in the very first comment. When user closes multiple documents, behaviour will stay the same as now (see my arguments above to find out why).
Tab Mix Plus remembers the whole history. Remembering just the last tab would actually be confusing, because the behavior when closing a tab would not be consistent: sometimes the tab to the left would be activated, and sometimes the previously selected tab would be activated. And why 1000 documents? You would only have to remember the open documents.
to abadea: I do not agree.
For what it is worth, IntelliJ (and Opera for that matter) does remember the whole history and I would also argue that it is more useful than remembering just one. In addition IDEA lets you configure the closing policy.
dsimonek: you have the right not to. Just be careful that by trying very hard to shield the users from any behavior that you're afraid would confuse them, you can actually cause more harm. Linus Torvalds has described this well, albeit in strong words: http://linux.slashdot.org/article.pl?sid=05/12/13/1340215 http://mail.gnome.org/archives/usability/2005-December/msg00021.html
For me it is even more confusing when using "CVS->Search History" for file A. This will open an new tab which is "another view" of file A. Closing "Search History for file A" and not returning focus to file A is strange to me. It is possible to return to file A by pressing "ALT + TAB"
thulin: Yes, accepted. abadea: Accepted as well, I'll try to think about out it more and ask on usability team.
*** Issue 99336 has been marked as a duplicate of this issue. ***
I will weigh in saying that editor panes should be treated like windows, not tabs in a dialog, and windows *always* return to the previously-visible window, maintaining what's called "z ordering" when you close one. There's no doubt about that...z ordering is standard logic for any windowing system, which is what NetBeans' editor panes are part of.
And note that Charles filed issue 99336 (which was marked as a duplicate of this one) as a *defect*, not a request for enhancement. This clearly indicates that the current behavior is simply seen as *incorrect* by real world users.
Is this planned for 6.0? The target milestone seems to indicate so, but it was set when the issue was marked as WONTFIX.
Probably there won't be any time left for this to come into 6.0, unfortunately.
Deservers higher priority than P3.
I've just been bitten by this, so I consider this a defect now. I had several files open in the editor: A, B and C. I wanted to make sure I don't have any changes in A, so I did a diff on it. The diff window D opened next to the others, so now I had A, B, C and D, with D selected. After checking the diff I closed it, wanting to go on and revert the changes in A. However, when D was closed C was selected. I didn't notice that, so I managed to revert C. The editor's behavior is completely counter-intuitive.
abadea, if you feel so strongly about this, please help me and attach the patch, I'll happily review it and integrate. Too much important things on my agenda, sorry...
We will try to fix this bug for 6.0.
This doesn't seem like it should be too hard. NB already maintains z-ordering for Ctrl-Tab switching of editor panes...just use that to determine the new editor to focus when one closes.
Thanks to dsimonek who raised this issue to me. I have reassigned to Standa because Dafe cannot work on this now due to the other important tasks (fixing DirChooser and GTK L&F). Standa will evaluate, we still might not be able to fix it before FF next week due to time restrictions and other tasks pending, but we might fix it as a defect even after FF.
fixed pls note that the new logic applies to editor windows only, all other views behave as before Checking in model/DefaultModeModel.java; /cvs/core/windows/src/org/netbeans/core/windows/model/DefaultModeModel.java,v <-- DefaultModeModel.java new revision: 1.14; previous revision: 1.13 done Checking in model/DefaultModel.java; /cvs/core/windows/src/org/netbeans/core/windows/model/DefaultModel.java,v <-- DefaultModel.java new revision: 1.26; previous revision: 1.25 done Checking in model/Model.java; /cvs/core/windows/src/org/netbeans/core/windows/model/Model.java,v <-- Model.java new revision: 1.20; previous revision: 1.19 done Checking in model/TopComponentSubModel.java; /cvs/core/windows/src/org/netbeans/core/windows/model/TopComponentSubModel.java,v <-- TopComponentSubModel.java new revision: 1.17; previous revision: 1.16 done Checking in model/ModeModel.java; /cvs/core/windows/src/org/netbeans/core/windows/model/ModeModel.java,v <-- ModeModel.java new revision: 1.13; previous revision: 1.12 done Checking in Central.java; /cvs/core/windows/src/org/netbeans/core/windows/Central.java,v <-- Central.java new revision: 1.59; previous revision: 1.58 done
Is there a separate RFE opened to match behaviors of Tab Mix Plus (Firefox extension)? In the original example, I would expect C to be opened *between* A and B originally (i.e. A-C-B) so that it stays close to A, which it is probably most related to.
FWIW, I haven't filed such an issue.
FYI, for me this last described behavior (A-C-B) is purely one of taste. I'm entirely comfortable with C being opened at the end of the list; I have grown used to tab lists generally reflecting the order in which I have opened files (or web pages). It certainly seems like it would be a new enhancement...one that I'm fine living without.
So I've been using this new mode for a couple of weeks now and I have to say I find it annoying more often than I find it helpful. I frequently want to just close a whole adjacent sequence of tabs. (*) I used to be able to just go the first in the list, then press Ctrl-F4 repeatedly. Now the selected window jumps around seemingly at random and I often wind up accidentally closing something I did not mean to, since when I am about to press Ctrl-F4 I have no way of predicting where the focus will wind up (unless I happen to have memorized the order in which I opened every document). The behavior is also confusingly different from other well-known applications, notably Firefox. Is there some way of disabling this feature and returning to the 5.x behavior? (*) In particular, from files opened when I reopen a project that I had not looked at for days - another behavior I find to be more annoying than useful.
do you mean a switch in options dialog or just some system property? please file a new issue in either case and i'll take care of it.
Adding an option for this is not necessarily a good idea; we should find the best behavior and implement it. _Sometimes_ the new behavior is nice, especially after opening a version control window from an open file. For my tastes, it would probably be better to close tabs predictably but open new tabs next to the selected tab. But I suspect we need to get more feedback before making any other changes. Probably some people will be pleased with the new behavior in 6.0 and other people will hate it.
This issue is back :/ Product Version: NetBeans IDE 6.0 RC1 (Build 200711131200) Java: 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b05 System: Linux version 2.6.23-gentoo-r1 running on i386; UTF-8; cs_CZ (nb)
Yes, I noticed that it is not working any more. Also see issue #121218, relating to tab positions - not sure if it only happens to me.
Btw in Beta 2 it's ok.
caused by fix of #101700, cc'ing the author of the fix
Reason is there are 2 contradictory requirements: 1.Someone wants components to *remember* their position after they are closed (it applies to TC with persistence type only_opened (editors) and non persistent. See issue #101700. 2.Someone wants components *NOT to remember* their position after their are closed. The things is complicated by fact that if TC instance is gc'ed, new TC is created and it is opened in last tab. If editor reuses TC it is now opened in remembered position. One solution would be: If you want editor to be opened in new position create new TC ie. do not reuse already existing TC. Question is: When reusing existing TC is correct and when not? (Similar solution could be implemented in winsys. But I have no idea what is 'correct' behavior in given moment/for given TC instance. I am afraid at this moment I cannot make happy all. Possible solution would be to extend TC persistence type to cover this. It would be API change.
After discussion with Standa: It was unwanted side effect of my fix of issue #101700. It just stopped removing TC from mode when TC was closed and method remove did some additional work. So fix of this issue should be easy. So please ignore my previous comment.
fixed /cvs/core/windows/src/org/netbeans/core/windows/Central.java,v <-- Central.java new revision: 1.74; previous revision: 1.73