Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 323984

Summary: [ipad] make scrollBar, shell, shell-border, sash, columns, slider draggable
Product: [RT] RAP Reporter: Tim Buschtoens <tbuschto>
Component: RWTAssignee: Project Inbox <rap-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: austin.riddle, tbuschto
Version: 1.4   
Target Milestone: 1.4 M7   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on: 314763    
Bug Blocks: 323032    
Attachments:
Description Flags
Fix for all necessary widgets
none
Fix for all necessary widgets and test cases none

Description Tim Buschtoens CLA 2010-08-30 11:43:49 EDT
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.
Comment 1 Austin Riddle CLA 2011-04-12 16:44:26 EDT
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.
Comment 2 Austin Riddle CLA 2011-04-12 16:46:17 EDT
grrr...just saw that I had tabs in the patch.  Will post updated with test cases.
Comment 3 Tim Buschtoens CLA 2011-04-13 05:39:09 EDT
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"?
Comment 4 Tim Buschtoens CLA 2011-04-13 05:45:01 EDT
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.
Comment 5 Austin Riddle CLA 2011-04-13 12:06:16 EDT
(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.
Comment 6 Austin Riddle CLA 2011-04-14 14:56:14 EDT
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.
Comment 7 Austin Riddle CLA 2011-04-14 16:01:14 EDT
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.
Comment 8 Tim Buschtoens CLA 2011-04-18 11:23:08 EDT
(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.
Comment 9 Austin Riddle CLA 2011-04-18 15:02:09 EDT
Fixed in CVS HEAD.