API proposal: drag view

Pavel Safrata pavel.safrata at oracle.com
Wed Jan 16 21:54:07 PST 2013


Yes, the terms seem too close. When a user complains about the "dragged 
image", we'll have no idea which one is it. I guess this is the reason 
why it was called DragView in FX 1. Also, in a sense, it is a view of 
the dragged content. What do others think?

Thanks,
Pavel

On 17.1.2013 2:09, steve.x.northover at oracle.com wrote:
> I support "drag image" over "drag view".  It's not a view that we are 
> dragging.  The confusion is around DragBoard.getImage() vs. 
> DragBoard.getDragImage()?
>
> Other than that, I like it.
>
> Steve
>
> On 16/01/2013 4:36 PM, Pavel Safrata wrote:
>> Looks like we've arrived back to the "getter that works only during 
>> drag detection".
>>
>> Richard proposed three properties. First, I would stay with the 
>> original "drag view", the "drag image" could really be confused with 
>> the dragged image data. Second, the DragBoard has many setters and 
>> getters, none of them being a property. Do we really want to do 
>> properties form these things? Or are the three getters, three setters 
>> and one convenience composite setter enough? It seems to be 
>> consistent with the rest of the DragBoard and I'm not sure there is a 
>> straightforward definition of the properties' behavior regarding 
>> bindings etc.
>>
>> So, currently I'd prefer:
>>
>> void setDragView(Image image, double offsetX, double offsetY)
>> void setDragView(Image image)
>> void setDragViewOffsetX(double offsetX)
>> void setDragViewOffsetY(double offsetY)
>> Image getDragView()
>> double getDragViewOffsetX()
>> double getDragViewOffsetY()
>> .. with javadoc stating clearly that all this is to be used only 
>> during drag detection and has no effect/return value anywhere else.
>>
>> Thanks,
>> Pavel
>>
>>
>> On 16.1.2013 21:48, steve.x.northover at oracle.com wrote:
>>> It returns null if called when another application has started a 
>>> drag.  If the drag is started within FX, it should probably also 
>>> return null, even though we could provide the image.  Thoughts?
>>>
>>> Steve
>>>
>>> On 16/01/2013 2:15 PM, Pavel Safrata wrote:
>>>> I've suggested this from the very beginning, just wanted to be 
>>>> sure. So, what will the getter return when another application 
>>>> starts the drag? That's the issue I'm talking about all the time..
>>>> Thanks,
>>>> Pavel
>>>>
>>>> On 16.1.2013 19:39, steve.x.northover at oracle.com wrote:
>>>>> Pavel, I had assumed that you knew this.  The drag image is 
>>>>> something that FX sets when it starts a drag, not something it can 
>>>>> get when another application starts a drag.
>>>>>
>>>>> Steve
>>>>>
>>>>> On 16/01/2013 8:28 AM, Alexey Utkin wrote:
>>>>>> On 16.01.2013 16:33, Pavel Safrata wrote:
>>>>>>> Hi Alexey,
>>>>>>> thanks for your input.
>>>>>>>
>>>>>>> On 16.1.2013 9:40, Alexey Utkin wrote:
>>>>>>>> I would like specialty emphasize here that image-for-drag is 
>>>>>>>> the same sort of transfer data
>>>>>>>> as the other parts (means that data is accessible for reading 
>>>>>>>> on the target side).
>>>>>>>
>>>>>>> Can you confirm it is always the case? If the drag starts in a 
>>>>>>> native application and continues to FX application, are the data 
>>>>>>> still accessible? On all systems?
>>>>>> I can say that image-for-drag is the same sort of transfer data 
>>>>>> as the other part in the most of cases (that is the best way for 
>>>>>> data transfer between processes),
>>>>>> but the structure of that data is not always disclosed by OS 
>>>>>> provider for native applications. For example the MS does not 
>>>>>> open the picture format, but it fixed and described in Internet 
>>>>>> by reverse engineering.
>>>>>>
>>>>>> In JavaFX drag target we can access to the image of pictured DnD 
>>>>>> only in case of JavaFX source. That is true for any OS.
>>>>>> -uta
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Pavel
>>>>>>
>>>>
>>



More information about the openjfx-dev mailing list