frontend: Set cursor width for OBSHotkeyEdit to 0

[sebastian-s-beckmann]

Description

Removes the blinking cursor from hotkey edit fields.

While related to #12465, it doesn't depend on it (or the other way around) and they can be merged separately.

Motivation and Context

Up until OBS 31.0(?), the cursor was hidden on macOS.
This was a conscious decision back then (the removal in #12465 is due to theming changes making that particular method impossible). It's unclear why it was only done on macOS, perhaps this used to be the default on Windows already.

Removing the cursor mimics Qt's own QKeySequenceEdit, which also doesn't have a blinking cursor.
As also noted in the comment removed in #12465, the focus should already be clear. To me personally, having a cursor suggests that the keys pressed are appended instead of replacing the current ones.

How Has This Been Tested?

macOS 26
The cursor is gone now. (tested in combination with #12465 as without it, the cursor would be gone on macOS anyways)

Types of changes

• Tweak (non-breaking change to improve existing functionality)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[PatTheMav]

Wouldn't it be better to create a bespoke proxy style for the hotkey edit widget instead of having to import the header and add a dynamic_cast runtime check to figure out if the widget in question is based on OBSHotkeyEdit?

Because this code as-is will run for every widget and has to do this check for every widget and will have a non-zero return in a very small percentage of its overall calls. And that seems wasteful to me.

[sebastian-s-beckmann]

I've swapped the comparison around, that was indeed quite wasteful (now it should only be dynamic_casting when asked for the cursor width metric).

The overhead now is pretty much only this one function call, personally I didn't consider that to be huge issue and had intentionally opted against the per-widget style (to keep down code complexity). But if you want me to change that I can also do that of course.

[PatTheMav]

Refresh my memory please - how does one enable a proxy style? A quick search gave me setStyle(new OBSProxyStyle());, which is set on OBSApp. Does Qt then automatically call specific style functions like styleHint when implemented in a QProxyStyle for every widget?

[sebastian-s-beckmann]

Does Qt then automatically call specific style functions like styleHint when implemented in a QProxyStyle for every widget?

Yes.

Additionally, a style (including a proxy style) could be set on a widget, that style would then be used instead.

[PatTheMav]

Got it, yeah it still rubs me the wrong way that this change has to include the header for a specific widget and still do dynamic casting checks (which would still take place for any widget that will use a text cursor) for all widgets in the entire app...

...just for the widgets used on a single page of the Settings window.

[sebastian-s-beckmann]

I'll change it to only be set on the specific widgets then.

[PatTheMav]

I'll change it to only be set on the specific widgets then.

Much appreciated, because the code looked fine otherwise.

[sebastian-s-beckmann]

Updated this PR to have a separate OBSInvisibleCursorProxyStyle that is only set on OBSHotkeyEdit widgets.
All the widgets that are created from code (which are all but one) share one style object that is owned by the settings window, that way we don't create a new style for each widget which would be ugly too.

[PatTheMav]

Wouldn't it make more sense to either generate a single instance of each available style once and have the instances live as public properties of the singleton OBSApp instance or add a static factory function to the proxy styles themselves that returns the a singleton instance?

Singleton patterns are ugly, but in cases like these represent the reality of the running application. And at the end of the day each hotkey input widget will just use that instance to call setStyle as far as I can tell.

I dunno what the style guides for Qt are about this, it's already a bit mad that the proxy style has to be a Q_OBJECT instead of a simple static function.

[PatTheMav]

Because I just spotted the remark on #12465, I'm actually not sure whether this is the right way to do it, at least on macOS: Shortcut input fields always have a text cursor on macOS, because it's consistent for "input fields".

[sebastian-s-beckmann]

I dunno what the style guides for Qt are about this

well the guidance from Qt is to not use QWidget::setStyle at all and only have one common style across the entire app: https://doc.qt.io/qt-6/qwidget.html#setStyle. However that appears to be solely on the basis of "Make sure your style is consistent".

Because I just spotted the remark on #12465, I'm actually not sure whether this is the right way to do it, at least on macOS: Shortcut input fields always have a text cursor on macOS, because it's consistent for "input fields".

That's why this definitely needs @Warchamp7's opinion. Not having the cursor would at least be consistent with Qt's own QKeySequenceEdit (which we can't use as it doesn't allow modifiers on their own).

[PatTheMav]

I dunno what the style guides for Qt are about this

well the guidance from Qt is to not use QWidget::setStyle at all and only have one common style across the entire app: https://doc.qt.io/qt-6/qwidget.html#setStyle. However that appears to be solely on the basis of "Make sure your style is consistent".

Because I just spotted the remark on #12465, I'm actually not sure whether this is the right way to do it, at least on macOS: Shortcut input fields always have a text cursor on macOS, because it's consistent for "input fields".

That's why this definitely needs @Warchamp7's opinion. Not having the cursor would at least be consistent with Qt's own QKeySequenceEdit (which we can't use as it doesn't allow modifiers on their own).

Ok, that's a separate decision to make then. That leaves my code-style concerns over having to pass the style instance all over the place from my original comment.

[sebastian-s-beckmann]

That leaves my code-style concerns over having to pass the style instance all over the place from my original comment.

Updated to have only one instance in OBSApp.

[PatTheMav]

I had further ideas, but enough is enough.. 😂

[RytoEX]

This has a merge conflict due to #12463.

[sebastian-s-beckmann]

This has a merge conflict due to #12463.

@RytoEX Resolved.

[RytoEX]

For what it's worth, on Windows in OBS Studio 30.1.2 and 31.1.2, the hotkey edit field has a blinking cursor.