Draggable pause

[killroy]

Hi,

 

Is there a way to pause a draggable? Basically I have a situation where I am dragging a card, and as I enter a certain area, I want to stop the card and start dragging a different draggable (with a crosshair). As I leave the area, I want to kill the crosshair and resume the card dragging.

 

Right now, if I .disable() the first draggable it hides the visual AND executes onDragEnd, even though the mouse has not been released yet.

 

At this stage I seem to be writing more code to work around Draggable's idiosyncrasies then it saves me from implementing stuff myself

 

There is also an undocumented "type" argument, but it does't stop onDragEnd from firing.

 

Regards,

Sven

[Diaco]

Hi killroy 

 

pls make a Codepen demo available for your questions .

 

for now pls check / try .startDrag() and .endDrag()

[killroy]

Not sure what you need an example off.

 

Just look at the srouce for Draggable.js:

 

Line: 1986

this.disable = function(type) {

 

The type is not mentioned in the docs. The next 20 or so lines mess wit ha bunch of event handlers and at line 2025, this:

_dispatchEvent(this, "dragend", "onDragEnd");

 

executes onDragEnd.

 

I'll start doing work for this as soon as you guys free some time up for me by working on my project, deal?

[Diaco]

as you can read in Draggable Doc. : 

• Rich callback system and event dispatching - you can use any of the following callbacks: onPress,onDragStart, onDrag, onDragEnd, onRelease,, onLockAxis, and onClick. Inside the callbacks,"this" refers to the Draggable instance itself, so you can easily access its "target" or bounds, etc. If you prefer event listeners instead, Draggable dispatches events too so you can do things likeyourDraggable.addEventListener("dragend", yourFunc);

 

in last release(1.17.0) , "throwupdate" and "throwcomplete" added too :

 

 

- NEW: Draggable now dispatches "throwupdate" and "throwcomplete" events (like when you add listeners like myDraggable.addEventListener("throwcomplete", function() {...}))

[OSUblake]

I'm having a hard time understanding what the problem is without seeing an example. And when you disable a draggable, why wouldn't it fire the dragend event if it's no longer in a dragging state? That could mess up other parts of your code that think the draggable is still active. If you want a mouseup event to happen, then add that to the element instead of the draggable. Just set allowEventDefault to true on your draggable.

 

As far as pausing goes, there's a lot of different ways to keep the draggable locked in place without calling .disable() or .dragEnd(). Here's how to do it in one line of code.

this.applyBounds(this.target.getBoundingClientRect());

If you need more control over the position, use liveSnap. Returning this.x and this.y will lock it in place since that's the current position.

function snapX(endValue) {
  return someFlag ? this.x : endValue;
}
function snapY(endValue) {
  return someFlag ? this.y : endValue;
}

And here's an example that does something similar to what you described. 

 

See the Pen bNJPwM by osublake (@osublake) on CodePen

[killroy]

I don't want to lock it. I want to disable it. Disabling, in English means that it no longer functions. Something that is disabled in programming traditionally does not do things such as firing event handlers.

 

Once again, I have to implement a whole framework on top of a GSAP tool to manage a second layer of events to make disable actually act like traditional .disable() methods in other frameworks. At this stage I will probably end up not needing Draggable at all as I will have re-implemented most of its functionality in the end.

[Carl]

Sorry to hear Draggable does not suit every need you have for it. Please keep us posted on the progress of your custom tool. Will it be on GitHub?

[killroy]

Kinda busy preparing for GDC Europe. If I module-ize it, it'll go here: https://github.com/killroy42/

[GreenSock]

killroy, I'm reading through this and trying to understand these "idiosyncrasies" you're talking about. Are you saying that if an element is in the middle of being dragged, and you call disable() on that, it should stop dragging but NOT fire an onDragEnd? This seems very odd to me. It's common for people to have logic wired up to an onDragEnd that would be very important to fire if/when the Draggable stops dragging. And disable() would obviously stop the dragging...so why does this strike you as idiosyncratic? 

 

You sound kinda angry, like Draggable is causing you nothing but trouble and for that I apologize. It sounds like maybe all the work we put into Draggable and all its features aren't a good fit for your project or the way you think...that's okay. We're not offended if you stop using it. We like to think it delivers a lot of very unique features and performs quite well, but clearly it's not for everybody. No worries. If there's a legitimate bug or inconsistency, I definitely want to fix it, though, so please help me understand where there's a disconnect and I'll do my best to address your concerns. 

[killroy]

Diaco, since it is different form 100% of all other APIs out there. If I disable a button, I expect no event handlers to fire for that. Are you saying that button.disable() should fire button.onClick ??? How does that make any sense?

 

I am angry since you're giving me the run around wasting a lot of my time which I don't have much off. GSAP is sold as a high-quality, professional tool, but you seem to expect me to accept a much lower level of quality. (similar with browserify support, etc). I would happily accept this if you would not sell this tool so highly. It has the technical competency to be as great as you claim, but it's not there yet. IT wouldn't be hard to get it there, but not if you just refute everything anybody says and start arguments at every turn.

 

It's more about removing non-standard behavior then adding features that would make this tool really great and of professional quality. Similar with other issues I have had with GSAP so far. Perhaps my project is a bit more complex then what GSAP is designed for, but you are selling it as a high-quality, high-power professional tool. I'm just hitting a lot of issues with your approach to API design.

 

Remember, lists of features are not what count at the professional level. Reliability, predictability and security are just as important.

 

Please note I am not using this in a traditional web environment, but in a complex game project. So I am looking at this as an application programmer (with decades of experience in using APIs and building them).

 

To re-iterate: a .disable() method should DISABLE the object. NOT fire events!!!

 

Similarly with the contextmenu hook I fell foul with before, if you see my other threads.

[Diaco]

How about something like this : 

this.vars.onDragEnd=null;  this.disable();

See the Pen rVyYVj by MAW (@MAW) on CodePen

[OSUblake]

I don't have decades of experience, nor am I trying to say you're wrong, but if buttons had a .disable() method, I would expect it to trigger something for matching on/off events. And I say that because this really isn't out of the ordinary with, at least with the libraries I've worked with. 

 

Take jQuery UI for example. It is probably the most used drag and drop library out there, and even it calls a drag end event when you disable it. But with jQuery UI, it won't disable it until you physically stop dragging it.

 

See the Pen 256b88333c5634e9f041d8efd4d3b451 by osublake (@osublake) on CodePen

[GreenSock]

I certainly don't want to give you the runaround, nor do I want to be argumentative in the least. I hope you'll indulge a little further conversation about this so that I can make sure we all understand each other, and I'd also like to ensure that GreenSock products are as "professional-grade" as possible. You and I have that goal in common, that's for sure. 

 

You said: 

Diaco, since it is different form 100% of all other APIs out there. If I disable a button, I expect no event handlers to fire for that. Are you saying that button.disable() should fire button.onClick ??? How does that make any sense?

 

 

I think that's an unfair comparison. If you disable a button, of course it shouldn't dispatch an onclick. A "click" implies a very specific sequence - a press and then release on the same element...that's enabled. If you press, then disable(), then release, the disable interrupted the sequence thus it's no longer a click. And it's intuitive that a disabled button wouldn't be able to be clicked. However, in the case we're talking about with Draggable, you press, you start dragging, then you disable WHICH ENDS THE DRAG. (Notice we don't fire an onClick). If we don't fire an onDragEnd, wouldn't that be funky? Dragging ends...but no event is fired? 

 

Keep in mind that it only fires that event the moment you disable - it's not like once you disable it keeps firing all sorts of other events thereafter.

 

If we don't fire the onDragEnd, it means you'd end up seeing an onDragStart and then....nothing. No corresponding onDragEnd. Again, it's very common practice for us to see people wiring up code that depends on these sequences of events. If we change behavior and say "we'll call onDragEnd when the drag ends...unless it ends as the result of a disable()", I imagine we'd have some pretty irate users on our hands telling us our tools aren't "professional-grade" enough, that there are frustrating quirks in our API that they have to work around, etc. 

 

See the dilemma? 

 

If there's a more professional-grade tool like this out there, please let us know. As Blake pointed out, jQuery UI's Draggable is by far the most-used one out there, and in my [utterly biased] opinion, GreenSock's Draggable runs circles around it. I could give you many, many reasons for that conclusion, but I won't go into it here - I assume you already looked at other options out there and that's why you landed on ours. 

 

That being said, we're always looking to improve things and you seem like the kind of guy who could pitch in solid ideas, especially since you're hammering on it so hard in your app. My only request is that you try to keep it constructive and not insulting. 

 

And I totally agree with you - what makes something "professional-grade" isn't just a list of features - reliability is essential. We put a lot of effort into that too. Name another tool that works as consistently as Draggable across the board in various browsers, inside nested elements with transforms, and even on SVG elements. I know of none. We have invested many hundreds of hours into finding browser inconsistencies and working around them so that Draggable "just works". But I'm confident we can make it better too.

 

I guess this response turned out to be a little more defensive than I originally intended. I admit: it was a tad offensive to have you leveraging the tools we've invested so much time and energy into and just criticizing us for "selling" them as professional-grade even though [as far as I can tell] you haven't paid a dime. You post questions in the forums and largely get polite answers from people trying to help you (again, totally for free) and your response is angry criticism of free tools...tools that have widespread industry support and a long track record of major brands singing their praises. Yeah, I guess that rubbed me the wrong way. Sorry if I veered too far into the defensive zone. I'm very sorry we have disappointed you. Hopefully we can win your confidence and you'll end up being one of the industry professionals praising the tools. 

[killroy]

Before getting technical when I have more time, I want to say a few things.

1. I'm often irate as I am under a lot of pressure to deliver a large project, quickly. My apologies.

2. You responsiveness in these forums are second to none. One of the main reasons I even bother to talk about certain things, as I actually feel you might help me out!

3. I could've sworn I had a paid license. I guess I was still testing GSAP out as I wasn't sure I'd be using it in the long run. I'll get one ASAP, as, even if I don't end up using it in the release, I definitely gained enough from it to make it worthwhile. And that also makes my "professionalism" statements unreasonable and rude

 

Cheers,

Sven

 

PS: I am currently working around this issue by completely separating the Draggable component from the items getting dragged and using it just as an event source. The dragged item is currently an empty, invisible div at [0/0].