Hi Cristian,
Here are a few comments about your patch:
1. Please try to follow the GWT team guidelines for formatting: two spaces for indentation and no tabs anywhere.
2. This patch seems to allow end-users to drag/drop an element within the canvas, using default styling for opacity of the element while it's being moved. This is nice, but it doesn't allow developers to do things that I would expect they will want to do, such as hooking up custom behavior to drag start/stop event, applying different visual styling than the default, constraining the element to different bounds, etc.
3. We've tried to avoid the use of native Javascript methods on the Raphael class itself, favoring their placement on the RaphaelJS overlay instead.
A patch more attuned to the spirit of this wrapper would expose the underlying Element.drag() method from the native Raphael library within the RaphaelJS API, along with all of the parameters that would allow a developer to hook up their own behavior as if they were calling it from native Javascript code. Note that the native Raphael drag method expects native Javascript functions as parameters, but a GWT developer should not have to deal with that, so this wrapper should act as an adapter by providing an interface that deals exclusively in terms of pure Java. For example, you can define an interface with three methods for onMove(), onStart(), and onEnd(), which you would then pass to RaphaelJS.drag() and use the JSNI notation for invoking methods on GWT objects from within native Javascript methods, to pass the three separate parameters to the underlying Element.drag() method in Raphael. Then a consumer of this class can implement that interface and respond to events however they want.
Something like that would be great and would definitely warrant inclusion. Is this something you can work on?
Geoff