Community
Participate
Working Groups
Build ID: 3.3 RC4 Steps To Reproduce: 1. Open Eclipse 2. Open debug perspective, bring breakpoints view to front 3. Reduce the width of the breakpoints view (@see screenshots) More information: Windows manages to create more lines for the tool bar, linux only creates two..
Created attachment 72583 [details] Linux version with buttons missing the in the breakpoints view
Created attachment 72584 [details] Windows version with all buttons accessible due to multiple lines
I think the reason behind this behavior is the fact that the GTK Toolbar implementation doesn't support the SWT.WRAP style bit afaik. But I wanna see this too :)
Moving to SWT for comment on platform differences.
The GTK way of showing "hidden" items is to add an overflow menu and add items to it.
(In reply to comment #5) > The GTK way of showing "hidden" items is to add an overflow menu and add items > to it. > Ciao Gheorghe :) So, are you going to fix this the "gtk way" or is the current behaviour already the "gtk way"? I looked at the breakpoints view again and could not find that "overflow menu", can you add an image to show this using the minimized breakpoints view I used? Additionally, I saw that the little "triangle pointing down" icon, containing actions like "Group By" etc., gets a separate line in the process of reducing the width (see attachment), which is why I would assume that creating more lines on GTK is not that uncommon but I might be wrong...
Created attachment 72675 [details] Resizing toolbar example This is the resizing toolbar snippet from http://www.eclipse.org/swt/snippets/ When I shrink the shell, the items just disappear and I don't get a chevron. PW
(In reply to comment #7) > Created an attachment (id=72675) [details] > Resizing toolbar example > > This is the resizing toolbar snippet from http://www.eclipse.org/swt/snippets/ > > When I shrink the shell, the items just disappear and I don't get a chevron. > > PW > Thanks for pointing this out :) So, looking at my linux pic above, what does this mean in regards to the chevron, is making a second line for it a separate bug? Also, can you please answer my other questions in Comment 6? By the by, thanks for looking into this! :)
I guess I wasn't clear enough. I'm not saying that SWT currently implements an overflow menu to deal with items that can't be shown due to a toolbar resize. I was merely pointing out that native GTK apps (like GIMP) make use of overflow menus instead of moving items to another line. We need to do some investigation to determine if it's worthwhile to add this support to SWT. The one immediate problem that comes to mind is the one Helmut points out in the Debug view: They already make use of a drop down menu to present other options to the user. It might be confusing to add yet another drop down to deal with the overflow of toolbar items.
We already have a different visual affordance for these: TB overflow is indicated using a 'chevron' ( >> ) while the dropdown menu uses a triangle that points down. This should at least mitigate any confusion...
(In reply to comment #10) > We already have a different visual affordance for these: TB overflow is > indicated using a 'chevron' ( >> ) while the dropdown menu uses a triangle that > points down. > > This should at least mitigate any confusion... > Ciao Eric :) Looking at the pic above (Linux version...) I can see one chevron indicating that there is insufficient space to display the views name. However, there is no chevron indicating that not all icons are shown with the Breakpoints view. So, using the chevron in the TB too (maybe even starting an effort to consistently use chevrons all over the place) is a possible fix here Another question is whether or not we should align the behaviour between windows and linux, the windows behaviour is IMHO far superior since it finds a way to display all icons while the gtk way seems to only be able to indicate that there might be some more icons. Looking at the triangle pointing down (which gets its own line once space is limited) I tend to think that shadowing the windows behaviour is doable and should be discussed here since linux looses usability if the proposed gtk way is implemented...
(In reply to comment #11) > Another question is whether or not we should align the behaviour between > windows and linux, the windows behaviour is IMHO far superior since it finds a > way to display all icons while the gtk way seems to only be able to indicate > that there might be some more icons. When we can fix this, it will be the linux way ... always select the platform behaviour unless prevented. PW
Any update on this one?
This is actually a duplicate of bug 443185. *** This bug has been marked as a duplicate of bug 443185 ***
