Add InputEvent icons

[MewPurPur]

Possibly finished version:

Adds a new color for the "activated" part.

Also does stuff with some other icons I came across as I was copying stuff:

• CapsuleShape2D: Draw it with a simple stroke instead of a complex path.
• JoyAxis: Remove unnecessary transform. Also, I made the middle circle bigger, I think it looks better that way - feel free to bikeshed it.
• JoyButton: Remove unnecessary transform. Draw masked circles with 2 arcs instead of 4.
• Joypad: Draw masked circles with 2 arcs instead of 4, simplify bezier curves into arcs.
• KeyboardPhysical, Shortcut: Simplify the icon and fix it up (??? it didn't have a viewbox like most other headers idk)

[Calinou]

I suggest using a different highlighted key for InputEventJoypadMotion (e.g. left button highlighted), so that it's easier to distinguish from InputEventJoypadButton at a glance.

Also, InputEventJoypadMotion is used for analog sticks and triggers, not the D-Pad. It may be better to use a circular icon, rather than a cross that resembles a D-pad.

[MewPurPur]

I know nothing about joysticks :V Well, this sounds like a better way to make the distinction.

[MewPurPur]

@Calinou

How's this?

[aaronfranke]

@MewPurPur Wouldn't it make more sense for the motion lines be on the other direction from how it was tilted?

For the other ones, here are some icon suggestions:

• InputEventMagnifyGesture: Two fingers with double-sided arrows either above or between them.
• InputEventPanGesture: A finger with lines of motion on one side. (not sure what the difference is between this and InputEventScreenDrag, but maybe the pan gesture is 2 fingers?)
• InputEventScreenDrag: A finger with lines of motion on one side. (again not sure what the difference is)
• InputEventScreenTouch: A finger with curved lines around it.
• InputEventAction: This is the tricky one. It's quite abstract since it's not connected to any real input device. Part of me wants to commandeer the CharacterBody icon and color it white, since this is closely connected with the code for performing in-game actions. Or, thinking of the code, maybe it should be an ampersand since this is expected to be used with StringNames. Or maybe an arrow pointing to a box, but that might be confused for just an icon for input in general. Maybe an arrow pointing to an ampersand →& ? Or an arrow pointing to a white CharacterBody icon?

[bruvzg]

For the other ones, here are some icon suggestions

Fingers and arrows probably won't be recognizable at this scale, so maybe something similar to Xcode gesture recognizers icons would work better?

[MewPurPur]

OK, thanks for showing this stuff! I got some ideas now, I'll try to get it done this week. And I agree with you Aaron, I'll tweak the icon to consider this.

As for InputEventAction, I'm not gonna go with ampersand, I'd like it to be language-agnostic. I think a cog would make sense, but I'm not sure.

Edit: I haven't pushed yet, but

[MewPurPur]

• Changed InputEventKey's label from A to K, as I thought it might be confused for Action.
• Added InputEventAction with a gear label to represent its configurability. (Ik it's not only for keyboard keys, but then again neither are shortcuts)
• Updated InputEventJoypadMotion icon to a more sensible direction.

I'll do the remaining 4 later, maybe in another PR if this one gets merged.

[MewPurPur]

The biggest hurdle is that I don't really know in what context the remaining 4 input events are used, namely:

• InputEventScreenDrag and InputEventScreenTouch: These two have similar names, so I suspect they are used in similar contexts. The names suggest that one is for dragging one or multiple fingers across a touchscreen, while the other seems like it's only for multitouch.
• InputEventMagnifyGesture and InputEventPanGesture: These two also have similar names, so I suspect they are used in similar contexts. The name suggests that one is for pinch-to-zoom gestures, which to my knowledge are only on touchscreens; the other suggests pan gestures on laptop touchpads.

For example, I've got this for InputEventMagnifyGesture, assuming a touchscreen:

(The SVG itself in case it's lost, since I've not pushed it yet: <svg width="16" height="16" viewBox="0 0 16 16" xmlns="http://www.w3.org/2000/svg"><path d="M3 2a1 1 0 0 1 1-1h8a1 1 0 0 1 1 1v12a1 1 0 0 1-1 1H4a1 1 0 0 1-1-1zm1 0v10.75h8V2z" fill="#e0e0e0"/><path d="M8.9-.2a1.75 1.75 0 1 1 3.3 0l-1 2.1a1.6 1.6 0 0 0 0 1.5l1 2.1a1.75 1.75 0 1 1-3.3 0l1-2.1a1.6 1.6 0 0 0 0-1.5l-1-2.1z" transform="rotate(28.5)" fill="#69c4d4"/></svg>)

But InputEventPanGesture seems to be in the same category, yet it doesn't come up in the context of touchscreens. The few people I talked with who seemed to have an idea said it was for laptops touchpads, and claim it has nothing to do with touchscreens. Moreover, InputEventScreenDrag seems similar and for touchscreen, although its documentation is dominated by it being for stylus pens... And on my personal laptop, using two fingers is just detected as if I'm using a 4-way scrollwheel, as an InputEventMouseButton... This would be awkward and confusing if I get it wrong, when it's already so awkward and confusing.

Any help? What are these? How are they normally triggered, and what do they normally do? I'm not so much asking for advice on the icons themselves. I could of course make something generic that "works", like a 4-way arrow for pan or a magnifying glass for "magnify". But I want this to be as useful to users as possible, and for this I need to know the contexts in which this stuff is used.

I'll keep trying to figure this out, but this isn't a WIP and I don't think it needs more work. The last icons can be added and tweaked later.

[Riteo]

@MewPurPur

For example, I've got this for InputEventMagnifyGesture, assuming a touchscreen

The magnify gesture is also a trackpad thing so I'd go with something a little bit more generic.

And on my personal laptop, using two fingers is just detected as if I'm using a 4-way scrollwheel, as an InputEventMouseButton... This would be awkward and confusing if I get it wrong, when it's already so awkward and confusing.

It is in a way.

The mouse button event here is AFAICT more of a compatibility thing than anything else, while InputEventPanGesture is the more specific and granular one. See InputEventMouseButton as a "click-based" scrolling while InputEventPanGesture as a pixel-based one.

This behaviour is further supported by things like #73502 which use it as a more precise branch if available.

Any help? What are these? How are they normally triggered, and what do they normally do?

I have no idea about the two weird touch ones but I looked a bit around for the panning and magnifying gestures.

They look to be implemented officially only on MacOS and Android alongside my Wayland branch.

It looks like they don't have a universal gesture, which might also be the reason why a semantic naming got chosen instead of a more descriptive one. For example, Android uses the generic scroll event through GestureDetector.SimpleOnGestureListener.onScroll():

godot/platform/android/java/lib/src/org/godotengine/godot/input/GodotGestureHandler.kt

Lines 212 to 243 in 4c677c8

	override fun onScroll(
	originEvent: MotionEvent,
	terminusEvent: MotionEvent,
	distanceX: Float,
	distanceY: Float
	): Boolean {
	if (scaleInProgress) {
	if (dragInProgress) {
	// Cancel the drag
	GodotInputHandler.handleMotionEvent(
	originEvent.source,
	MotionEvent.ACTION_CANCEL,
	originEvent.buttonState,
	originEvent.x,
	originEvent.y
	)
	dragInProgress = false
	}
	return true
	}
	dragInProgress = true
	val x = terminusEvent.x
	val y = terminusEvent.y
	if (terminusEvent.pointerCount >= 2 && panningAndScalingEnabled && !pointerCaptureInProgress) {
	GodotLib.pan(x, y, distanceX / 5f, distanceY / 5f)
	} else {
	GodotInputHandler.handleMotionEvent(terminusEvent)
	}
	return true
	}

Although I'm not really sure how and why Android should distinguish between a drag, a scroll and a pan. See: https://m2.material.io/design/interaction/gestures.html#types-of-gestures

[MewPurPur]

OK! Doned, check out the PR description for the updated icons in their context.

[Riteo]

So pretty! Love 'em!

[MewPurPur]

Yeldham wasn't happy about motion lines, I want to test out his motion blur proposal first.

[YeldhamDev]

Yeldham wasn't happy about motion lines, I want to test out his motion blur proposal first.

I guess that's my cue! 😛

Just putting my 2 cents from the dev chat, I think 3 motion lines in a 16x16 icon pollutes it too much, specially if together with other icons. I suggested that they could become a single "smear", here's a quick and dirty example with the JoypadMotion one:

[MewPurPur]

Motion blur looks better, yup. Updated the description with the new icons.

[Riteo]

Yeah this approach looks cleaner. Would it be worth to do the smear on the other icons?

[MewPurPur]

I did motion blur for InputEventMouseMotion and InputEventJoypadMotion. The other are impact lines and I think their approach is good.

[Riteo]

@MewPurPur all right, makes sense.

[YeldhamDev]

Just putting my other 2 cents, here's a suggestion I did back in the dev chat about the keypress ones:

[bruvzg]

Just putting my other 2 cents, here's a suggestion I did back in the dev chat about the keypress ones:

I would prefer the original one. Lines (or rings) going out are pretty standard for depicting a "click".

For me, this variant does not convey an idea of clicking at all, when I'm looking at it, the first thing I see is:

[Riteo]

@bruvzg yeah I agree that it doesn't convey the same thing. I can kinda see where the idea comes from but using lines specifically, other than being "standard", is itself very godotty IMO, if that makes sense.

That's also one thing I like about the icons of this PR, they mesh really well with the actually pretty iconic and almost cartoony style of Godot.

Edit: To put it in another way, other than the stuff discussed above, IMO the line risks getting a bit too... Serious? Dunno if I'm getting the point across.

[YeldhamDev]

That's also one thing I like about the icons of this PR, they mesh really well with the actually pretty iconic and almost cartoony style of Godot.

I have zero problems with the cartoonish style, it's just that I'm worried about visual pollution on icons so small. Which is why I generally try to simplify those whenever possible.

Lines (or rings) going out are pretty standard for depicting a "click".

I thought about suggesting rings, but in Godot (and in a lot of other stuff), rings represent something coming out. For example, the icons for Nodes that are connected.

[Riteo]

@YeldhamDev

it's just that I'm worried about visual pollution on icons so small

Oh yeah I can understand that.

To be completely fair I'm not overly worried about visual pollution in this case, lots of node icons are already really complex and IMO the lines are worth here.

But... I'm not really known for my graphical taste, so take this heavily with a pinch of salt :P

[YeldhamDev]

lots of node icons are already really complex

Existing stuff being bad doesn't justify ignoring those type of problems. If anything, this means we should start paying double attention for this sort of thing.

But... I'm not really known for my graphical taste, so take this heavily with a pinch of salt :P

While there are some clear rules for icon design, a lot of it depends on personal taste too, so don't worry about it. 😉

[Calinou]

Looks good to me. For reference, this is how icons look with editor scale set to 100%:

Black (OLED) theme

Light theme

[akien-mga]

Thanks!

[aidan-j-rhoden]

What is the InputEventMIDI icon for? I was unable to find such an option in the input settings (which would be really nice, btw)

[aaronfranke]

@aidan-j-rhoden It's for MIDI devices, such as a piano or guitar. Musical Instrument Digital Interface.

[aidan-j-rhoden]

Yes, I understood that part. Is the icon simply for documentation, or is it an actual option, like a physical key or joy button in the Input Map?