Ticket #479 (closed defect: invalid)
Opened 2011-05-02T18:38:27-05:00
Last modified 2011-05-20T17:06:03-05:00
Should Window, Key and Mouse Events extend DisplayEvent
| Reported by: | gharris | Owned by: | curtis |
|---|---|---|---|
| Priority: | minor | Milestone: |
|
| Component: | Display API | Version: | |
| Severity: | serious | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: |
Description (last modified by gharris)
If WinEvent extends DisplayEvent this implies that all windows are displays; this would not be the case of a text window, for instance.
Perhaps WinEvent should extend ImageJEvent.
Key and Mouse events also may not be related to a display.
Perhaps these events should not be in the display package, but rather the ui package
Change History
comment:1 Changed 2011-05-02T18:44:50-05:00 by gharris
- Description modified
- Summary changed from Should WinEvent extend DisplayEvent to Should Window, Key and Mouse Events extend DisplayEvent
comment:2 Changed 2011-05-03T14:58:31-05:00 by curtis
Do we need to publish mouse and keyboard events for things like text window editors?
Do you have other examples of situations where mouse and keyboard events are needed outside the context of a display?
I am reluctant to change this hierarchy because the current tool framework crucially relies on these events having a linked display. That is, for a given input event, it must be easy to ask "for which display?" so that the tool can react accordingly (e.g., zoom that display's image canvas).
comment:3 Changed 2011-05-20T17:06:03-05:00 by curtis
- Status changed from new to closed
- Resolution set to invalid
No comment in two weeks—closing ticket. If it comes up again we can reopen.