Adds `encoder` type with a circle (50% border radius) drawing style

[patricksurry]

This adds a second commit on top of the qmk_info PR which adds the circled encoder drawing style. There'd be more needed to display encoder twist actions but seems nice/easy to at least draw a circular representation.

It wasn't obvious how to make a completely independent PR since the example extends the previous one.

But if you prefer to separate in a different way, or reject the earlier PR, lmk.

[patricksurry]

a simple idea to show rotation actions might be to add optional cw, ccw (aka clockwise, counterclockwise) tags to the keymap schema. perhaps only valid for type=encoder? when present the tag values would be drawn at top left and top right respectively, paired with a simple arc arrow. any hold and shift values would be right-aligned rather than centered to minimize overlap.

i could do a quick mock if that sounds interesting.

[caksoylar]

Thanks again, I can probably handle the rebase once the other one is in.

I'd be curious to see how you envision how it would look like, especially how to fit the cw/ccw legends in with the tap as well! I haven't thought about a good way myself but I never seriously tried.

In general, I am on the fence on how best to support encoders in the keymap spec. Your proposed approach is one way, where encoder is just another key in the layer but can have additional properties. It doesn't work well if the encoder doesn't have a push button, like EC12 encoders. But I suppose most firmware will assume compatibility with both, so we might be able to assume it will always have a corresponding position on the layer.

Another approach would be to assign them in a separate encoders: field, like how firmware do it. But that has the downside of introducing a new field, and co-locating the rotation functions with the button behavior might be a good thing.

[patricksurry]

Art is not my strong suit: I was thinking of something simple. e.g. 30 deg arrow arc for each of cw and ccw if specified, along with the key text as usual. It's definitely busy if you have all of cw, ccw, tap, shifted and hold but I guess that's unlikely for most encoders, and things seem to fit if your labels are short and/or icons.

I did this by hand adding a couple of defs:

<defs>
    <marker id="arrow-head"
            viewBox="0 0 10 10" refX="0" refY="5"
            markerUnits="strokeWidth"
            markerWidth="4" markerHeight="3"
            orient="auto">
        <path d="M 0 0 L 10 5 L 0 10 z" />
    </marker>
    <!-- A rx, ry, x-axis-rotation, large-arc-flag, sweep-flag, x, y -->
    <path id="enc-cw" class="arc" d="M 0 -26 A 26 26  0  0 1  13 -22.5" marker-end="url(#arrow-head)"/>
    <path id="enc-ccw" class="arc" d="M 0 -26 A 26 26  0  0 0  -13 -22.5" marker-end="url(#arrow-head)"/>
</defs>

and style

path.arc {
    fill: none;
    stroke: #999;
    stroke-width: 2;
}
#arrow-head {
    fill: #999;
}

which are then referenced in the key like

<use xlink:href="#enc-cw"/>
<use xlink:href="#enc-ccw"/>
<text x="20" y="-18" class="key shifted">up</text>
<text x="-20" y="-18" class="key shifted">dn</text>