Skip to content

Fix buttonset items' layout calculations and painting (fix #3554) #3565

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 31 commits into from
Feb 28, 2023

Conversation

martincapello
Copy link
Member

@martincapello martincapello commented Oct 20, 2022

Fixes several issues when displaying buttonsets. This required a few changes in the sheet.png file.
To verify the changes see:

  • Context bar buttons.
  • Canvas size buttons.
  • Debugger buttons.
  • Outline buttons.
  • Dynamics buttons.
  • Symmetry buttons.
  • Pivot point options.

Fix #3554

@martincapello
Copy link
Member Author

@Gasparoken Don't review this yet, because I will add some styles to make the buttonset a bit customizable. I will reassign you when done.

@dacap
Copy link
Member

dacap commented Oct 25, 2022

Just giving a try to this PR, the brush size button is not aligned with the center (I didn't see other buttons):

image image

Previously:

image image

@martincapello
Copy link
Member Author

I can see the difference in the 1pixel case, but I don't see any difference with the 16px brush. Also, I think that any even brush size is displayed the same as before. For the odd cases I will investigate a bit, but I would suggest comparing how all the other buttonset items look now.

@dacap
Copy link
Member

dacap commented Oct 25, 2022

Sorry, the problem appears only with odd sizes:

image

@martincapello
Copy link
Member Author

martincapello commented Oct 25, 2022

I will try to explain the issue using the canvas size buttons. This is how it looks with this PR:

image

In the image you can see the dimensions used to calculate the position of the icon inside each button. As you may notice, the last row of buttons look different than the others, despite using the same area for positioning elements. This is due to the following overlapping when painting:
image

In the above image I displaced a bit to the right one of the buttons in the last row to see how they overlap.

Then, for the Brush Type button in the context bar I use the same criteria to calculate the position of the icon:
image

Without this PR, the height used to calculate the position of the icon in the last row is greater than the other rows, then you actually end up having some misalignment issues like this:
image

A possible solution would be to modify a bit how the button set items are displayed to something like:
image

But, giving it a second thought, this may not work as well. Because the brush type button height would end up being 15px, and 15px / 2 = 7px = 14 px / 2. Currently the height used to calculate the position of the icon is the client bound height, which for the last row of buttons has 3 extra pixels, so currently is 16px for the brush type button, hence a 1px icon is positioned at 16px/2 = 8px, and this is the reason you see it aligned vertically (see EDIT2)

EDIT:
The horizontal alignment is displaced one pixel because of the change I made to getTextIconInfo(), currently it does:

box_x = (bounds.x + bounds.x2())/2 - box_w/2;

In this PR it does:

box_x = (bounds.x + bounds.x2() - box_w) / 2;

So, for the same 16px, in the first case box_x = 8px, and in the second case box_x = 7px. However in neither case it is aligned at the center, given that you cannot center 1px perfectly in a 16px row.

EDIT2:

But, giving it a second thought, this may not work as well. Because the brush type button height would end up being 15px, and 15px / 2 = 7px = 14 px / 2. Currently the height used to calculate the position of the icon is the client bound height, which for the last row of buttons has 3 extra pixels, so currently is 16px for the brush type button, hence a 1px icon is positioned at 16px/2 = 8px, and this is the reason you see it aligned vertically.

This is not right..this may actually work. I recall now that currently there is an -1px adjustment for the last row of buttons (or when the button has an icon), then it currently work because 16px/2 - 1px/2 = 8px and then it subtract 1px giving us 7px.
Also my calculations were wrong, they should have been: (15px - 1px)/2 = 7px which is not the same as (14px - 1px)/2 = 6px.
So, doing this

A possible solution would be to modify a bit how the button set items are displayed...

should work.

@martincapello martincapello assigned dacap and unassigned Gasparoken Nov 9, 2022
@dacap dacap added the wip label Nov 16, 2022
@dacap
Copy link
Member

dacap commented Nov 16, 2022

I'll take these changes from here. I saw some differences mainly with the width of buttons like this:

original:
Screenshot from 2022-11-16 12-50-53

with this patch:
Screenshot from 2022-11-16 12-50-55

@martincapello
Copy link
Member Author

martincapello commented Nov 17, 2022

That's right. Without this patch, the last column of buttons in a buttonset are one pixel smaller in its width. Look at the 3 buttons after the lock in the original image you posted, the last one has a width 1 pixel smaller than the other two, which by the way have the same width that when using this patch.

@dacap
Copy link
Member

dacap commented Nov 17, 2022

I'll mark the buttons that seens a bit off:

image

I'll see what I do with this PR, at the moment just merged one commit to main which is unrelated to the PR. But then I'll see if it's better to merge it and redo some work (e.g. converting buttonset to styles) or starting from main again.

@dacap
Copy link
Member

dacap commented Nov 17, 2022

Some mockups of possible solutions:

image

Still not sure which one is better. I have to design a lot of details yet.

@martincapello
Copy link
Member Author

The one at the top looks better IMO...I think that I could try to make it look like that with a minor change. I will try it and let you know.

@dacap dacap removed the wip label Nov 17, 2022
@dacap dacap assigned martincapello and unassigned dacap Nov 17, 2022
martincapello and others added 27 commits February 27, 2023 09:43
…orrectly for big brushes

As now the BrushType button has an odd number width (15px), it's
better to limit the brush size to an odd number size (9px instead of
10px). In previous versions the BrushType button had an even number
width (16px) so the 10px brush size was correctly centered.
The icon/stylus was inverted. We've also moved the icon for each state
to the theme xml (so we don't need to use setIcon() manually anymore
for this button).
…in tiles mode

It was planned to use this color for this button when it's on.
Now these buttons look more like the previous version, where the
special background color is painted to the edges. To achieve this the
"buttonset_item_normal" part has less border to fill the background
with "edit_pal_face" color in "pal_edit_button_unlock" and
"edit_tiles_mode" styles.
…nsets

We cannot use the fix from 6e2b44c as
they contain different slice borders depending on the state (and that
generated moving labels/icons in RGBA/Grayscale/Indexed buttons when
we hover the mouse on them), so we had to revert it and use a new
"buttonset_item_active" theme part to set the background of Edit
Pal/Tiles.
We have to copy all missing <style> into the new theme, so these
styles are re-loaded using colors and parts from the new
theme (instead of using the data of the default theme).
@dacap dacap merged commit 355ceac into aseprite:main Feb 28, 2023
@martincapello martincapello deleted the fix-buttonset-issues branch October 10, 2023 18:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Regression in button set icons in Canvas size dialog and Keyboard Shortcuts > Drag Value
3 participants