Bugzilla – Full Text Bug Listing
| Summary: | No busy cursor for Open on Selection | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Nick Edgar <n.a.edgar> |
| Component: | SWT | Assignee: | Steve Northover <snorthov> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P2 | CC: | akiezun, daniel_megert, grant_gayed, jed.anderson, kitlo, lynne_kues |
| Version: | 2.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 44445 | ||
|
Description
Nick Edgar
The same is for the open type hierarchy action. *** Bug 6136 has been marked as a duplicate of this bug. *** 20011219-S on linux: F3 and F4 both show the busy cursor. 20011219-S on w2k: They never show the busy cursor. However, the breakpoint in BusyIndicator.showWhile() is hit and it appears do set the busy cursors. This seems to be an SWT issue. * changed to SWT component * removed from target milestone 2.0 M2 I just tried it. The cursor doesn't change on either Motif or Windows. This is an old problem. I think this is what's happening. The problem is that cursors are defined per control and inherited when not defined. Setting a cursor in a Shell only "works" when no control in the hierarchy defines a cursor. Unfortunately, StyledText defines a cursor in order to show an i-beam. This API is modelled on X, not Windows. How should we be calling SWT to get the right result? Unfortunately, you would need to set and restore the cursor in every leaf widget in every shell. There is no API to query the cursor from a control (ie. there is no Control.getCursor()) you would need to know that StyledText defines the i-beam cursor and that this is the cursor that needs to be restored. It's not great but we are restricted by what can be implemented on X (ie. we must use XDefineCursor and XUndefineCursor to implement SWT on X and this API is quite restrictive. Also, there is no way to query the "current cursor" for a widget on X). I have some ideas how the save/restore problem can be addressed but this will require new API. In any case, the "show busy cursor while" API is currently flawed - the application needs to know which widgets define cursors in order for it to work or no widget can define a cursor. I will look again on X to see if we can do better. This is still causing people grief. See 13724. *** Bug 13724 has been marked as a duplicate of this bug. *** *** Bug 4760 has been marked as a duplicate of this bug. *** *** Bug 5544 has been marked as a duplicate of this bug. *** *** Bug 25256 has been marked as a duplicate of this bug. *** *** Bug 25256 has been marked as a duplicate of this bug. *** *** Bug 31201 has been marked as a duplicate of this bug. *** Currently no solution for this on X. Steve this is on the list of bugs to be fixed for R2.1. Can you look at this again or hand it over to Grant to investigate? I am increasing the priority to P1. Grant, as far as I know, we are restricted in our API by X Windows. Can you confirm this? Thanks. We have a solution for this but it is too risky. The current thinking is as follows. Cursors will be inherited and overridden exactly the way they are now but when a parent is disabled, the cursor in the child will no longer override the parent. On platforms where the cursor is on the server (X/GTK), this will require us to create a hidden transparent window and put it in front of the client area when a composite is disabled. This window will need to be destroyed when the composite is enabled. We have prototyped a solution but the changes are too risky for 2.1. Downgrading this PR because it's too risky. Not for 2.1. Fixed > 20040609 (It only took 3 years) |