Bug 474556 - [cocoa] Unified Toolbar has wrong height
Summary: [cocoa] Unified Toolbar has wrong height
Status: REOPENED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 4.5   Edit
Hardware: PC Mac OS X
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-SWT-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-09 03:35 EDT by Matthias Fuchs CLA
Modified: 2020-01-20 03:22 EST (History)
2 users (show)

See Also:


Attachments
Comparison between SWT and BetterZip toolbar heights (33.37 KB, image/png)
2015-08-09 03:35 EDT, Matthias Fuchs CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Fuchs CLA 2015-08-09 03:35:23 EDT
Created attachment 255731 [details]
Comparison between SWT and BetterZip toolbar heights

The empty toolbar has a height of 19.
As soon as I add a toolitem with text it height grows, and again when I add an icon (24x24 px).
The resulting toolbar height is 55px.

This is 19px too high. Look at the screenshot of how it should look like. It's compared to BetterZip with "small symbols" enabled. If I set BetterZip to "big symbols", the height is the same as my SWT toolbar.

So this implies to me that the height of the SWT based unified toolbar is always set to have big toolitems, regardless of the image size.

Either there should be a way to set the toolitem height (or toolbar height) or a style that to chose between "small" and "big" items.
I didn't find any SWT.* style so far. Documentation is also very scarce :-(

Hope this will be fixed anytime soon.
Comment 1 Eclipse Genie CLA 2020-01-17 11:42:41 EST
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. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. 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.

--
The automated Eclipse Genie.
Comment 2 Matthias Fuchs CLA 2020-01-20 02:50:59 EST
Just because no one had not comment doesn't mean it's fixen. I think those who care, like me, just didn't have any other information to add - so we wait for it to get fixen.
But if a new comment keeps this issue alive - I'm happily writing one :-)
Comment 3 Paul Pazderski CLA 2020-01-20 03:22:44 EST
(In reply to Matthias Fuchs from comment #2)
> Just because no one had not comment doesn't mean it's fixen. I think those
> who care, like me, just didn't have any other information to add - so we
> wait for it to get fixen.
> But if a new comment keeps this issue alive - I'm happily writing one :-)

The bot to bring up old bugs recently started to additional close them. From my subjective feeling this is ok because the larger part of those bugs are likely fixed or get no response. I disliked the change to make them wontfix at first but meanwhile I get the impression people are more likely to react on the close than just the message and the stalebug marker.

PS: just like you had wrote a comment to keep it alive, I'm forced from bugzilla to write something to reopen. ;)