Hi @ngraham ,

I have made this separate change to discuss the redesign of the indicator arrows. The current patch changes the indicator arrow so that the toolbutton stays the same size and the indicator arrow is drawn as a two pixel arrow with one pixel margin to the border. Below is some screen shots:

Indicator arrow size 2 pixels:

I also did a test with a 3 pixel arrow size:

Finally, the before picture:

Thanks very much for this patch! I will review sometime in the next 48 hours.

Did anyone check how this patch look with other icons than those in the screenshot ?
E.g. the preview icon in dolphin, or list sorting or search icons ? Does the new arrow overlap with the said icons ?

Yes I checked, and they looked fine.

However I'm considering reverting the patch anyway because I'm un-convincing myself that it was needed at all to properly support D19311.

Reverted in c9aa535863e09bf736b1fb64c182b93530780c5d

+1

Are you +1'ing the original patch or the fact that I reverted it?

One problem I see with this is that the tops of the down arrows are a bit blurry. The way to fix that is to increase the size just enough that they fill the pixel. The bottom point should also have a MiterJoin so that it isn't a horizontal flat tip on high DPI screens.

I'm not sure how to do that in the Breeze style here; can you show me?

In D19890#577135, @ngraham wrote:

I'm not sure how to do that in the Breeze style here; can you show me?

Ehh, I'm already working on it and figuring it out as I go. I have to move points in a vector around, which is annoying since I can't see the dimentions of the area I'm drawing in. I'm not even sure where the origin is. I would assume the top left of the area I have, but I'm not certain since -4 is apparently a valid X and Y position.

All right, if you're working on it, I won't bug you. :)

Ok, so there is an overlap problem, but it's quite rare. It happens when an icon uses 100% of the available space in the bottom right corner (or left with RTL, I think).
Here I changed the stop icon in KDevelop to the icon for Codelite:

I could get around this in a number of ways that all have their downsides:

• Move the arrow to the very bottom right and make sure it's small enough that no clipping happens
  • This looks bad and makes it harder to see the arrow
• Reduce the default icon size for flat buttons
  • This is more consistent with non-flat buttons, but I like the bigger icons. They're more readable too.
• Increase the padding around flat buttons
  • I like the current padding
• Ignore the problem
  • Will look fine with most icon themes, but bad in some cases such as the one described above.

I honestly think ignoring the problem is the best solution, because it's not even really a problem in practice: the vast, overwhelming majority of icons use correct margins, especially action icons which are going to be the ones used 99.9% of the time in buttons that will get these corner arrows. The alternative is to regress something significant for a more common use case or abandon this change and live with user complaints about these buttons taking up too much space, neither of which seem very appealing.

In D19890#577204, @ndavis wrote:

Ok, so there is an overlap problem, but it's quite rare. It happens when an icon uses 100% of the available space in the bottom right corner (or left with RTL, I think).
Here I changed the stop icon in KDevelop to the icon for Codelite:

.

I could get around this in a number of ways that all have their downsides:
1/ Move the arrow to the very bottom right and make sure it's small enough that no clipping happens

• This looks bad and makes it harder to see the arrow

2/ Reduce the default icon size for flat buttons

• This is more consistent with non-flat buttons, but I like the bigger icons. They're more readable too.

3/ Increase the padding around flat buttons

• I like the current padding

4/ Ignore the problem

• Will look fine with most icon themes, but bad in some cases such as the one described above.

Confused about 2: I thought icon size was the same for flat and non flat toolbuttons (see oxygen-demo5, buttons tab)
About 3: really I think that would be bad
I too think that either 4 (ignoring the problem) or 5: don't change the current code, and dont revert the revert, is the way to go.
for 4: only a few icons would be affected, and only for toolbuttons with long popup delay (the only case for which this arrow is drawn).
These are already rather rare, and considered bad UI anyway if I remember right.

Please pretty please, do not (re) add this arrow (whether tiny or large) to instant-popup toolbuttons though.

Hugo

We could also do these things:

• In Dolphin, mimic the back/forward buttons in Firefox/Chromium/Falkon by making the right click menu provide the history instead of the normal menu for manipulating the toolbar. Inconsistent with what we normally do, but not unexpected for anyone used to web browsers. Clicking and holding is also awkward and slow for mouse and touchpad users.
• Remove the feature. It's not essential, but it is nice to have.

In D19890#577207, @ngraham wrote:

I honestly think ignoring the problem is the best solution, because it's not even really a problem in practice: the vast, overwhelming majority of icons use correct margins, especially action icons which are going to be the ones used 99.9% of the time in buttons that will get these corner arrows. The alternative is to regress something significant for a more common use case or abandon this change and live with user complaints about these buttons taking up too much space, neither of which seem very appealing.

What are correct margins though? Margins are only correct if following an HIG that requires margins. There are no universally correct margins.

In D19890#577221, @hpereiradacosta wrote:

Confused about 2: I thought icon size was the same for flat and non flat toolbuttons (see oxygen-demo5, buttons tab)

Most normal buttons use 16px icons while flat buttons on the toolbar use 22px icons.

About 3: really I think that would be bad

I also think that it would cause more trouble than it would fix.

I too think that either 4 (ignoring the problem) or 5: don't change the current code, and dont revert the revert, is the way to go.
for 4: only a few icons would be affected, and only for toolbuttons with long popup delay (the only case for which this arrow is drawn).

Are you saying not to revert the revert at all and instead write a new patch or is that just part of #5 (not changing the code)?

These are already rather rare, and considered bad UI anyway if I remember right.

Correct, I personally think we should never use long popup delay buttons for devices with touchpads or mice.

Please pretty please, do not (re) add this arrow (whether tiny or large) to instant-popup toolbuttons though.

Ok. Why do we use those arrows for pushbuttons with instant popups, but not toolbuttons?

As a side remark: did you check how it looks when one selects "text under icon" or "text beside icon" for toolbar button ?

In D19890#577833, @hpereiradacosta wrote:

As a side remark: did you check how it looks when one selects "text under icon" or "text beside icon" for toolbar button ?

There is no problem with text, even if you set the font size to something outrageous like 20pts.