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.
I am not really sure when this changed, but I am almost positive this is a regression from 3.6. It used to be the case that when you selected a node in the Explorer that was scrolled out of the scroll area (horizontally or vertically), the scroll pane would adjust to display it (or as much of it as possible, starting from the left). This no longer seems to work - of course vertical scrolling works, but horizontal scrolling does not happen automatically. Not just an aspect of e.g. the Projects tab; happens also in All Files (= old Filesystems tab, more or less). This is a major usability problem, IMHO.
Note that you can use Ctrl-Left and Ctrl-Right to scroll horizontally, which is occasionally useful (e.g. if a node display name is too wide to fit in the Explorer window) but should not be required just because you are browsing up and down nodes IMHO.
*** Issue 37450 has been marked as a duplicate of this issue. ***
gtzabari claims this was broken in 3.6, not promo-D.
So I looked at it. Horizontal autoscroll partially forks for me. If i browse the explorer using up/down arrows, it scrolls correctly in both directions (at least on Linux, I've verified that even this is broken on windows). If I invoke "show node in ...", it scrolls only vertically, not horizontally. And there is one more annoyance: If I invoke "show node in ..." and have the node already selected there (but scrolled away), it doesn't scroll at all.
Seems it was broken by jrojcek's integration of tree table branch on 17-Apr-02. If I comment out his (strange) rectangle recomputations in BeanTreeView.showPathWithoutExpansion, everything works correctly even on Windows. Jano, don't you remember why you did such modification?
I don't remember. Sorry.
Fixed in: openide/src/org/openide/explorer/view/BeanTreeView.java,v1.24 Also, added scrolling in case of already selected but hidden node to: projects/projectui/src/org/netbeans/modules/project/ui/ProjectTab.java,v1.7
Note re. "If i browse the explorer using up/down arrows, it scrolls correctly in both directions (at least on Linux, I've verified that even this is broken on windows)." - this was broken for me on Linux, and the reason I filed this bug. I will check the next dev build.
Guys, the bug still occurs as of dev build 200406211800 under JDK 1.5 beta 2. Specifically, the explorer window does not scroll horizontally when I expand nodes that do not fit in the screen.
On subtree expansion, it scrolls only vertically, not horizontally, right? Hmm, that may still be considered an issue but hardly P2...
I guess P3 is appropriate. It does make KB navigation of deeply nested trees very cumbersome. On the other hand, navigating such deeply nested trees is less common in NB 4.0 compared to 3.x.
Jesse, Petr, This is both a regression and very annoying to me. You might have shallow working directories but mine are always very deep. This feature was working before and it sounds like a simple bug to fix (if only someone would take a look at it)... A final off topic comment, the recent Netbeans 4.0 dev builds have been completely unusable. There has been a noticable shift from stability to "add new features at all costs" recently and frankly it makes the life of beta-testers like me much harder. I have finally given up and jumped back to Netbeans 3.6. My main concern is that there are a lot of usability problems (like the IDE forgetting your settings when you shutdown and restart) that make using it hell. Even Netbeans 3.6 final shipped with more visible bugs than it should have (I remember some routine operations get exceptions on a regular basis)... What happened to incremental development? :)
> It does make KB navigation of deeply nested trees very cumbersome. I don't understand. If you're actually navigating the tree (moving up/down over entries), it scrolls correctly to show most of currently selected node. The only thing that doesn't work is horizontal scrolling when expanding a node. Do you have the same behaviour? In that case it makes mouse navigation worse, not the KB navigation, right?
"If you're actually navigating the tree (moving up/down over entries), it scrolls correctly to show most of currently selected node." - no, this is precisely what does not work for me - the topic of this bug. I will attach a screenshot. Here I have java/j2seplatform open and am selecting a class in the Files tab, entirely using the KB. Note that much of the label is not visible; I need to use Ctrl-Right to manually scroll it into view.
Created attachment 17263 [details] Screen shot
That is strange, that exactly works correctly for me. Both scrolling when navigating using up/down key and scrolling when navigating using CS-x from editor.
Ah, I got it. Seems like a regression in Swing to me, needs more analysis. Works perfectly on 1.4.2_05, is broken on 1.5 beta.
Petr, Please report this regression to Sun ASAP. My feeling is that they are planning to release 5.0 final very soon and unless this issue gets reported right away it might not get fixed for the final.
OK, verified it *is* a regression in JDK, just try running SwingSet2 both on 1.4.2 and 1.5.
Petr, I was right, they just released JDK 5.0 RC1. Did you file the bug on BugParade yet?
Used a workaround that sets the property JDK1.5 evaluates when autoscrolling. openide/src/org/openide/explorer/view/TreeView.java,v1.170
I've reopened this issue because in dev build 200409151800, horizontal scrolling still does not work in the Versioning explorer.
Works OK for me even in versioning explorer.
Petr, What build?
At least in 20040917. Anyway, versioning explorer should behave the same way as other explorers. When exactly doesn't it work?
Using the Versioning tab, if you expand folders (using the mouse or keyboard) deep enough, eventually some of them will fit outside the viewable area. The tab should scroll horizontally to make them visible, but it does not. I will try out the newer build soon but like you I doubt there have been any recent changes.
x
This was FIXED, not WORKSFORME.
Guys, this issue is still not fixed. dev build 200409281800, JDK 1.5 RC, expand nodes in the Versioning tab and it still scrolls right off the visible area.
dev build 200410070525, JDK 1.5 RC, in the projects tab if you scroll to the right as much as possible (use the mouse to drag the horizontal scrollbar) then use the keyboard to move up/down nodes, the beginning of the node label will be cut off (on the left). Expected behavior: horizontal view scrolls node into view such that left-most part of label is visible.
OK, now I see it. JTree scrolls in each direction only the amount to not scroll out the other side. So if you have a node so long that it is cut on both sides, it won't autoscroll at all. If you have your view scrolled right, it will scroll left only to fill the gap on the right side. I'm not going to change that behaviour unless specifically instructed so by HIE as it may be very annoing if you scroll to see ends of nodes and start moving up/down between them.
Petr, Sorry, but again I don't see how you can close this issue as fixed. I don't see autoscrolling working in the versioning tab or anywhere else for that matter. I have the tab big enough so the node can be displayed without being cut off on both sides but it still does not scroll. I have not noticed a single visible change since this issue was first created. Are you *sure* you actually fixed something in the code? If so, I honestly don't see it working. I've used clean userdirs, the latest builds, etc and it still does not work. I also assume you are using JDK 1.5 final under WinXP? When *does* the node auto-scroll horizontally now that it didn't when this issue was first created? BTW: The behavior you mentioned (only scroll to make sure the node fits in the visible area and don't scroll at all if the node is too long to fit at all) is basically the desire I am looking for; except in the latter case I would suggest auto-scroll should make sure the *beginning* if the node is visible, regardless of whether it'll fit in the visible region or not. Regardless of whether you make this change or not, I expect the other functionality to be fixed before this issue is closed as fixed :) We need to figure out if you and I are using different configuration which is preventing you from seeing this issue on your end.
OK, you're right. I went to an XP box (I don't use Windows myself) and tried it there. It really doesn't work. I'm sorry to tell you I'm not going to fix it, as the behaviour is controlled by PLAF and the behaviour under the XP LAF is consistent with WinXP behaviour (try it in windows explorer). If you try another LAF (such as Metal), autoscroll will work for you even on WinXP. I'm closing this as FIXED as I have really fixed (on 09/14/2004) the original bug - autoscroll wasn't working at all on JDK1.5, not even using Metal LAF.
Petr, Thanks for the response. I agree with your assessment that Explorer doesn't auto-scroll either so it is likely that the Windows L&F is applying this same behavior. I am curious whether it would be possible for me to file a RFE to add a "force autoscroll" feature to Netbeans that would enable autoscrolling regardless of the L&F setting. Is this technical possible or does the Windows L&F not expose a property to force this behavior?
This does not occure in latest builds of 4.2 on sol/sparc Metal LnF. If there are no more such problems on windows, I'll verify.
closing
This issue had *1 votes* before move to platform component