New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for e.getCurrentType() and e.getData(type) in "drag" and "dragover" events #9535

Open
cboulanger opened this Issue May 24, 2018 · 8 comments

Comments

Projects
None yet
3 participants
@cboulanger
Contributor

cboulanger commented May 24, 2018

According to the docs, getCurrentType() of qx.event.type.Drag "returns the type which was requested last, to be used in the droprequest listener." and getData(String type) "returns the data of the given type. Used in the drop listener." In a drag session, when the "drag" and "dragover" event handlers are called, the getCurrentType() and getData() methods do not return any data or even throw.

However, one important use case is to determine at runtime if the dragged item can be dropped on another item by checking the drag type and drag data. We therefore need to support the use of these methods in the "drag" and "dragover" event handlers.

@cboulanger cboulanger self-assigned this May 24, 2018

@oetiker

This comment has been minimized.

Member

oetiker commented May 24, 2018

I have this

            localTags.addListener('dragover', function(e) {
                // only accept rowId drops
                if (!e.supportsType('item')) {
                    e.preventDefault();
                    this.debug('prevented');
                }
            },this);
@cboulanger

This comment has been minimized.

Contributor

cboulanger commented May 24, 2018

@oetiker Thank you. However, I specifically need the drag data, not only the type. For example, I drag a number of tree nodes. They can be of different "types", and I must be able to check each of them when hovering over a potential drop target in order to determine if drop is allowed before the drop happens (which destroys the drag sessions).

@cboulanger

This comment has been minimized.

Contributor

cboulanger commented May 24, 2018

According to the documentation, the idea is to retrieve the data lazily only after the drop happens. But the problem might also have to do with the fact that the events seem to be fired by different drag session managers (different instances of qx.event.handler.DragDrop) and that they might not have access to each other's data.

@johnspackman

This comment has been minimized.

Member

johnspackman commented May 25, 2018

In my experience, although that event mechanism looks pluggable, it's really not and therefore there is only one DragDrop handler. I did try to replace it at one stage and it was really hard - I only got it working by hacking private variables, and a subsequent major release of qx broke it (I ended up not using drag & drop altogether).

What I was trying to achieve at the time was to integrate browser drag and drop with the Qooxdoo drag and drop (eg drag a widget from Qooxdoo and drop it onto an iframe (containing plain JS+HTML) and have the iframe use the "drop" to grab data); IMHO that's a pretty unusual use case, and I think it would be OK to [continue to] assume that the only thing you have to care about is the one instance of qx.event.handler.DragDrop

@cboulanger

This comment has been minimized.

Contributor

cboulanger commented May 25, 2018

Ok, thanks for clearing this up. From reading qx/event/type/Drag.js#L140, I assumed that there is a manager for each drag source (but even that wouldn't support my assumption about different managers without access to each other's data). The heart of the problem lies here: the private __validDrop and __dropTarget members are only set in the drop handler, and access to the data is prohibited in the drag events.

@cboulanger

This comment has been minimized.

Contributor

cboulanger commented May 25, 2018

BTW, I don't think that's an unusual use case - it would be enormously useful for using qx apps as desktop apps. I would be thrilled if I could drag files or selected text into my app or drag items out of my app into other desktop applications. But implementing this sounds challenging.

@cboulanger

This comment has been minimized.

Contributor

cboulanger commented May 25, 2018

(dragging files into qooxdoo app is probably not so difficult since there are certainly tons of external scripts who can deal with dropped files).

@johnspackman

This comment has been minimized.

Member

johnspackman commented May 25, 2018

it's certainly simpler to drag in, you have to add your own native DOM handlers on the element, ie not on the widget and AFAICR you have to wait until the element is created (on demand). It's not too complicated to do but ugly. I think it would be a very cool addition though!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment