Community
Participate
Working Groups
Currently on ipad drag & drop does not work, period. SWT's drag and drop won't work at all in the foreseeable future, however all widget that have a internal drag & drop behavior could be supported. Biggest problem will be to distinguish between dragging an element and the entire document, and how/when to create a mouseout, since those can not be detected easily.
Created attachment 193094 [details] Fix for all necessary widgets Test cases coming soon. But this covers all of the widgets that need to have the touch move operation.
grrr...just saw that I had tabs in the patch. Will post updated with test cases.
Okay, a few comments on the first patch (without having tested it) - The approach seems reasonable (if it works for all cases). - I would like to "switch" the terminology: instead of checking for "cancellable" and "nonCancellable" widgets, we should look for "draggable" ones. - Since there seem to be several special cases, we would need specfic tests for all of those. (For those it should suffice to test the function currently called "isCancellableWidget"). - Combo scrollbar seems to be an issue. Wouldn't the method "basic-button -> use parent" match several cases? Might there be either a more general or a explicitly combo-specific way to solve this? - Is the outer for loop in "isCancellableWidget" really needed? It seems only to do anything for "widget.classname == key"?
Oh, one more: Though its not critical, the current code seems to check the widget on every touchmove. Perhaps we could just do it on the first one and store the result ( like "this._inDragOperation = true" until the touchend comes.
(In reply to comment #3) > - I would like to "switch" the terminology: instead of checking for > "cancellable" and "nonCancellable" widgets, we should look for "draggable" > ones. That is fine..I was just keeping with the convention you had already for _cancelMouseSession(). Doesn't make a difference to me. > - Since there seem to be several special cases, we would need specfic tests for > all of those. (For those it should suffice to test the function currently > called "isCancellableWidget"). That is the plan. > - Combo scrollbar seems to be an issue. Wouldn't the method "basic-button -> > use parent" match several cases? Might there be either a more general or a > explicitly combo-specific way to solve this? In the combo scrollbar case, the widget being dragged is a BasicButton that has the appearance scrollbar-thumb. I can test for that case instead, which is probably most the most narrow case. > > - Is the outer for loop in "isCancellableWidget" really needed? It seems only > to do anything for "widget.classname == key"? No it is not. I had a array implementation originally and then switched to the "map" I am using now, so it is a carryover that can be replaced by a simple lookup now.
Created attachment 193283 [details] Fix for all necessary widgets and test cases Tim, Let me know what you think. If it looks good I will check in.
I saw that there was some experimental api for custom-widgets in MobileWebkitSupport.js and I was wondering if to support custom-widgets we could add a method for adding a "draggable type" to the list that is already there. We could prevent sabotage by simply allowing additions.
(In reply to comment #6) > Created attachment 193283 [details] Okay, lets see. - Code: Looks good, with one objection: The formatting of the map looks nice, but sadly break with our coding conventions. - Tests: Split the one big test into several smaller and move the helper functions to the bottom of the class. - One bug i found: When zooming in the ipad cant decide whether to drag the widget or the viewport. I think calling preventDefault on the touch event should take care of that. Just check that the viewport can still be moved on non-draggable widgets. Fix those and then you can check it in from my pov. Take care not to overwrite any revent changes in CVS HEAD. Your current patch is slightly out of date. About the custom widget api: If you have a specific need and the changes are only a few simple lines i would be okay with that. If it gets more complex we would have to discuss it.
Fixed in CVS HEAD.
