colomar wrote:Looks nice! Here is a small modification:




What I changed was simply to bring some randomness into the differences between the bar lenghts. I did this because in Andreas' version, it looked more like an outline of a geometric form to me than sizes of real-world objects.

And now I see that Ken did something similar. Oh well...

+1 well done

And one more deviation
Descending:


Ascending:


- more golden mean metrics =)
- solid arrow
- arrow direction indicates meaning rather than "original direction", ie. the ascending arrow is ascending and the descending arrow is - guess what - descending

On other posts (and contrasting the proposal

+1 for more randomness, though.
+1 for "full" lenght arrow as well, I think - for saying: "scrub entire list"

About bar length and direction: ascending would be to start with the smallest and end with the biggest. In a topleft -> bottomright culture, i'd expect the smallest to be on top in this case.

colomar wrote:Looks nice! Here is a small modification:




What I changed was simply to bring some randomness into the differences between the bar lenghts. I did this because in Andreas' version, it looked more like an outline of a geometric form to me than sizes of real-world objects.

And now I see that Ken did something similar. Oh well...

Great minds think alike!

Not earlier than today I've noticed (by accident as usually) the Material action icons use similar approach:


Looks like universal approach does not need A-Z or 1-2-3. And arrows improve it, really, since there are really many actions (in Calligra itself, and any app using rich text format) what use multiple horizontal lines too: 4 alignment actions, 2 indenting actions. And without arrows we're not 100% sure which action means 'ascending'.

Moreover, good that we're not using 1-2-3 as it's for a numbered list action:

BTW, Would sort-presence icons be adopted to the new concept?

andreas_k wrote:yes there was a thread about und redo and the icon was changed. the new one works good.

Ah, yes, sorry, I have just replied: viewtopic.php?f=285&t=122705&p=321949#p321949

I just cannot find the new icon in git (git@git.kde.org:breeze). Is it pushed already?

jstaniek wrote:

andreas_k wrote:yes there was a thread about und redo and the icon was changed. the new one works good.

Ah, yes, sorry, I have just replied: viewtopic.php?f=285&t=122705&p=321949#p321949

I just cannot find the new icon in git (git@git.kde.org:breeze). Is it pushed already?

No because I still have to review the icons. Also, the upstream repo of the icons isn't there, it's on GitHub.

By the way, the proposed icon:



The icons are fine, they are just too busy, there's too many lines, a simple fix away, no other icons noting an instance of a list has that many lines, except those that convey cells. Also, the symbols accompanying the icon are 90% of the time in a single position (bottom-right corner).

jstaniek wrote:BTW, Would sort-presence icons be adopted to the new concept?

No need to, then again, no list icon has that many lines, and, the icon represents the whole action of where it's used. IM software and the sorting of contacts statuses.

Uri_Herrera wrote:By the way, the proposed icon:



The icons are fine, they are just too busy, there's too many lines, a simple fix away, no other icons noting an instance of a list has that many lines, except those that convey cells.

I had the same feeling. I reduced the number of lines to four at some point which looked way less busy. Then, however, they looked a bit "lost in space" when they were only one pixel wide.

Also, the symbols accompanying the icon are 90% of the time in a single position (bottom-right corner).

Ah yes, the standard add-on position, we forgot about that.

Okay, here's a new try incorporating both points:

colomar wrote:

Uri_Herrera wrote:By the way, the proposed icon:



The icons are fine, they are just too busy, there's too many lines, a simple fix away, no other icons noting an instance of a list has that many lines, except those that convey cells.

I had the same feeling. I reduced the number of lines to four at some point which looked way less busy. Then, however, they looked a bit "lost in space" when they were only one pixel wide.

Also, the symbols accompanying the icon are 90% of the time in a single position (bottom-right corner).

Ah yes, the standard add-on position, we forgot about that.

Okay, here's a new try incorporating both points:

Thanks. BTW, would making the arrows blue be consistent with stuff such as edit-text-frame-update?

colomar wrote:

Uri_Herrera wrote:Also, the symbols accompanying the icon are 90% of the time in a single position (bottom-right corner).

Ah yes, the standard add-on position, we forgot about that.

Okay, here's a new try incorporating both points:

An arrow in the bottom right corner may "clash" with the menu indicators for toolbuttons, though
Would the right center be an acceptable/better option?

luebking wrote:

colomar wrote:

Uri_Herrera wrote:Also, the symbols accompanying the icon are 90% of the time in a single position (bottom-right corner).

Ah yes, the standard add-on position, we forgot about that.

Okay, here's a new try incorporating both points:

An arrow in the bottom right corner may "clash" with the menu indicators for toolbuttons, though
Would the right center be an acceptable/better option?

Drop-down menu indicators? On breeze-qt4 I find it not redesigned compared to oxygen, btw, for example:

Maybe left position could be better?

Anyway, the indicator could be properly positioned in the style implementation.

jstaniek wrote:Anyway, the indicator could be properly positioned in the style implementation.

I rather meant that the part-of-the-icon arrow could easily be mistaken as a dropdown menu indicator, not that it (or anything in the lower right) could be covered by the indicator (that would really be a style issue and "sort-*scending" is unlikely provided with a dropdown anyway

luebking wrote:I rather meant that the part-of-the-icon arrow could easily be mistaken as a dropdown menu indicator, not that it (or anything in the lower right) could be covered by the indicator (that would really be a style issue and "sort-*scending" is unlikely provided with a dropdown anyway

Hm, good point. That might affect other icons as well, though, because the lower-right corner is the default position for modifiers (like arrows) to icons (see the file-new or save icon, for example).

At least the breeze style could work-a-round this (the indicator can be positioned anywhere), but it's typically "somehwhat lower right side" and the HIG fellows may object deviating from that too much...

luebking wrote:At least the breeze style could work-a-round this (the indicator can be positioned anywhere), but it's typically "somehwhat lower right side" and the HIG fellows may object deviating from that too much...

Well "The HIG guys" (me being one of them) do not recommend those buttons anyway, because the are horrible from a usability perspective (since they need a long-press to open the menu, which is both unintuitive and dangerous as it executes an undesired action if one releases the mouse button too soon). The only thing we do recommend are split buttons (those which have a push button on the left side and a regular full-eight dropdown button on the right side). See the Button HIG. So those buttons which Kontact uses are violating the HIG and the usability team (both former and current members) are in agreement that they should never be used.

"me being one of them"
Hehe, just checked colomars profile for the first time

So those buttons which KMail uses are violating the HIG and the usability team (both former and current members) are in agreement that they should never be used.

The (Breeze) style can easily force another dropdown mode on polishing the icons from "QToolButton::DelayedPopup" to "QToolButton::MenuButtonPopup"

A problem could be when QToolButton is used in special contexts (LxQt taskbar etc.) where a delayed popup (activate first window or show window list) might actually make sense.
Eventually testing for a toolbar parent might help, dunno.