Project

General

Profile

Actions

Emulator Issues #7793

closed

Fix Toolbar Icon Spacing

Added by PEmu over 9 years ago. Updated about 8 years ago.

Status:
Invalid
Priority:
Low
Assignee:
-
Category:
UI
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
Yes
Relates to usability:
No
Relates to performance:
No
Easy:
Yes
Relates to maintainability:
No
Regression start:
Fixed in:

Description

Post 4.0 the ability to move the toolbar around was removed and as a result now the Open icon is excessively close to the left window border and doesn't match the spacing of the other icons. I would like to suggest adding a greater amount of padding before the Open icon to fix this issue if possible.

How it looks now: https://i.imgur.com/dlQctSO.png

How I think it should look: https://i.imgur.com/lM5roBK.png

Actions #1

Updated by JMC4789 over 9 years ago

  • Category set to ui
Actions #2

Updated by PEmu over 9 years ago

I don't mean to spam my own requests too much but it would be nice to have this looked into before 5.0. imo we shouldn't be releasing new stable versions with GUI problems (if this is in fact determined to be one).

Actions #3

Updated by delroth about 8 years ago

  • Assignee deleted (MayImilae)
  • Priority changed from Normal to Low
  • Milestone set to Current
  • Regression changed from No to Yes
  • Easy changed from No to Yes
Actions #4

Updated by Fog about 8 years ago

Possibly a wxWidgets quirk?

Screenshot from OSX: https://cloud.githubusercontent.com/assets/6551020/12155389/7444b4d0-b48a-11e5-8ad7-bbbe5c148662.png

Linux: http://i.imgur.com/gUbhPp7.png

Thanks gamax92 for the screenshots.

Actions #5

Updated by BhaaL about 8 years ago

As mentioned on IRC, I don't really think this is actually a bug. As it is there, it is intended - altho it might not necessarily be pretty or what some may expect.

MaJoR was kind enough to provide us with a more direct comparison:
Toolbar Comparison

You can see some small dots on the 4.0 screen, to the left of "Open"; aswell as different background in the right part.
Those dots usually indicate that the toolbar can be picked and dragged around...and you can see the toolbar ends after the last button.
With newer revisions, this has changed - I'm guessing since it doesn't make sense to actually move that toolbar around.

One could argue that it is an esthetic issue tho, since the margins around the seperators between individual button groups leave more empty space than is visible to the left of the "Open" button.

Actions #6

Updated by PEmu about 8 years ago

BhaaL wrote:

As mentioned on IRC, I don't really think this is actually a bug. As it is there, it is intended - altho it might not necessarily be pretty or what some may expect.

Yes I do not believe this is a bug with the interface, I just think how it is currently set up looks bad. As far as I can tell the size of those buttons is defined by how wide the icon/label is rather than being uniform. So in the case of the Open button there is very little padding due to the short "Open" label. I think it would be preferable to have some additional padding on the left side of the button but I don't know the best way to go about doing that. One option I considered would be to swap out the icon with a new version that has some additional transparent columns on the sides to force the button to be wider but I don't know if that solution would be considered too hacky.

Actions #7

Updated by MayImilae about 8 years ago

Pringo wrote:

One option I considered would be to swap out the icon with a new version that has some additional transparent columns on the sides to force the button to be wider but I don't know if that solution would be considered too hacky.

That won't work. :/ All icons are exactly the same size 32px square. The block needs to be square, so adding horizontal pixels would just mean losing vertical pixels, and making the image smaller. This is entirely a padding problem!

So um, I'm going to try to explain what I think is going on. Imagine "x" is an icon, ":" is the grab point, and "|" is padding. Each icon has padding to its left and right, like this: |x| . When icons are place beside eachother, with how wx appears to handle it, the padding stacks. |x||x||x|. Before, the grab point and it's padding served as the left hand edge, which meant it was :||x||x||x|. That placed the first icon far to the right of the left window edge, while the grab point was right up against it. But without the grab point, there is only a signal padding in place, and it is very close to the edge. |x||x||x| . Of course the titles of buttons affect padding too, but that's not really an issue for this.

Of course, a proper composite system would work differently. So instead of having padding that is tied to the left and right of every single element, it has a floating padding element. Let's use ‡ for that. So instead of |x||x||x| you have ‡x‡x‡x . Which gets far more consistent results!

Hopefully you understand what we are saying a little better?

Btw, I haven't looked at the source so I don't know for sure if any of this is true, but that's what it looks like is going on, to my artist/designer eyes!

Actions #8

Updated by Fog about 8 years ago

  • Milestone deleted (Current)

Removing from current as it's not a blocker for release.

Actions #9

Updated by delroth about 8 years ago

MaJoR, please decide whether you think it should be fixed before 5.0 or not. I think getting our UI right is important.

Actions #10

Updated by Fog about 8 years ago

delroth wrote:

MaJoR, please decide whether you think it should be fixed before 5.0 or not. I think getting our UI right is important.

Discussed with her in IRC, the UI as it is doesn't really seem to be a problem. Going to mark it as Invalid based on that.

Actions #11

Updated by Fog about 8 years ago

  • Status changed from New to Invalid
Actions

Also available in: Atom PDF