Community
Participate
Working Groups
When dragging view's within a perspective, it would be great to be able to see the view contents (or an alpha blended version of them) as opposed to the current Tracker. Especially for building RCP applications that have customizable layouts.
Brian, we're unlikely to be able to do this in the 3.x stream but I'll add it to my 4.0 pool (where 'cool' really counts!! ;-). Dragging the actual view will require a new type of 'floating' PartPane since we can't rely on any sort of bit capture to work correctly; the view could be partially overlapped and/or dynamic (like the Progress View...).
Related to this (don't know if there's an existing bug on this yet), dragging a view hangs the rest of the UI in my RCP application. If the view contents were displayed as mentioned in #1, would the display be static, or would the UI still be updating while being dragged? I have a view that dynamically displays data received from various sources and sometimes the data is coming in at a high rate and currently if I drag the view, the UI hangs until I drop it at which point the view is now behind in displaying the data it was receiving while being dragged around and must catch up.
DaSH, thanks for the input. This ('dynamic' views) will make a good test case for any implementation involving showing views in different ways. Right now the issue is that the 'internal' DnD (which we use to move views...) captures the mouse and spins if event loop itself. I've just tried this by doing a full re-build of my WS and dragging a view while it was running. In this case the ProgressBar doesn't update until I finish the drag (the little green 'in running' indicator keeps cycling though, interesting). If we want to drag 'live' view's around we'll have to ensure that the drag code shares the processing with everything else. While I'm not sure I have a suspicion that what we aren't doing (and should) is processing the 'asynchExec' queue inside the drag loop...
Removing outdated target milestone.
