[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: API proposal: drag view
From:       Richard Bair <richard.bair () oracle ! com>
Date:       2013-01-30 23:10:00
Message-ID: DAA1A586-7519-4E23-846F-87ECEB404158 () oracle ! com
[Download RAW message or body]

I think that's OK. The setDragView(image, x, y) is a little squishy, but since the \
other setters are there, OK. I couldn't think of a better name off hand.

Richard

On Jan 24, 2013, at 7:55 AM, Pavel Safrata <pavel.safrata@oracle.com> wrote:

> I'm withdrawing this latest change. We should rather be consistent with putting \
> other data on drag board which doesn't care about it. Sorry for the noise. The \
> issue is updated. Pavel
> 
> On 24.1.2013 14:23, Pavel Safrata wrote:
> > 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 startDragAndDrop). Thanks,
> > Pavel
> > 
> > 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@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@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@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@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
> > 
> 


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic