Community
Participate
Working Groups
I think SWT should allow for TabFolders to have multi-row tabs (if the OS supports it like at least Windows and Linux/GTK does). Suggest using SWT.MULTI to set the TCS_MULTILINE flag on the windows control at least.
api request, SN to consider
See also bug 28722.
Created attachment 9610 [details] SWT.MULTI without a manifest file I'm going to submit a patch to implement the SWT.MULTI flag for TabFolder. Here's a screenshot of it in action.
Created attachment 9612 [details] SWT.MULTI running *with* a manifest file As seen on Windows XP SP1.
Created attachment 9613 [details] SWT.VERTICAL option without a manifest file (not included in the patch) I played around with adding a SWT.VERTICAL flag and it worked fine without the manifest file (see the screenshot) but the text didn't appear when I did have a manifest file. Therefore I pulled out that change. I guess CTabFolder will have to do vertical tabs.
Nice work Ed. Will your patch include just Win32 support or Linux/GTK/OSX as well?
Just Win32; somebody else will have to do the others. Until then it will have to just be taken as a hint and ignored on the other platforms.
Created attachment 9616 [details] Patch to implement SWT.MULTI on Win32
Created attachment 9617 [details] Patch to the examples to use SWT.MULTI It should be verified that SWT.MULTI is ignored (if it's not implemented) on platforms other than Win32 or this change to the examples might cause a problem there.
Bug 52780 could use this.
This is low priority and probably won't make it into 3.0. There are "what about the other platforms?" issues as well as testing issues. (ie. do computeSize(), getClientArea() etc. still work. There are crazy work arounds in TabFolder on Windows for redrawing. Are these broken?). BTW: The SWT.MULTI kind of TabFolder is generally considered to be bad UI design. The problem is that the tabs move and disorient the user.
I'd really like to see this make it in 3.0, for example the SWT Control example has 17 tabs and without this patch you often end up with those left/right arrows to scroll through them. I don't have a Mac or Linux box but if there's something else I can do on Windows, fixing bugs etc. let me know. The other platforms can just ignore the SWT.MULTI hint if they want and things should still work fine. I don't necessarily like the way the tabs move around but I'm used to it by now from other apps like TextPad and many Windows XP dialogs, and it's better than the alternative. So that's not a good reason to hold off on it. BTW, it seems to me that this has been requested a few times before but I can't find the other requests if they exist. Maybe I'm remembering passing references in other bugs that never got reported seperately.
I would like to see this added for 3.1.
So would I. To me, the tabs changing size and moving is a very small tradeoff for being able to see tabs for all of the files that one has open. It could also be an optional setting so that those who like it the way it is now can keep it that way. When one is constantly switching files, the extra effort that one exerts in selecting a file adds up. One already has to select a file from a long list of files in the package explorer and the way it it now makes one select from another potentially long list (this one not being ordered in any way) to switch to that file.
From a discussion with Steve, I have opened Bug 76684 to cover the possibility of such an option on CTabFolder.
I find myself frequently editing 10-20 files with large file names, many of which begin with the same word. With the icons, file-extensions, X (for closing), and the ellipsis, only the first 7 characters of the file name are displayed when 12 or more editors are open. And this is with 1600 pixels to work with. I work on a project with over 1000 files as I'm sure many eclipse users do. Not only does the large number of source files virtually guarantee I will be editing many at the same time, it also usually leads to larger file names (to avoid duplicates). As far as I'm concerned, the tabs might as well not even exist when I have over 11 files open. Switching editors by [some-action], [scan list of editors], [some-action] becomes quite a burden when switching editors multiple times per minute, which is done frequently in debugging. Having the editors available already in plain view, prevents the first action, as well as limiting scan-time. This is basically the only thing I don't like about Eclipse. It *far* surpasses any other difficiency I ever notice. There are so many comments about this problem. Why not fix it sooner? I know I obtained Eclipse for nothing, but I'd happily pay for this.
I'm in the same boat as Scott regarding his comment #16 and frequently editing many files. Any chance of hitting this in 3.2, or at least a commitment to the next release if time no longer permits? There are currently 17 votes between here and bug 28722, and Mr. Burnette has already contributed a good amount of work to this. I'd rather run this feature officially than using a patched version of Eclipse. Thanks!
As a note, the editors in Eclipse use CTabFolder, not TabFolder. As a result, anyone wanting multiple rows of editor tabs, you probably want to vote on Bug 58945.
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.
