Eclipse Community Forums: GEF » unnecessary command creations during DND

Help

Home

Home » Eclipse Projects » GEF » unnecessary command creations during DND(In the DragEditPartsTracker.java)

Show: Today's Messages :: Show Polls :: Message Navigator

unnecessary command creations during DND [message #628712]

Thu, 23 September 2010 18:27

rex

Messages: 9
Registered: September 2010

Junior Member

This is talking about GEF 3.6.

The job of DragEditPartsTracker is to support REQ_CLONE (a copy), REQ_MOVE, and REQ_ADD. Let's discuss how it handles mouse activities.

When a DragEditPartsTracker instance is in place, it means a mouse down has already been performed and a drag started. It then monitors mouse moves (during DND) and mouse up that will end the drag.

The method handleDragInProcess() is called for every mouse move and it in turns call setCurrentCommand(getCommand()), which I think is inappropriate. Because you do not need a command until the end of drag e.g. a mouse up.

Since every call to getCommand() will result in a new instance of a command, it is very unnecessary to me.

I would like to suggest to move the line of setCurrentCommand(getCommand()) to method handleButtonUp() right before the method performDrag().

I tried it on my machine, it works well for move/clone/resize commands. If you know a bigger picture of why this class and methods mentioned above must operate in the way it is right now. I would like to hear from you.

Thank you!

Report message to a moderator

Re: unnecessary command creations during DND [message #628752 is a reply to message #628712]

Thu, 23 September 2010 23:25

Jens von Pilgrim

Messages: 313
Registered: July 2009

Senior Member

On 23.09.10 20:28, rex wrote:
> The method handleDragInProcess() is called for every mouse move and it
> in turns call setCurrentCommand(getCommand()), which I think is
> inappropriate. Because you do not need a command until the end of drag
> e.g. a mouse up.

I haven't looked at the DnD processing in detail, but Commands are
always created when the mouse moves, e.g. in case of creation processes.

> Since every call to getCommand() will result in a new instance of a
> command, it is very unnecessary to me.

Actually it is necessary in order to give user feedback, e.g., by
changing the mouse cursor. This way, the user can easily see, e.g, if an
object can be dropped (or created or whatever) at the current position.

Cheers,

Jens

Report message to a moderator

Re: unnecessary command creations during DND [message #628755 is a reply to message #628752]

Fri, 24 September 2010 00:02

rex

Messages: 9
Registered: September 2010

Junior Member

Jens von Pilgrim wrote on Thu, 23 September 2010 16:25

Hi Jens,

I agree with you we need real time feedbacks (e.g. visual effects) with every mouse moves. On the other hand, by definition, a command is a piece of change to be applied to model. My theory is that a command is only needed when your mouse/key gesture is eventually finished.

In the case of DragEditPartTracker, method handleButtonUp() is the best place to create and execute a command. Actually all command instances created during mouse moves are wasted.

I looked into another tracker SimpleDragTracker, it seems have the same problem too. Maybe we should exam all tracker classes.

Thanks,
Rex

Report message to a moderator

Re: unnecessary command creations during DND [message #628823 is a reply to message #628755]

Fri, 24 September 2010 10:12

Jens von Pilgrim

Messages: 313
Registered: July 2009

Senior Member

> I agree with you we need real time feedbacks (e.g. visual effects) with
> every mouse moves. On the other hand, by definition, a command is a
> piece of change to be applied to model. My theory is that a command is
> only needed when your mouse/key gesture is eventually finished.
>
> In the case of DragEditPartTracker, method handleButtonUp() is the best
> place to create and execute a command. Actually all command instances
> created during mouse moves are wasted.

Well, almost all command instances are wasted, indeed. However, a
command object usually has only very view fields, and its creation is
not that expensive. The whole request processing in GEF relies on
Commands. If an edit part returns no command (i.e. all its policies
return null instead of a command object), a request cannot be processed
by an edit part. If you won't use commands, and instead return a boolean
or something like that in order to indicate whether an edit part can
handle a request, than you would have to call the edit part again in
order to actually create the command, which is then also executed. This
would require additional methods in edit parts and policies, which
wouldn't make things easier. A command is a very small object, so it is
no problem creating it.

So, the command is used twofold: firstly for indicating whether a
request can be processed, secondly the command is executed if required.
And if you have a look at some command classes: they all have a very
limited amount of (initially) set fields. Creating a command and
executing it (which may be indeed more complicated) are completely
different things! And a command is not automatically "applied to model".
It can be executed, must not necessarily! And this is the trick here!

Cheers,

Jens

Report message to a moderator