Generally that was what I was looking for, thanks! I wonder how it would look with a vertical line or two between the arrows, though. Might make the concept a bit clearer?

I do agree that the 22px version is clearer with two lines in between the arrows:

To fit this into the 16px was difficult, however:

I think the arrows are not clear enough at 100% scaling and the 2px gap in the middle looks awkward.

I think your original design looked the best. I don't think having lines extend to the area between the arrows makes the meaning significantly clearer.

I was imagining vertical lines, not horizontal. A bit more like this (WARNING: exceptionally crude mockup approaching)

In D16905#360021, @ngraham wrote:

I was imagining vertical lines, not horizontal. A bit more like this (WARNING: exceptionally crude mockup approaching)

You mean sort of like the arrow on view-sort-ascending but going both ways?

In D16905#360028, @ndavis wrote:

You mean sort of like the arrow on view-sort-ascending but going both ways?

Exactly!

In D16905#360055, @trickyricky26 wrote:

I have adjusted the arrows to fit the view-sort-ascending style:

22px

16px

Very nice! I like these a lot.

However, I also noticed these can easily be changed to show ascending / descending order:

22px

16px

Maybe the new ascending and descending icons could replace the existing view-sort-ascending and view-sort-descending, while the sorting icons with alphabetic characters would be renamed to view-sort-name-ascending and view-sort-name-descending, as they represent sorting by name rather than generic sorting.

view-sort-ascending-name and view-sort-descending-name would be better for the name specific stuff. This way if our software is using view-sort-ascending-name and a user switches their theme to something that doesn't have view-sort-ascending-name, they will get view-sort-ascending instead.

So should I include the renaming of the existing icons and adding of the ascending and descending versions of these new ones in this revision? That way applications that use view-sort-ascending for alphabetical order will have it replaced, but I guess that's okay since in that case the applications weren't using the icon properly in the first place.

The old view-sort-ascending and descending icons are also available in 24px and 32px. If I rename those as well for consistency, will I need to add the new ones as view-sort-ascending and descending? Otherwise applications using view-sort-ascending will not be able to display a fitting icon.

Also should I change the fallback colors of the old SVG's to Shade Black as per the upcoming HIG change?

In D16905#360075, @trickyricky26 wrote:

So should I include the renaming of the existing icons and adding of the ascending and descending versions of these new ones in this revision? That way applications that use view-sort-ascending for alphabetical order will have it replaced, but I guess that's okay since in that case the applications weren't using the icon properly in the first place.

I don't see it hurting anything. I'd guess some apps are using it correctly and some aren't, but your new icons will still have a useful meaning that matches the situation.

The old view-sort-ascending and descending icons are also available in 24px and 32px. If I rename those as well for consistency, will I need to add the new ones as view-sort-ascending and descending? Otherwise applications using view-sort-ascending will not be able to display a fitting icon.

Yes, I would say you should also match sizes for the already existing icons. 24px is the same as 22px, but with slightly wider margins.

Also should I change the fallback colors of the old SVG's to Shade Black as per the upcoming HIG change?

I suppose so. It's hard to say because doing piecemeal changes to improve consistency also leads to more temporary inconsistency, but we have plenty of time before KF5.53.

+1 to everything @ndavis is saying. I love the new double-arrow versions! Those are just what I had in mind. :)

I made all necessary versions of these icons:

size	view-sort	view-sort-ascending	view-sort-descending
16px
22px and 24px
32px

I wasn't quite sure if I should use 2px strokes in the 32px versions, so I used 1px for now as that is more consistent with the rest.
If there are no more suggestions, I will update this revision with these icons.

In D16905#360449, @trickyricky26 wrote:

I wasn't quite sure if I should use 2px strokes in the 32px versions, so I used 1px for now as that is more consistent with the rest.
If there are no more suggestions, I will update this revision with these icons.

1px is correct. Looks good to me!

For the -descending versions, could we consider moving the arrows up so they don't obscure some of the horizontal lines? The effect is okay for the larger versions, but I think it doesn't work for the 16px version because the descending nature of the lines is lost.

This is how the set looks with the arrows above the lines in the descending versions:

size	view-sort	view-sort-ascending	view-sort-descending
16px
22px and 24px
32px

