So... You can set client mouse_pointer_icon to an icon file to change the appearance of the mouse pointer. You can also set mouse_over_pointer, mouse_drag_pointer, and mouse_drop_pointer to icons as well. But you can also set the atom variables to strings, which will use an icon-state, rather than a full icon.
Now, what would have made sense, is if icon_state was applied against the client's mouse_pointer_icon. Instead, what happens, is the icon-state form uses an icon_state from the atom's own icon.
This approach is obvious nonsense, and it's so, so, so limited compared to the way it in my opinion, should have been designed.
I propose that everything that can currently be done with mouse cursors could be done via the approach I recommend. However, quite a lot of what could be done with my approach could not be done at all easily with the existing implementation.
Imagine you have two different players. You want one to use a human hand icon, while you want the other to use a skeletal hand icon. In order for this to be possible with the current implementation, you would have to intercept every single MouseEntered()/MouseExited()/MouseDrag() function and manually change the client's mouse_pointer_icon to the specific state.
However, if it were to be using my approach, one could merely set the client's mouse_pointer_icon a single time to one of two icons with a series of named states, and set the mouse_over/mouse_drag/mouse_drop pointer variables to a state name.
There is no benefit to the existing approach. It's massively cumbersome and completely nonsensical. See for instance, the problems of using a mouse_pointer state with an object whose icon's size is greater than the tile-size. It looks terrible and makes zero sense.
It'd be really nice to see either a blanket change to this behavior, or a per-object mouse_pointer variable implemented on objects which specifies whether the mouse_pointer variables will apply against the object's own icon, or the client's pointer icon.
ID:1948934
Sep 25 2015, 11:34 am
|
|||||||
| |||||||
I'll have to read all this over more carefully, but I'm open to looking into a new way of handling the cursors. I never much liked the cursor setup either.
|
I guess I explained this carelessly.
Here's the gist of it: Currently, mouse_drag_pointer, mouse_drop_pointer, and mouse_over_pointer support the use of text strings to specify an icon_state to use as the mouse pointer. However, the icon that the atoms draw these icon_states from is the atom's own icon. Instead, I'm proposing that the icon that atoms should draw from when an icon_state is supplied is the icon file specified by client.mouse_pointer_icon. If the specified icon_state is not found in that icon file, it should fall back to "". If you want to preserve legacy (Personally, I think the legacy mode is completely asinine to begin with, so there's no reason to preserve it. All it does is encourage bad practices and heavy solutions), here's my humble solution: Add a single flag to atoms: mouse_pointer_mode = (CLIENT_POINTER|ATOM_POINTER) //default: ATOM_POINTER When mouse_pointer_mode is set to ATOM_POINTER, the pointer icon is determined by the atom's icon. When mouse_pointer_mode is set to CLIENT_POINTER, the pointer icon is determined by a state in the client's mouse_pointer_icon. |
Hrm. I kinda hate to add a new var to handle this, but I do think there's value in preserving the legacy mode. I actually think the legacy mode makes sense for some games. If you're dragging an atom, having an image of that atom might well be desirable.
Without adding a var, one option is adding a flag to appearance_flags; that's easier to do during the beta series than adding a whole new var, which typically is best done on major version changes. (I did make a rare exception and change a message format mid-beta for one of the 509 fixes, though.) I'll have to look over the cursor foo in more detail. It'd be helpful I think to refresh myself on how it currently works and how it could be different--plus I want to change the webclient code for cursors anyway. |
Unless there is some kind of reason why it is implemented the way it is, I don't see what is wrong with your suggestion! :)