[Bf-taskforce25] Drag & Drop into 2.5

[Elia Sarti]

Brecht Van Lommel wrote, on 07/23/2009 02:28 PM:
> Hi,
>
> On Thu, 2009-07-23 at 12:00 +0200, Elia Sarti wrote:
>   
>> Yes but the problem is exactly this, that each operator in the end gets 
>> own context. Maybe I'm missing something but there's need for the 
>> MOUSEDROP event to have both mouse_drag and mouse_drop data. The problem 
>> is that these two types of data lie into two different space contexts, 
>> unless we store this data at some higher level (like WM), which I'm not 
>> sure is ok? This is the data retrieved from the CTX_data_drag_pointer 
>> and CTX_data_drop_pointer. We'll have to set them under C->wm. If this 
>> is fine then there's no problem.
>>     
>
> I think the MOUSEDROP should not have to call CTX_data_drag_pointer.
> That is done by the MOUSEDRAG operator, which then passes it on to the
> windowmanager, which will give it to MOUSEDROP as customdata in the
> event.
>
> Thinking of it further, I don't understand why CTX_data_drag_pointer and
> CTX_data_drop_pointer are really needed. They can be computed in the
> MOUSEDRAG/MOUSEDROP operator directly, unless there is some reason to
> have that decoupled?
>
> Brecht
Yes this is what I suggested as alternative solution in the first 
e-mail, but I was not sure it was ok? I mean MOUSEDRAG operator is modal 
and when it gets MOUSEDROP it sets custom data for MOUSEDROP and pass on 
the event which then arrives to the current space the cursor is in with 
the new custom data (which will contain the drag_pointer).
If this is ok (and doable) then we can just do it this way I guess with 
no need for CTX_ calls. One reason to have them was to make things 
reusable. This way we could have one generic function that accepts 
context and then in every editor you have a specific operator that 
determines what's the data at x, y mouse coords for that specific space. 
But I guess the generic code can just be a function that accepts two RNA 
pointers.