Community
Participate
Working Groups
This was introduced into head sometime between Friday Feb 20 and Monday Feb 23. Only the maximize button can be used to zoom a view now.
Not sure who's responsible. I couldn't see any relevant changes in either ViewPane or PartTabFolder.
Opinions? This is how it works now: To maximize a view now, you have to use the maximize button (right of tabs) or double click on the area around the tabs. This means left click on a tab pulls down the list to switch between tabs and right click opens a popup menu. Double click was removed since it forces the delay on the left click to have to wait till there is no chance of a double click before bringing down the list which is too long.
IMHO, we should fix this. - Double-clicking on the title is the standard way to maximize in windows. Being different is really frustrating. - Most people arrange their perspectives such that they can see all their tabs, which means the "switch views" menu is almost never useful. That is, we've removed a useful function in order to gain a rarely-used function. - The "switch views" menu only shows up if you have more than one tab... this means that many users will never even discover that it exists. - Unless we have a good reason to change the UI, we shouldn't.
I have to disagree with you Stefan. I arrange my views so that Outline/Package Explorer/Heierarchy all are stacked and I can only see one tab. This gives me more space in the editor area so that I don't have to maximize it so often. Also with editors, regardless of which mode you use (single or multi), you will have editors you can't see. Switching between editors and views is much more important than maximizing them.
I agree that switching between editors is -much- more important than maximizing, but I also agree that double-clicking on the title to zoom is a common and expected gesture. Moving double-click to the non-tab area is going to be very confusing. Can we not keep single-click to switch (with no hysteresis) and double-click to zoom. It may not be that bad if the drop-down appears briefly before zooming. Also, single-click on a tab does not drop down the list when in multi tab mode.
Do you mean single click does not bring down the list in multi-tab mode when all tabs are visible?
The problem is that the editor list dialog that pops up steals the focus and then the second click does not go to the CTabFolder2. Therefore you will never get the doubleclick in the editor workbook. It works just fine in the stacked views (the list shows briefly then goes away) where I use a menu insetad of a shell. But I think it would be better to have consistant behaviour between the views and the editors. Besides, you are more likely to maximize the editors than the views so fixing the views doesn't help much.
How about this: there used to be a little menu (containing "move, maximize, etc.") that opened when you clicked on the view's icon. Why don't we bring that back, add a separator to the bottom, and add the contents of the "switch views" menu there. In that case, clicking on the icon always opens a menu, single-clicking on a tab gives it focus or begins a drag, and double-clicking on the tab maximizes. The way things are now, clicking on the tab does too many different things.
I think the tabs are too small for single-click to have different meanings depending on whether you're over the icon or text. I'd prefer to see: left click: select right click: system menu double click: zoom These should apply whether over the text or icon. Whether the system menu contains the list of other views in the stack is a different decision. However, it's already really confusing when views disappear from the stack even with the visual feedback of the chevron button appearing. If the chevron went away, the user would have even less of a clue where their other views went.
Having the view list open on left-click brings up even more problems. Now, when you click on a tab to give it focus, you get the view list. This means you have to click an additional time to make it go away. I wasn't suggesting that we remove the chevron. If anything, I think we should make it more prominent (black?).
Stefan did you try the scenario you mention about getting the list when giving a tab focus, this is not the case for me.
Comments from Nick: I'd prefer to see: left click: select right click: system menu double click: zoom This scenario is critical for Lotus.
Matthew - see the arguments above. It is not possible to have the left mouse select and left mouse double click zoom. Not without introducing a delay for the list appearing on single select. This delay makes the list unusable.
That depends on what Mattew means by "select". If "select" means bring the tab to the foreground or give it focus (ie: the 2.1 behavior), then there is no problem -- and I totally agree with him. If "select" means "open the view selection popup", then this is problematic. There are many other ways that we could open the view selection popup that don't involve left-clicking on the tab. Can we possibly use one of them instead of breaking the double-click behavior?
> That depends on what Mattew means by "select". Yes I was referring the 2.1 behavior. -m@
Me too.
I am open to suggestions. The little arrow to access all the rest of the items is insufficient for switching between editorsviews. It is giving me RSI. A key board shortcut is not a good answer - I am looking for a mouse driven solution because in some scenarios, the user does not want to go to the keyboard. The delay before showing the list on single mouse click is unacceptable. What else can we do?
I think it might make sense to keep the double click zoom "when there is a title bar", this is more like MDI behaviour and maps to what you would get with a shell on the desktop.
I disagree. The behavior I requested is absolutely critical for Lotus. We are using views in tab folders with hidden titlebars to give the same effect as an editor folder. Please allow this to be configurable for RCP applications.
Double-clicking on the tab to maximize is a commonly used action, and removing it is very frustrating. In the new look, the tabs ARE the view title bar. The fact that we've changed the underlying implementation and included new functionality shouldn't change their old behavior. Having maximize only work for views with CLabels would only make it more frustrating when maximize doesn't work in the rest of the views. Veronica, perhaps we could consider adding additional rows of tabs when the first row runs out? That would be more visible than the tiny triangle, and would reduce mouseclicks to switch between tabs.
I have removed the following from CTabFolder: - single click on selected tab calls showList - double click on the background maximizes CTabFolder By default, the only way to maximize the CTabFolder is to click on the maximize image and the only way to get the list is to click on the chevron. It is now up to the application to define whatever double click or single click behaviour they desire.
I20040404 is behaving strangely. Single click on the tab name does different things for views and editors and also does different things depending on whether or not you can see all the tabs. If you can't see all the tabs single click brings up a list of the tabs you can't see. The list of tabs looks really different between views and editors. FWIW, here's what I want it to do: - Single click on the tab name should bring that tab up to the front of the stack and make it active. That's all. - Double click on the tab name should do what single click does plus it toggles zoom on that tab. - Right click on the tab should do what single click does plus it brings up the tab menu, containing: - Restore - Move - Size - Fast View (only for views) - Maximize - (Separator) - List of all the tabs here... - (Separator) - Close - Close others (means close others on the same stack) - Single click on the tab icon should do what right click does. - When space is tight, tabs should either overlap (like physical paper tabs would do) or abbreviate. Having the tabs vanish is not a good design. - When space is *really* tight, instead of a chevron it should use left/right triangles to scroll through the tabs. - View tabs should keep their icons even when not on the top of the stack, just like editor tabs. - There should be an option to turn off the tab name and show only the icon. This would save a bunch of space if you can live with that style. - Hovering over a tab should use a popup to show the full name if it is abbreviated or has the text turned off (maybe always). - Tabs should highlight subtly when you move the mouse over them to indicate they are clickable (like tabs in the preferences window). - View tabs and editor tabs should behave exactly the same except where noted. This ditches the annoying little popup list of views and the not so little popup searchable list of editors. You can always bring back the old Editors view if you like lists of open editors (that could be used for example as a fast view), but you already have Ctrl-F6 and Ctrl-Shift-R so I'm not sure how many different ways you need to provide. Note that I'd rather have it always do the right thing than have an option to make it do the right thing.
I just submitted a patch that fixes this in head. However, I'm keeping this bug open until we open new bugs to track the editor tab double-click behavior and capture ed's enhancements in comment 22.
I overall agree with Ed's suggestions about click handling, except for overloading the icon area. Since view tabs in particular tend to be small, I think single-click anywhere in the tab area should select and "that's all." <g>
Ok, I can live with that.
Are we just talking about the default behavior for the ide? If so ignore comments below. I disagree with you guys (I have to <g>). Especially with the new presentations API, there is no telling how big a tab will be. Expanding the view on a double-click event in the tab is absolutely critical for LWP. Remember, we are actually using views as editors. I have not done a deep dive into the latest presentation code, not sure if this behavior can be defined at the presentation level. If so ignore above comments. -m@
please look here as well https://bugs.eclipse.org/bugs/show_bug.cgi?id=53069 double click should be consistent between views and editors.
Matt, I think you, Ed and I are all in violent agreement: - Double click on the tab name should do what single click does plus it toggles zoom on that tab.
The presentations API is capable of determining the double-click behavior (in fact, everything that Ed suggested could be implemented using the presentations API). I actually like Ed's suggestion of using the icon to drop down the system menu (as it did in Eclipse 2.1). Even in the new look, the tabs are still much larger than toolbar icons and people don't have any trouble clicking on those. If we added mouse-over affordance for the image, it would be pretty obvious that clicking on the image will do something different than the rest of the tab.
I really don't see a need for overloading left-click behaviour on the tab if right-click can give the menu. Keep it simple: left click to select, right click is menu, whether you click on the text or icon. Another argument against having left-click for menus is that the click behaviour for drop-down menu invocation is different on different platforms. Sometimes it appears on mouse up, sometimes on mouse down (which then allows you to select an item on mouse up).
*** Bug 51432 has been marked as a duplicate of this bug. ***
hmm... this bug report is against the double click maximize being removed. I think since we are pressed for time and M8 is approaching, I would like to mark this as fixed and if there are other requests or enhancements we document them in new bugs so that we don't lose this information. any objections?
I think this can be closed.
closing
*** Bug 56809 has been marked as a duplicate of this bug. ***
