Simple drag and drop based on java example behaves oddly

[Owen Nelson]

Hi all,

I was looking at the basic examples shown here:

https://docs.oracle.com/javase/8/javafx/events-tutorial/drag-drop.htm

and https://docs.oracle.com/javase/8/javafx/events-tutorial/paper-doll.htm

In my ScalaFX app I'm using traits similar to:

https://gist.github.com/onelson/383bcc245511b6529681

however these nodes do not behave like those in the java examples.

In my app, the `Draggable.onDragDetected` method fires as expected, but the `Droppable.onDragOver` does not fire until I drag my mouse outside of the app window, then back in. At this point, the `Droppable.onDragOver` kicks in, and I start to see the enter/exit events fire as well. When I release the mouse to complete the drop there is log output showing 

GOT A dragExit when dndGesture is null!

This message shows up regardless of if the drop happens inside or outside the `Droppable` node. My `Droppable.onDragDropped` also never fires.

Not sure what's going on, but it feels like something might be wired up incorrectly in the ScalaFX layer.

Anyone have any experience with this?

Cheers,

Owen

[Owen Nelson]

Hey - sorry. Looks like this is a combination of jvm flags and specifically on linux.

I had added `-Dsun.awt.disablegrab=true` to my `sbt run` since debugging in IntelliJ causes X to stop accepting input after hitting a breakpoint without it!

Unfortunately it causes my weird issue.

So... unrelated to the previous, I'm wondering if anyone has any details about setting `fork in run := true` in build.sbt while still being able to use the debugger in IntelliJ. When I do this, none of my breakpoints get hit, presumably because the flags for connecting the debugger are being swallowed by sbt and not passed to the forked process.

I'd really like it if my flags passed to sbt would just pass through to the forked jvm but I'm not sure how to implement this in sbt.

[Jarek Sacha]

On 9/21/2015 8:08 PM, Owen Nelson wrote:

So... unrelated to the previous, I'm wondering if anyone has any details about setting `fork in run := true` in build.sbt while still being able to use the debugger in IntelliJ. When I do this, none of my breakpoints get hit, presumably because the flags for connecting the debugger are being swallowed by sbt and not passed to the forked process.

I'd really like it if my flags passed to sbt would just pass through to the forked jvm but I'm not sure how to implement this in sbt.

Did you try to set javaOptions, like here:

javaOptions ++= Seq(
      "-Xmx512M",
      "-Djavafx.verbose"
    )

Jarek

​

[Owen Nelson]

Jarek, 

Yes, but when intellij launches the app in debug mode, it randomly selects a port to bind on and passes it as a flag to sbt. The question is if it's possible to just pass all the flags along or if I'll have to test for each specific one I want to have carried through explicitly. I'd also hope to be able to  set whatever properties I'd want to configure my app, but these would also have to be explicitly handled I'd think.

Even still, if I set the remote debugger details in javaOptions I can connect using IntelliJ's remote debugger tools - more overhead, but ok. Unfortunately I'm still getting a lockup on X without the `-Dsun.awt.disablegrab=true` flag, which in turn breaks the drag and drop events. I'm in a bind if I want to debug and use drag and drop it seems.

Owen Nelson

--
You received this message because you are subscribed to a topic in the Google Groups "ScalaFX Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scalafx-users/VTXa9mjbc6o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scalafx-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jarek Sacha]

On 9/21/2015 9:19 PM, Owen Nelson wrote:

Yes, but when intellij launches the app in debug mode, it randomly selects a port to bind on and passes it as a flag to sbt. The question is if it's possible to just pass all the flags along or if I'll have to test for each specific one I want to have carried through explicitly. I'd also hope to be able to  set whatever properties I'd want to configure my app, but these would also have to be explicitly handled I'd think.

Even still, if I set the remote debugger details in javaOptions I can connect using IntelliJ's remote debugger tools - more overhead, but ok. Unfortunately I'm still getting a lockup on X without the `-Dsun.awt.disablegrab=true` flag, which in turn breaks the drag and drop events. I'm in a bind if I want to debug and use drag and drop it seems.

Owen,
 I think I misunderstood before, but now I am even more confused. What are you trying to do?
If you start an app in IntelliJ it is using IntelliJ's "Run/Debug Configuration" for JVM options not SBT. So you can just specify options there. I use debugger like that all the time.
I may have had problems in the past with debugging in IntelliJ when I set in SBT to disable generation of debug info: "-g:none". Are you using "-g:none"?

Jarek

[Owen Nelson]

I think you understood well enough!

Setting flags in the configuration to define/override properties is what I've been trying to do, but they are ignored (or so it seems) by the forked process.

Regardless, this is not a ScalaFX issue at all and I would recommend ignoring this thread!

Thanks again,

Owen

[invic...@gmail.com]

Owen, What is the visual effect you are after with these examples? (Although due to lack of documentation on Scalafx these examples shed light some key questions I had in understanding the difference between MouseEvents and DragEvents).

[Owen Nelson]

This thread originated back in 2015 so I'm not really sure what I'll be able to share on this. This is ancient history for me.

The drag and drop system is fundamentally different from regular mouse events as it is in part designed to handle dragging and dropping things from other applications, or even files from the desktop. It's a means of inter-app communication, and the way the message passing works is quite stringly as a result.

The "look" of a drag and drop operation is different on different platforms, but the gist is that you generate a png image representation of the things being moved, and the image floats along to follow the mouse position. Some platforms render the png as-is, some will add some alpha feathering to make it fade out around the edges.

[Bene Volent]

Gotcha, but is this the easiest way to have visual feedback as you described on drag action / translation in relation to "things" moved so that you actually see? 

As an option I am contemplating the translate-function on "things" as mouse drags them as an other path which I have seen somewhere... Not sure which is more scalable and on what basis.

[Owen Nelson]

In the application I was working on at the time, we actually ended up using 2 different tactics for dragging and moving things.

The drag and drop implementation (provided by the framework) was more trivial to setup, but had limitations (visual cue is governed by the OS, data passed between draggable and droppable is string only). 

For some cases this was sufficient. For other cases we sort of built a custom solution whereby once a drag is initiated, we hoist whatever the node is up onto an overlay layer so it can be moved freely around the application window -- essentially, the extra work here was to pluck the so-called (custom) draggable out of where it lived in the scene graph so it would not be clipped by whatever it was contained by. With this custom setup I was able to send case classes with various data between the draggable, droppable, and the underlying system we have for tracking application state as a whole.

I'm not sure this answers your question, but I think that's all I can say without stumbling into a deep dive about the architecture of the app.

[Bene Volent]

Actually, quite interesting approach the adoption of an overlay layer to create draggable situation. 

The string limitation in data exchange popped out from your narrative as risk-ahead flag when thinking of scalability. Though I am trying to mirror the interesting items, nodes, in database thus trying to survive with string based reference to key values.

Much appreciated.