Fallback to xcursor if failed to render hyprcursor

[SoSeDiK]

Describe your PR, what does it fix/add?

Fallback to xcursor as last resort. Should bandaid invisible cursors on broken themes.

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

-

Is it ready for merging, or does it need work?

Ready

[vaxerski]

is this a good idea though? An Xcursor theme might not be in use at all - which would result in a random ugly cursor, instead of the old one staying...?

[SoSeDiK]

This is what's already done if hyprcursor is not in use:

if (!m_pHyprcursor->valid() || !*PUSEHYPRCURSOR) {
    wlr_cursor_set_xcursor(g_pCompositor->m_sWLRCursor, m_pWLRXCursorMgr, name.c_str());
    return;
}

This simply fallsback to that if the hyprland theme couldn't get neither requested or default cursor.

[SoSeDiK]

This is an edge case when no cursor could be found at all, so the expectation is that either the fancy cursor didn't load in the first place and mouse will be invisible without this, or something went so horribly wrong that fancy cursor is not a priority.
Edit: without this change, might be the case when the fancy cursor stays, but is wrong (e.g. pointer instead of text).

The proper fix is to change/repair a broken theme, but this should help those who had invisible cursor in e.g. kitty and had to hover over e.g. Waybar for cursor to reappear.

[SoSeDiK]

hyprwm/hyprcursor#31 should fix invisible cursors too during initialization. I still think this is a good caution in case it ever breaks during runtime.

[vaxerski]

I guess it's okay since if you dont have a left_ptr your theme is cringe