GEF-improves user experience and adds assistant toolbar for graphic elements to replace palette Functions

I have been working on a GEF project over the past few days. I have read some documents on the Internet and feel that adding a tool bar for some graphic elements will greatly improve the user experience. I think Liu Gang is the only one to discuss related issues on the Internet, but I have different ideas than his implementation. My idea is to refer to the implementation of each figure tooltip and display this toolbar through shell, in this way, we don't have to work back and forth between the palette and the graphic workspace. Let's talk about my ideas and implementations. Here, we need to note that "graphic elements" refer to non-connection GEF images, such as rectanglefigure and ellipsefigure in the GEF example shape, LEDs, andgate, orgate, and so on in logic; or class diagrams, activity diagrams, and states in state machines in UML tools; for example:

The work flow item in this figure is what I call a graphical element, and the above work flow path is actually the connection between two graphic elements;

We all know that a tooltip can be set in figure. This tooltip is displayed in figure. How does GEF implement this? The following describes how tooltip is implemented.

The display of tooltip is implemented by the tooltiphelper class, which inherits from popuphelper. The figure shows that popuphelper has its own LWS and its own shell, popuphelper fully utilizes lightweight1_m and the corresponding shell to display the pop-up window. The display is implemented through the show method, and there is a control variable in this class, this variable indicates the SWT control to which the current pop-up window belongs. With this inspiration, we can implement pop-up windows in any form. If we want to, we can even display tables, buttons, and even tree structures in this window; tooltip is just a simple implementation.

To implement floating toolbar, we need to do the following:

1. This toolbar should be displayed when you hover the mouse over a graphic element;

 

2. The display of toolbar should be subject to the following restrictions:
If you move the mouse over the toolbar, it should always be displayed;
If the mouse does not enter the toolbar, the toolbar should be displayed for a certain period of time, whether it is hover or move, and then disappear;

3. If a tool is selected on the toolbar, the corresponding command should be constructed. This command can be a common command used to construct graphical elements, the connectioncommand can also be used to construct a connection between two graphic elements, but the two commands are different. The former can be executed directly, while the latter requires a target graphic element, therefore, the command execution requires two stages. First, we need to construct a start command. Then, when a target graphic element is selected, the "complete command" is actually editpolicy. graphical_node_role is the default operation defined by the role name.

4. The effect of zoom on the coordinate position;

Now, the solution is provided below.

 

1. For the first point in the above discussion, we must implement the mousemotionlistener corresponding to the graphic element, implement the following in the mousehover method:
lightweight1_m construction;
shell construction;
floating toolbar corresponds to figure construction;
display shell in a proper location; -- shell. setvisible (true);
Create a timer that controls whether the floating toolbar is displayed;
the first four steps of the above work are the standard draw2d Program . As long as you understand draw2d, there should be no problem. However, pay attention to the following points:
· a parent is often required during shell construction, how is this parent obtained? ---- We can call getviewer () in the corresponding editpart (). getcontrol () gets control and calls its getshell () method to get the parent. In fact, we dynamically track the execution of tooltiphelper and find that this is its implementation method;
· Determine the shell display position, which must be the absolute position on the screen. For this reason, I have been busy for a long time. Especially for multiple screens, if the error is not handled correctly, this error is even more obvious. The program runs on a screen on the split screen, but the shell is displayed on another screen, which is truly unpleasant. One of the simplest solutions here is to copy the implementations of popuphelper and tooltiphelper.
· timer needs to be defined as a polling situation, that is, it can be executed once every certain time; as follows. 3000 represents 3 seconds. The first 3000 represents the first execution after 3 seconds, and the second 3000 represents the execution every 3 seconds.

Timer = new timer (true );
Timer. Schedule (New timertask (){
Public void run (){
Display. getdefault (). syncexec (New thread (){
Public void run (){
Hide ();
Timer. Cancel ();
Floattingfigure = NULL;
}
});
}
}, 3000,300 0 );

 

// This method determines whether to continue displaying the tool by checking whether the mouse enters the toolbar. Pay attention to the entered variable;

Protected void hide (){
If (shell! = NULL &&! Shell. isdisposed ()&&!Entered)
Shell. setvisible (false );
}

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The above is all the work that needs to be done by the graphic elements we care about. As shown in, the mouse is invisible;

2. For tool bar, it needs to implement mouselistener and mousemotionlistener. The former completes the structure of command when a tool item is selected, and the latter completes the judgment of whether the mouse enters the tool bar; therefore, we need a Boolean variable entered to indicate whether the mouse enters the toolbar. If the mouse enters the toolbar, the value true indicates that the mouse enters the toolbar, and the value false indicates that the mouse leaves the toolbar. In this way, when the timer is executed, both determine whether entered is true. If "yes", it will continue to be displayed; otherwise, shell will be hidden;

3. For the implementation of mousemotionlistener, we can consider two situations, that is, the two types of commands mentioned above. If it is the first command, we can directly construct this method in the mousepressed method of the floating toolbar, and then call the Command Stack to execute it: getviewer().geteditdomain().getcommandstack(cmd.exe cute (command); then the corresponding command is executed immediately and can be undo; if we have used eclipse3.5 Galileo modller, we will find that the implementation of his UML2 plug-in is like this. When the mouse stays in the work zone, a toolbar is displayed, depending on the currently constructed UML diagram, the optional tools on the toolbar are also different. Once a tool is selected and clicked, the corresponding graphic elements are created; however, in the second case, connectioncommad, the processing is not that simple. We need to create a "Start Command" in the mousepressed method, and then complete the command in the mouse released method, that is, the complete command is completed and then executed;

· note that this is a tool bar mouse event, therefore, the mouse position in the "event" event is relative to the coordinate origin of the toolbar, and a conversion process is required.
· second, if your GEF Program supports zoom, when the mouse is released, the distance between the mouse movement (offset relative to the tool bar origin) should be the ratio of the mouse position to the zoom rate. Remember that the ratio is not the product.

for the implementation of assistant creation, he put the toolbar in the handle layer. For the second implementation (connection), he sets the activetool of editdomain to the tool of connection and then specifies the targeteditpart. I have not tried it yet, I don't know how to implement it, but either method can implement it. You can select different methods based on your preferences.