Even if the arrows are at the top instead of the bottom like the other two icons, which is a bit inconsistent, this change makes the direction of sorting clearer at 100% scaling, .

I prefer that version, thanks!

size	view-sort	view-sort-ascending	view-sort-descending
16px
22px and 24px
32px

I think this version looks best, as you said, the direction is clear enough with 22px and 32px icons and I prefer the consistency with the placement of the arrow.
The change is necessary for the 16px icon, though.

All right, let's go with that.

1. Aren't the names in reverse? view-sort-ascending shows a list in descending order
2. In view-sort-descending the items are not even sorted. Not sure how i feel about that.

@trickyricky26 I think we should stick to whatever conventions the KDE community has. I checked with Dolphin and the arrow goes up for descending and down for ascending, however the VDG makes these calls in the end.

On lists that are sorted alphabetically A-Z (i.e. ascending), the first item is at the top, the last at the bottom. That's why user interfaces show an arrow pointing down; they show the direction of item "flow".

So you're saying the direction of the arrows is consistent with the current way, and only the names for ascending and descending need to be switched, correct?

In D16905#360586, @trickyricky26 wrote:

• Fix naming of ascending and descending versions; make ascending versions less confusing; fix symlink sort-name
  
  I have flipped the naming of the ascending and descending versions to be correct. The arrow in the ascending versions is now always at the top and does not cut off lines. The symbolic link sort-name was changed from view-sort-ascending to view-sort-ascending-name

I hate to have you going back and forth, but are you (and anyone who suggested you do this) sure that this is right?

I am sure that in ascending, the lines get longer further down (representing larger file sizes etc.). The thing I am not quite sure about is the direction of the arrows.

In D16905#360524, @cfeck wrote:

On lists that are sorted alphabetically A-Z (i.e. ascending), the first item is at the top, the last at the bottom. That's why user interfaces show an arrow pointing down; they show the direction of item "flow".

According to this, on ascending (alphabetically a-z) sorted lists, the arrows points downwards to indicate the flow.
If this is correct, the new icons show the correct arrow direction, while the existing alphabetical sorting icons have this backwards.
Perhaps they need to be changed in that regard, however I think this might be beyond the scope of this revision.

Looking around the internet, quite some icons have arrows always pointing downwards, regardless of the sorting direction; I think this is the worst solution as the arrow does not provide any meaning.
The La Capitaine icons have the same alphabetic icons as we do with the arrow pointing upwards in ascending versions; their generic sorting icons have the arrow pointing downwards in ascending versions.

In D16905#360938, @trickyricky26 wrote:

I am sure that in ascending, the lines get longer further down (representing larger file sizes etc.). The thing I am not quite sure about is the direction of the arrows.

I would say make the direction of the arrows match the view-sort-*-name icons. This way existing users won't be confused.

See if yo can shorten the title down to 50 characters and if not that, see if you can get it down to below 80. It's good practice to keep the title fairly short. If you feel more detail needs to be added, you do that in the summary.

Great! That will work.

That was not supposed to be there anymore after we changed the name. I'm going to remove sort.svg

The margins on the 32px icons are different from other 32px icons. The existing ones use a 4px margin on each side.

Ok I will change that, however the graphic on the Icons HIG Page (https://hig.kde.org/_images/Breeze-icon-design-5.png) says a inner size of 28px which means 2px margins on each size.
So that graphic should be updated, or if the 4px margins only apply to action icons, that should be clearly stated in the text.
I don't recall either of them being adressed in D16848: Revamp Icon Design and Emblem pages.

In D16905#361148, @trickyricky26 wrote:

Ok I will change that, however the graphic on the Icons HIG Page (https://hig.kde.org/_images/Breeze-icon-design-5.png) says a inner size of 28px which means 2px margins on each size.
So that graphic should be updated, or if the 4px margins only apply to action icons, that should be clearly stated in the text.
I don't recall either of them being adressed in D16848: Revamp Icon Design and Emblem pages.

Yes, our HIG still needs more work. My advice is that when you notice a broad inconsistency between what the HIG says and what actually exists, look at icons similar to what you're making and copy what you can from those. The exception here is with the new icon colors because they will not have a noticable difference in existing KDE apps where the color is changed by the colorscheme anyway.