API proposal: drag view

Pavel Safrata pavel.safrata at oracle.com
Thu Jan 24 05:23:21 PST 2013

Hi Richard,
done. I did a slight modification: in case the methods are called 
outside of drag detection, they throw IllegalStateException 
(consistently with the other methods restricted to drag detection as 

On 23.1.2013 19:43, Richard Bair wrote:
> That's fine with me.
> Can you update the issue with the latest proposal?
> Richard
> On Jan 16, 2013, at 9:54 PM, Pavel Safrata <pavel.safrata at oracle.com> wrote:
>> 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