TotalCross / TotalCross/totalcross
Review SDL mouse event timestamp passed as modifier flags
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 227
- Forks
- 42
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 11
Description
Summary
handleMouseEvent in TotalCrossVM/src/event/linux/event_c.h computes a getTimeStamp() value and passes it as the last argument to postEvent for SDL mouse events.
However, the last postEvent argument is mods, not an event timestamp:
void postEvent(
Context currentContext,
TotalCrossUiEvent type,
int32 key,
int32 x,
int32 y,
int32 mods);
postEvent already generates the event timestamp internally when it calls the Java _postEvent method. Before posting, it also calls keyGetPortableModifiers(mods). Consequently, the lower bits of the elapsed-time value supplied by handleMouseEvent may be interpreted as keyboard modifier flags.
Current code:
void handleMouseEvent(SDL_Event event) {
int32 timestamp = getTimeStamp();
...
postEvent(mainContext, PENEVENT_PEN_DOWN, 0,
event.button.x, event.button.y, timestamp);
}
Relevant internal behavior:
executeMethod(currentContext, _postEvent, mainClass,
(int32)type, key, x, y,
keyGetPortableModifiers(mods), getTimeStamp());
Why this is being deferred
The runtime timing APIs are being redesigned to separate monotonic time from Unix wall-clock time and to remove the legacy native getTimeStamp helper. This SDL call site should not be mechanically migrated to the new monotonic function because its apparent timestamp value is passed through the modifier parameter. It needs a focused event-semantics review instead.
Questions to resolve
- Should SDL mouse events pass
-1,0, or modifier state derived from SDL APIs asmods? - Should
handleMouseEventpreserve mouse or keyboard modifier state from the original SDL event? - Does the
event.button.buttonaccess remain valid forSDL_MOUSEMOTION, or should the event union member be selected by event type? - Are there tests that assert modifier values and timestamps for SDL mouse down, up, drag, and move events?
Expected outcome
- Remove the misleading local
timestampvariable. - Pass intentional modifier data to
postEvent. - Keep event timestamps generated exactly once inside
postEvent, unless the event API is deliberately redesigned. - Add focused tests for SDL mouse event type, coordinates, modifier flags, and timestamp ordering.
Acceptance criteria
- Mouse down, mouse up, drag, and move events carry the expected modifier flags.
- Their Java-side
Event.timeStampvalues are generated by the event posting path and remain monotonic. - No elapsed-time value is interpreted as modifier bits.
- The SDL event union is accessed through members valid for each handled event type.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in TotalCrossVM/src/event/linux/event_c.h at handleMouseEvent and compare its SDL event handling with postEvent's modifier and timestamp path. Locate existing SDL or event tests, then verify mouse down, up, drag, and move behavior, including event-union access, modifier flags, coordinates, and monotonic Java-side timestamps. Done means no timestamp is passed as mods and the acceptance criteria are covered by focused tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, linux
- Domain
- desktop, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100