Community
Participate
Working Groups
Some of SWT widgets like List, Table, Tree, TreeTable can have a really large srollable area. It will be very convenient to have automatically provided splitter on these witdgets that will enable multiple views/viewports (even more then two) for a scrollable area. This way high level components like Navigator or JDT Package View will get an incredibly convenient feature of viewing and scrolling subparts ov tree independently. If this is not possible on a low level, please assign it to JDT team to enable this feature for JDT Package View. Please let me know if you'd like to have screen mookups for this feature.
This looks like a JFace feature request.
We are well past feature freeze for 3.0
Reopening now that 3.0 has shipped
Tod, is there are any progress on this feature? Maybe any thoughts/ideas/pointers that would allow community to participate into this?
This is not currently one we are looking into
Ted, can you please suggest some place or person to discuss possible scenarious? I'd like to look at options to implement it for Tree widget. If there are any issues that already being observer or if there is anything that makes this feature difficult to implement on a low level. Thank you.
I'll move this to SWT - they will know who to send this to.
SWT is designed to provided "efficent, portable, access to the capabilities of the operating systems on which it is implemented". Since none of the operating system native widgets have this capability, it doesn't belong here.
Steve, I think that I will have to reopen this bug. I'm not an expert in native wigets and can't tell about all operating systems, but really long time ago when I was playing with MFC on Windows, I recall that one of the MFC application wizards in MS Visual C++ was generating an application that was adding a split bar to a component/widget inside some window. Again, I don't remember all details, so it is quite possible that such funcionality had been provided by a parent container/placeholder. Can you please investigate further and maybe readdress this issue to more high-level components. I truly believe that such feature will dramatically improve UI usability, especially for a large tables and trees and especially if it will be provided on a low level, so developers will have to do a minimal efford. Thank you.
I can tell you that on Windows, for example, the native tree and table widgets to not come with a splitter. There also doesn't exist a native "split pane" control. SWT provides something called SashForm but it is not part of a native control. MFC is an application framework that is written on top of the win32 API. It might contain the thing you are talking about but win32 itself does not. SWT is programmed against win32, not MFC. So, the right place for this functionality is in JFace, or nowhere. The problem with providing "free" sashes is that different applications have different policies regarding dragging and the like. If the sashes are provided for "free", then they can't embed policy decisions. Back to you Maxie ...
Steve, thanks a lot for the explanation. By the way, can somebody tell me what kind of widgets are used to show trees in JDT Package Explorer and Navigator views?
They are TreeViewers which just use SWT trees
Tod, I'm not experienced with viewers. Can you advice if two viewers (tree, table or treetable) can share the same model?
Yes they can as this is all done via content providers. The same view in two different windows effectively does this now.
Great! Can we than transparently create a sash and a second viewer in place of the existing viewer? Visually it could be a small draggable area on top of the verticall scroll bar (similar to what we have in MS Word, Exel and other MVC-based apps).
Eugene the route for this is likely to create one viewer with two widgets - this way the content provider is specified and you decide how it is rendered. I don't see us adding this to Eclipse ourselves as it is getting too large but this might be a nice thing for you to whip up and donate to the community.
Tod, sorry if I haven't explicitly said that, but actually I wanted more then one splitter. The idea is to have as many splitters as user wanted, so he can create multiple small working areas that can help a to save a lot of time on scrolling trough large tree. For Package Explorer it could be extended to allow each split panel to show some working set or even single class (kind of nice substitution/addition to outline view). I'd love to try to protortype this for Package Explorer but right now I'm not sure how I can add extra slitters/sashes to existing component/panel and rearrange widgets accordingly.
(In reply to comment #16) > Eugene the route for this is likely to create one viewer with two widgets - this > way the content provider is specified and you decide how it is rendered. > > I don't see us adding this to Eclipse ourselves as it is getting too large but > this might be a nice thing for you to whip up and donate to the community. Tod, I made several attempts to implement this and it looks like the best option is to add such support on a view level. I've replaced original Package Explorer class with a decorator/proxy class that maintain SashForm in a view and create/delete separate instances of the original Package Explorer component per split. So, perhaps such decorator code could be generalized and done on a view level.
Created attachment 24416 [details] Multi-splitter prototype for a Package Explorer view Please let me know if I should submit a patch
I've packaged a feature patch for Eclipse 3.1 that can be installed/uninstalled from an Update Manager. Update site is at http://www.md.pp.ru/~eu/eclipse/ Tod, do you think it would be possible to address this issue in 3.1 or 3.2 streams?
Eugene I can only look at code attached to a problem report due to the EPL. We won't be doing any more feature work in the 3.1 stream so if it did go in it would be 3.2 or later. I will be happy to look at what you did if that is possible. The screenshot helps but I am not totally clear on your requirements - is it basically just sub scrollbars you wants - i.e. multiple scrollbars in a view?
(In reply to comment #21) > Eugene I can only look at code attached to a problem report due to the EPL. What about external code/fixes not attached but also released on EPL? Anyway. I'll create patch for my current changes and will attach it here tonight or tomorrow. > We won't be doing any more feature work in the 3.1 stream so if it did go in it > would be 3.2 or later. That is ok with me. I can still have my own feature patch trough update manager. :-) > I will be happy to look at what you did if that is possible. The screenshot > helps but I am not totally clear on your requirements - is it basically just sub > scrollbars you wants - i.e. multiple scrollbars in a view? Yes. But is actually little more then just a scroll bars. Basically each panel in sptitter is an independent packages/project view, so you can have different filters and working sets choosen for each panel. More over you can use "Go Into" independently as well and have independent settings for "Link With Editor". It is sort of mix of multiple packages + outlines views. Few words about my implmentation. I've replaced "Package Explorer" view with my own SplitterViewPart implementation, which is using a SashForm and can create multiple instances of original PackageExplorerPart on this sash. All view events are caming to my view and delegated to the currently active PackageExplorerPart (I have focus listener for activation). Quite non intrusive change I believe. The major issue is to deal with CustomFilterActionSet, because it is registering its on menu listener. I still working on it and it seems that I'll have to remove this action set from PackageExplorerPartActionSet and register single instance on SplitterViewPart initialization. So, what do you think?
I think this is a nice idea. My suggestion is to also look at what Msoft Outlook 2003 does with its "favorite Folders" view. I think that implementation would be ideal for eclipse as well. The way the Favorite folders works is that you can select any folder and add it to the Favorites. The Favorites view would then list only what you are actively working on. This could be a real time saver. /sanjay
(In reply to comment #23) > My suggestion is to also look at what Msoft Outlook 2003 does with its "favorite > Folders" view. I think that implementation would be ideal for eclipse as well. > The way the Favorite folders works is that you can select any folder and add it > to the Favorites. The Favorites view would then list only what you are actively > working on. This could be a real time saver. Sanjay, can you please attach some screenshots? I was thinking about adding an empty split and allow drag-n-drop from other panels.
Created attachment 24829 [details] Snapshot of outlook favorites view
Created attachment 24830 [details] Work in progress "Package Explorer" splitter prototype
(In reply to comment #25) > Created an attachment (id=24829) [edit] > Snapshot of outlook favorites view Hmm. This is not quite the same what I've done. There is already Bookmarks view in Eclipse and you can probably request to allow bookmark folders or packages inside some view...
(In reply to comment #21) > Eugene I can only look at code attached to a problem report due to the EPL. > I will be happy to look at what you did if that is possible. I've attached a patch for org.eclipse.jdt.ui. My current problem is to update view menu properly when jumping between splits.
(In reply to comment #21) > Eugene I can only look at code attached to a problem report due to the EPL. > We won't be doing any more feature work in the 3.1 stream so if it did go in it > would be 3.2 or later. Tod, have you had a chance to look at the code I've attached hare? What are the chances to get this in 3.2?
I haven't had a chance yet. It is not currently on the 3.2 plan as we have to assess how useful this is for the SDK.
(In reply to comment #30) > I haven't had a chance yet. It is not currently on the 3.2 plan as we have to > assess how useful this is for the SDK. I thought it is useful at least for Package Explorer and probably for Navigator views. Is there are difficulties? Because if feature is there it will be up to the user if he want to use it or not... In any case it would add some new flavor to Eclipse UI because none of other IDEs has it at the moment.
just want to follow this thread - thx!
Another approach might be that of the "split editor" solution: just make it possible to open up another Package Explorer View.
(In reply to comment #33) > Another approach might be that of the "split editor" solution: just make it > possible to open up another Package Explorer View. Please don't do that! It will be nearly impossible to manage more then two opened views. Not to mention that views controls and decoration will eat-up a lot of screen estate like it happens with current "split" editor implementation.
Is there any development gone regarding this (very usefull) enhancement?
(In reply to comment #35) > Is there any development gone regarding this (very usefull) enhancement? No, sorry, there are currently no plans to work on this. Frankly, I don't believe it is as simple as providing support for splittable trees in JFace. Some technical problems are for example: - which of the trees does the "collapse all" view action collapse? - when you are in "link with current editor" mode, which of the trees is the one that is linked? Then there is the question whether this will benefit most of the Eclipse users and not a small fraction that is able to understand what is going on when you split a tree viewer.
(In reply to comment #36) > No, sorry, there are currently no plans to work on this. Frankly, I don't > believe it is as simple as providing support for splittable trees in JFace. > Some technical problems are for example: > - which of the trees does the "collapse all" view action collapse? In the currently selected splitter of course. Also note that it should significantly reduce need in doing collapse all, especially if each shown tree fragment would also allow "go into". > - when you are in "link with current editor" mode, which of the trees is the > one that is linked? It is linked with splitted tree. So, if it can't find match in currently selected splitter, then it should check ever other split. > Then there is the question whether this will benefit most of the Eclipse users > and not a small fraction that is able to understand what is going on when you > split a tree viewer. By default there would be no split. Users who needed them should be able to create as many splits as they need.
Hitesh is now responsible for watching bugs in the [Viewers] component area.
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. If you have further information on the current state of the bug, please add it. 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.
