This was published on Multiply Nov. 4, 2008, 3:43 P.M.This segment was taken from http://72.5.124.55/docs/books/tutorial/uiswing/dnd/intro.html

Drag and Drop — Behind the Scenes

Let us say there is a user named Rollo, who is running a Java application. He wants to drag some text from a list and deposit it into a text field. (Note that the process is the same when dragging from a native application to a Java application.) In a nutshell, the drag and drop process works like this: > - Rollo has selected a row of text in the source component: the list. While holding the mouse button Rollo begins to drag the text — this initiates the drag gesture.

• When the drag begins, the list packages up the data for export and declares what source actions it supports, such as COPY, MOVE, or LINK.
• As Rollo drags the data, Swing continuously calculates the location and handles the rendering.
• If Rollo simultaneously holds the Shift and/or Control key during the drag, this user action is also part of the drag gesture. Typically, an ordinary drag requests the MOVE action. Holding the Control key while dragging requests the COPY action, and holding both Shift and Control requests the LINK action.
• Once Rollo drags the text over the bounds of a text field component, the target is continually polled to see if it will accept or reject the potential drop. As he drags, the target provides feedback by showing the drop location, perhaps an insertion cursor or a highlighted selection. In this case, the text field (the current target) allows both replacement of selected text and insertion of new text.
• When Rollo releases the mouse button, the text component inspects the declared source actions and any user action and then it chooses what it wants out of the available options. In this case, the text field chooses to insert the new text at the point of the drop.
• Finally, the text field imports the data.

While this might seem like a daunting process, Swing handles most of the work for you. The framework is designed so that you plug in the details specific to your component, and the rest “just works”.Whew! What a read!

This led me to realize that programming languages are really becoming more and more complicated. Java alone, claimed for being a very easy language (some say Python is even easier) is in fact a complicated one already, still being made complicated by the many libraries it has, especially the GUI libraries (such as AWT and Swing).

But then, I think I am missing the point. The language itself is not complicated (though the notion of being “complicated” is somewhat subjective). What I really realize is the greater degree of flexibility allowed by the language becomes more and more high as the programming language become more and more “easier”. But I think it depends again on what you want to do, hence the degree of flexibility issue again.

This is only a self-reflection; don’t bother to comment (though it is strongly encouraged to comment).

P.S. What I’m writing now is a program that will receive directories as an input and compressed files of the input’s subdirectories and/or files as an output. Not a single compressed file but compressed files equal to the number of subdirectories and/or files the input directory contains. (e.g. 1 directory with 558 subfolders will output 558 compressed version of the 558 subdirectories) This is a semestral break project (not as a school requirement but as a hobby project) and I plan to distribute it as open-source. So far, I am in the progress of writing a Linux version.

Any help with the said project will be appreciated and duly rewarded.

Comments

None.