Ticket #88 (closed defect: fixed)
Opened 2007-03-27T13:45:08-05:00
Last modified 2007-05-02T10:53:45-05:00
Need system to scale selection areas to pixel coordinates
| Reported by: | sorber | Owned by: | sorber |
|---|---|---|---|
| Priority: | critical | Milestone: | |
| Component: | visbio | Severity: | |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: |
Description
The dimensions of the selection grid or highlighting band should be scaled according to the current zoom level, etc. of the display the user is working on (the 'active' display). Currently, OverlayObjects are unaware of such display properties since they may appear simultaneously on multiple displays, but the getSelectionGrid() method is part of OverlayObject. Here are some ideas for scaling the selection grid to the display:
- Make OverlayObjects aware of the display by passing all objects the active display at each (relevant) mouse event in each OverlayTool
- Let OverlayTool compute the selection grids of each object. I like this idea--separating the selection of the object from the object itself.
Change History
comment:3 in reply to: ↑ description Changed 2007-04-06T12:58:38-05:00 by sorber
Let OverlayTool compute the selection grids of each object. I like this idea--separating the selection of the object from the object itself.
Better yet, let OverlayTransform call a utility class that computes selection layers. The only problem with this idea is that OverlayTransform is not aware of any display. Curtis suggested
- changing getData() to accept a wrapper object including all current arguments and a display.
This might also involve
- adding a static method to each transform type that returns whether the transform type cares about changes to the displays' projection matrices, and code in TransformLink (I presume) that would call getData again if a display changes and the new static method returns true.
comment:4 Changed 2007-04-12T14:08:23-05:00 by sorber
Use the TransformLink object now provided to OverlayTransform.getData(...): lnk.getHandler().getWindow().getDisplay();
comment:5 follow-up: ↓ 8 Changed 2007-04-24T13:41:42-05:00 by sorber
Will move getSelectionGrid methods out of OverlayObject and subclasses into a utility class. OverlayTransform.getData will use this utility class to compute selection grids.
comment:7 Changed 2007-04-24T13:54:21-05:00 by sorber
Also need to scale the following attributes:
- Arrow width
- Polyline proximity circles
- Proximity threshholds for editable overlays
comment:8 in reply to: ↑ 5 Changed 2007-04-24T18:04:02-05:00 by sorber
Replying to sorber:
Will move getSelectionGrid methods out of OverlayObject and subclasses into a utility class. OverlayTransform.getData will use this utility class to compute selection grids.
Moved these methods to loci.visbio.util.OverlayUtil. Removed these and the computeGridParameters() (now computed during OverlayUtil.getSelectionLayer() if at all) methods from OverlayObject. computeGridParameters() is no longer applicable since overlays use different selection layer types.
comment:9 Changed 2007-05-02T10:53:45-05:00 by sorber
- Status changed from new to closed
- Resolution set to fixed
Completed scaling of arrow width, polyine proximity circles. Most proximity thresholds were based on pixel coordinates already, except the selection threshold in PointerTool, now scaled using OverlayUtil.getMultiplier(). Will log further bugs relating to scaling as separate, new tickets.