|
BeZilla blog - Drag'n'Drop status
[Recent Entries][Archive][Friends][Profile]
|
04:35 pm
[tqh]
[Link] |
Drag'n'Drop status
After talking to Sergei, and then going of in a completly different direction1, the backbone for all types of DnD is done. Every nsWindow (or the BView in it) now starts the dragsession on a MOUSE_ENTER, and ends it on a MOUSE_EXIT, but only when we have a dragmessage.
The thing left to do is getting and setting the appropriate data for all but Mozilla to Mozilla DnD's.
This isn't really how it's supposed to be done, but it's the best way Sergei or I have come up with so far. This ensures that the dragsession starts when you drag something in from outside or when you drag something out from the inside, which is good. The bad is that we keep some data longer than it should, and some shorter than we should.
* the dragged data stays until another drag is started (ie a new internal drag, or a drag message from the outside).
* the frame and node where an internal drag is started is lost on the first MOUSE_EXIT. We could probably save it, but it's not completly simple. Holding on to it for to long and you lock the UI, and we can't determine exactly when to release it because of our asynchronous DnD. Cloning a frame and a node, on the other hand, probably a takes a lot of memory.
1 Which Sergei and I discussed earlier and I said couldn't be done, due to some faulty test I had done. The solution which I was supposed to take, ending it on MouseUp, was hard to do because it occured before the drop was done. It could only be done when dropping outside of Mozilla, which is hard to detect. When the drop was inside it wouldn't register as the DnD had already ended.
|
|
|
bezilla
