unsubscribe
Akintayo Abiona Olusegun
akintayo.segun at gmail.com
Wed Jan 16 00:13:53 PST 2013
unsubscribe
On Jan 15, 2013, at 9:00 PM, openjfx-dev-request at openjdk.java.net wrote:
> Send openjfx-dev mailing list submissions to
> openjfx-dev at openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
> openjfx-dev-request at openjdk.java.net
>
> You can reach the person managing the list at
> openjfx-dev-owner at openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openjfx-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: API proposal: drag view (Pavel Safrata)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 15 Jan 2013 20:43:27 +0100
> From: Pavel Safrata <pavel.safrata at oracle.com>
> Subject: Re: API proposal: drag view
> To: steve.x.northover at oracle.com
> Cc: "openjfx-dev at openjdk.java.net" <openjfx-dev at openjdk.java.net>
> Message-ID: <50F5B15F.8000107 at oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> First of all, the DnD could have been started outside of our application
> and in this case I'm not sure it's possible for the image to appear in
> the java object somehow. Second, we don't keep the DragBoard instance in
> scenegraph. We always get one from glass, and glass gets it by
> createDragboard() call. I think currently it reuses the same instance,
> but it is not guaranteed anywhere so we should not rely on it.
>
> Anyway, the getter will sometimes work and sometimes not (unless all
> operating systems provide an access to the drag image). By the way, we
> most probably could keep the value set by user in Glass, but having
> "getter that works only during drag detection" sounds better than
> "getter that works during drag detection and sometimes also during
> dragging depending on where the gesture started".
>
> Pavel
>
> On 15.1.2013 20:03, steve.x.northover at oracle.com wrote:
>> I don't understand why it only works during drag detection. We set
>> the Java object in a field and we return that field. Do you mean that
>> setting the image outside of drag detect will not update the image
>> that is used by the operating system? I understand that this is most
>> likely a restriction.
>>
>> Steve
>>
>> On 15/01/2013 1:56 PM, Pavel Safrata wrote:
>>> Richard,
>>> you're right, this could work. And the getter (or a boolean
>>> hasDragImage()) could be used in this case. So are we OK with a
>>> getter that works only during drag detection?
>>> Thanks,
>>> Pavel
>>>
>>> On 15.1.2013 19:46, Richard Bair wrote:
>>>> I assumed the Tree / Table could override this method and configure
>>>> the drag board int he startDragAndDrop call itself?
>>>>
>>>> On Jan 15, 2013, at 10:41 AM, steve.x.northover at oracle.com wrote:
>>>>
>>>>> Got it. You need to start drag and drop before you get a drag
>>>>> board. Drag and drop is started in drag detect which takes a
>>>>> MouseEvent, not a DragEvent.
>>>>>
>>>>> How are we going to allow tree and table to provide default drag
>>>>> images?
>>>>>
>>>>> Steve
>>>>>
>>>>> On 15/01/2013 1:06 PM, Pavel Safrata wrote:
>>>>>> Hi Steve,
>>>>>> I take it that you want it only for the drag start and you are not
>>>>>> concerned about an inaccessible value during the rest of the
>>>>>> gesture (we are not always the source so we don't always set the
>>>>>> drag image). Still, how would you even access the dragboard in a
>>>>>> different node than the one that started the DnD to call the
>>>>>> getter if we provided it? I don't think we have a mechanism for
>>>>>> one node starting DnD and another node altering the dragboard.
>>>>>> Thanks,
>>>>>> Pavel
>>>>>>
>>>>>> On 15.1.2013 18:55, steve.x.northover at oracle.com wrote:
>>>>>>> Without a getter, the application has no idea whether a drag
>>>>>>> image has already been set for them. Having a setter without a
>>>>>>> getter generally makes no sense. Since we set the drag image, we
>>>>>>> can easily return the image that we set.
>>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>> On 15/01/2013 4:20 AM, Pavel Safrata wrote:
>>>>>>>> Hi Richard, Steve,
>>>>>>>>
>>>>>>>> On 14.1.2013 20:51, steve.x.northover at oracle.com wrote:
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> I'd like to see some example code where the tree and table set
>>>>>>>>> a default image as part of the implementation of these
>>>>>>>>> controls. Applications would get a reasonable image for free
>>>>>>>>> and be able to override it as necessary. Having and getter is
>>>>>>>>> necessary for this.
>>>>>>>> Is it? What will be done with it? User will get the image and
>>>>>>>> programatically check if it looks good?
>>>>>>>>
>>>>>>>> (please see my answers to Richard's comments below).
>>>>>>>>
>>>>>>>>> BTW, the last time I looked, on Windows, when you set image
>>>>>>>>> content, then you will get a drag image for free. This doesn't
>>>>>>>>> happen on the Mac. We should stop doing this on Windows.
>>>>>>>>>
>>>>>>>>> Steve
>>>>>>>>>
>>>>>>>>> On 14/01/2013 2:09 PM, Richard Bair wrote:
>>>>>>>>>> HI Pavel!
>>>>>>>>>>
>>>>>>>>>> Overall great. I don't see why you can't have a getter. The
>>>>>>>>>> only way to set the drag view is via an API we control so it
>>>>>>>>>> seems pretty easy to implement the getter as well.
>>>>>>>> No. DnD is an OS feature. You can drag data from native
>>>>>>>> applications to FX. Is it possible on all systems to find out
>>>>>>>> what did the native application use as drag image? I'm really
>>>>>>>> not sure. Anybody has the knowledge?
>>>>>>>>
>>>>>>>>>> You could either have a DragView class which encapsulates the
>>>>>>>>>> node/image and the offsetX and offsetY, or you could just
>>>>>>>>>> break it out into three properties on the DragBoard and save
>>>>>>>>>> yourself the extra class.
>>>>>>>> If we are OK with the properties having value only during
>>>>>>>> starting DnD and not during the rest of the gesture, then yes,
>>>>>>>> this could be done. But I still don't see the value.
>>>>>>>>
>>>>>>>>>> I think you should just have an image based dragImage property
>>>>>>>>>> and dragImageOffsetX and dragImageOffsetY properties. We
>>>>>>>>>> shouldn't by default put anything in as the drag image, except
>>>>>>>>>> for a few UI controls. We'll want a ListView, TreeView,
>>>>>>>>>> TableView, TreeTableView to automatically pre-populate the
>>>>>>>>>> DragBoard before the onDragDetected code is called, so that
>>>>>>>>>> those control give you a nice drag image for free but the
>>>>>>>>>> developer is free to replace it or clear it as they see fit.
>>>>>>>> I don't think this is possible with the proposed API. The
>>>>>>>> DragBoard instance doesn't exist until you start DnD in the
>>>>>>>> DRAG_DETECTED handler, so you cannot really pre-populate it.
>>>>>>>> Would it be sufficient if the controls contained
>>>>>>>> getDefaultDragImage() method that users would explicitly call?
>>>>>>>>
>>>>>>>>>> The developer could use the synchronous version of snapshot.
>>>>>>>>>> But I think either snapshot should be fixed to be transparent
>>>>>>>>>> by default instead of a white fill by default or add another
>>>>>>>>>> snapshot method which produces a transparent fill by default.
>>>>>>>> True. Kevin, how easy/hard it would be to add such snapshot method?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Pavel
>>>>>>>>
>>>>>>>>>> Basically:
>>>>>>>>>>
>>>>>>>>>> source.setOnDragDetected(new EventHandler<MouseEvent>() {
>>>>>>>>>> public void handle(MouseEvent event) {
>>>>>>>>>> DragBoard db =
>>>>>>>>>> source.startDragAndDrop(TransferMode.ANY);
>>>>>>>>>> db.setContent(?);
>>>>>>>>>> db.setDragImage(source.snapshot());
>>>>>>>>>> db.setDragImageOffsetX(event.getX());
>>>>>>>>>> db.setDragImageOffsetY(event.getY());
>>>>>>>>>> event.consume();
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Maybe also have a convenience method on DragBoard:
>>>>>>>>>>
>>>>>>>>>> db.updateDragImage(node, x, y);
>>>>>>>>>>
>>>>>>>>>> which then just calls the 3 setters as appropriate.
>>>>>>>>>>
>>>>>>>>>> Richard
>>>>>>>>>>
>>>>>>>>>> On Jan 13, 2013, at 11:59 PM, Pavel
>>>>>>>>>> Safrata<pavel.safrata at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>> this is a proposal of an API allowing to specify the image
>>>>>>>>>>> floating with mouse cursor during a drag&drop operation.
>>>>>>>>>>>
>>>>>>>>>>> Jira: http://javafx-jira.kenai.com/browse/RT-14730
>>>>>>>>>>>
>>>>>>>>>>> I propose to add two methods to DragBoard:
>>>>>>>>>>> setDragView(Image image, double offsetX, double offsetY)
>>>>>>>>>>> setDragView(Node node, double offsetX, double offsetY)
>>>>>>>>>>>
>>>>>>>>>>> The first one simply uses the given image for the drag view
>>>>>>>>>>> with the offsetX and offsetY specifying cursor position over
>>>>>>>>>>> the image. The second one renders the given node to an image
>>>>>>>>>>> and uses the result (the coordinates being in the node's
>>>>>>>>>>> local space).
>>>>>>>>>>>
>>>>>>>>>>> The typical usage will look like this:
>>>>>>>>>>> sourceNode.setOnDragDetected(new
>>>>>>>>>>> EventHandler<MouseEvent>() {
>>>>>>>>>>> public void handle(MouseEvent event) {
>>>>>>>>>>> Dragboard db =
>>>>>>>>>>> source.startDragAndDrop(TransferMode.ANY);
>>>>>>>>>>> ClipboardContent content = ...
>>>>>>>>>>> db.setContent(content);
>>>>>>>>>>> db.setDragView(sourceNode, event.getX(),
>>>>>>>>>>> event.getY()); // that's it
>>>>>>>>>>> event.consume();
>>>>>>>>>>> }
>>>>>>>>>>> });
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This API is meant for telling the operating system what
>>>>>>>>>>> visual cues to provide, I don't think it is useful (and I'm
>>>>>>>>>>> not sure it is even possible) to provide getters.
>>>>>>>>>>>
>>>>>>>>>>> There is a possibility to provide default drag view - if none
>>>>>>>>>>> of those methods is called, the default drag view would be an
>>>>>>>>>>> image of the drag gesture source. This should work nice most
>>>>>>>>>>> of the times. However, it may cause inconveniences to some
>>>>>>>>>>> existing apps - for instance a text editor node which puts
>>>>>>>>>>> the selected text on the DragBoard - after updating FX the
>>>>>>>>>>> application starts to show the entire editor in the drag
>>>>>>>>>>> view. For this reason I think the default behavior should
>>>>>>>>>>> remain unchanged.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Pavel
>>>
>
>
>
> End of openjfx-dev Digest, Vol 14, Issue 48
> *******************************************
More information about the openjfx-dev
mailing list