Armory - plugin for IntelliJ IDEA
Hello dear readers of Habr! In this article I will talk about the theoretical background and the existing problems in the development of an interface for the IDE, and in the end I will offer you to get acquainted with the result of our work in the form of a plugin for the Intellij IDEA development environment.
Why we decided to create another tool for developers
For a long time, our team has developed the idea of alternative ergonomics of the interface for the development environment, which would make it easy to cope with complex and confusing projects with a large number of classes and files on board. First of all, we, as programmers, were interested in increasing the level of efficiency and satisfaction when working on tasks. This refers to the usual programming tasks like creating new classes, filling them with code, studying existing code, finding the right place to learn, navigating between different parts of the project, and the like.
In a nutshell, the main tasks that this alternative ergonomics should solve can be formulated as follows:
- Reducing the number of routine actions, such as scrolling to the right place in the code or to an element in the tree, expanding the nodes of the tree, visual search of the element in large lists and the like.
- Minimization of cognitive load. Solving programmer problems already puts a heavy load on intelligence and memory, so it would be wrong to require the developer to remember and analyze additional information. This not only reduces the level of pleasure from work, but can also significantly affect productivity.
- Reducing the number of distractions. Excess information irrelevant to the current task should, if possible, be either hidden or have less visual weight.
- Reuse of automation. If the interface involves the development of some new skill, then this skill should be used as many times as possible.
Let us dwell on each of these points in more detail.
Reduce routine activities
During the experiments, it turned out that productivity is significantly affected by the access time to the target code section. Moreover, this influence is expressed not by a linear function, as it might seem at first glance, but by some kind of parabola.
The explanation of the nonlinear dependence is likely to lie in the characteristics of short-term human memory. If the development environment does not allow you to access the desired section of code in the cherished seconds, while the short-term memory is still “alive”, then most likely the developer will be forced to switch back or “think” for some time to restore the task context in his head. Surely everyone is familiar with the situation when we finally found the same method in the same class, but completely forgot why we were looking for it at all. The positive side of this relationship between access time and work efficiency is that even a slight decrease in search time significantly affects the overall results.
The key rationalization that we propose to solve the problem of reducing access time is the use of a multiple project tree. Instead of the familiar one tree, we propose using an arbitrary number of project trees, each of which can be configured on a specific branch of the structure. This approach allows you to fine-tune the "desktop" of the project for specific needs and arrange the elements so that everything is at hand.
Reduce distractions
Not only the search time and the number of necessary movements for its implementation affect the overall cognitive load on the user. Another important factor is the congestion of the workspace with irrelevant information. Of course, it is not so simple to determine which objects are currently the main ones and which are not relevant and represent only a source of interference, especially considering the variety of ways to use the development environment. Nevertheless, to give the developer the ability to hide unnecessary seems to us a very important task.
At the code editing level, hiding all the surrounding code except the current class method showed good results. This allows you to concentrate on finalizing or studying the current method, forgetting for a while about the existence of the rest of the code in this class.
At the navigation level in the project tree, good results were obtained by hiding elements that were not relevant to the current task in the so-called visual groups . Groups, unlike folders and classes, do not affect the project structure in any way, but they allow you to quickly and painlessly create a suitable visual layout and prioritize.
In addition to hiding minor elements, it is sometimes useful to approach from exactly the other side - to highlight the important with the help of visual accents (for example, boldness, italics or underlining). Such notes allow you to catch your eye while browsing a tree branch and remember something meaningful, for which the emphasis was placed.
Automation Reuse
Sometimes even the most obvious at first glance decisions on organizing quick access to frequently used elements are doomed to failure due to the fact that the user's developed automatisms take up above the assumed simplicity. An example of this type of failure is the suggestion by Windows developers to put multimedia files in folders specifically designed for this purpose: “Pictures,” “Music,” and “Video.” Why does this work poorly? The fact is that the user will rather use the familiar and universal skill of creating a new folder and put music in it, than remember the existence of a directory specially designed for this purpose, politely created by the creators of the operating system. And this behavior will be quite rational. Learning a new way to solve a problem is always associated with an additional expenditure of time and effort, and,
Thus, when developing the interface, it would be naive to expect that all the ideas for organizing labor that we proposed would immediately find approval among users. Moreover, if we offer to learn a new skill or remember new information, this should be truly justified and this skill should be as universal as possible.
For this reason, we did not like the idea of Favorites as a separate dialogue or component. Instead, we would like each of the project trees to turn into a set of the necessary classes or packages selected by the developer for a specific purpose with a flick of the wrist. Thus, the universal skill of tuning the tree could be used repeatedly in the process. In addition, this would allow moving away from the principle of a singleglobal favorites in favor of favorites in context .
Implementations
The first development environment that implements the principles described above appeared in 1996 under the name Visual Programming Armory. At that time, C ++ was the most relevant language for us, and the future flowering of the Java era was just beginning. The development environment was a standalone-application for Windows with plug-ins support for various programming languages, including the object-relational subsystem, an add-in for modeling and other proprietary tools.
A lot of work was done and many of the ideas were implemented, but, unfortunately, the project was curtailed in 2001 due to force majeure circumstances.
Despite this, we continued to improve Armory for personal use. It is difficult to abandon a tool that allows you to speed up development at times and earn more.
Meanwhile, progress did not stand still. Autocomplete, Find Usages, navigation in the code by Ctrl + Click and various kinds of smart search are becoming the norm among popular IDEs.
In 2001 IntelliJ IDEA appeared and slowly but surely began to win the hearts of programmers. Predictive code analysis helps you find errors before compilation, and refactoring tools allow developers to quickly reorganize the source code of programs. We have to give JetBrains credit here; they did a great job of creating a complete structure of the source code elements, reflecting it in the so-called hierarchy of Psi objects . Based on this abstract model, it becomes possible to perform code inspections, code analysis, micro refactoring, and displaying the project tree.
Despite our love for this wonderful development environment (Intellij IDEA), some things didn’t quite suit us, especially given the experience gained in organizing an ergonomic workspace.
The question arose, is it possible to combine the ergonomics of the old Armory and the intelligence of IDEA? After examining the source code of the IntelliJ Platform SDK, we found out that the Open API provides access to all the key functions of the development environment, and such a combination is quite possible. The prospect of getting a convenient tool for working with all the goodies of the most advanced editor inspired us and we thought, why not share it with the developer community.
As a result of our work, a plugin for JetBrains products - Armory - appeared. The plugin is completely free for IntelliJ IDEA Community Edition and supports languages such as Java, Scala and Groovy under this platform.
How to use the Armory plugin
You can install the plugin either from the official JetBrains plugin repository , or from the Downloads page on the program website. Plugin distributions are exactly the same, the only difference is that updates appear on the site a day or two earlier. This is due to the fact that after the publication of the update in the JetBrains plugin repository, it is necessary to undergo moderation.
After installing the plugin and rebooting IDEA, the Armory tab will appear on the right (similar to the tab of the Project window in the left pane). By clicking on which the main working window of the plugin will open, containing the project trees themselves, a toolbar and a panel of information about the selected item in the tree. Like all Tool Window in IDEA, Armory window can work in several modes: Pinned, Floating, Docked. You can read more about managing Tool Window here.. By default, Docked Mode is set in conjunction with Pinned Mode. Docked mode means that the plug-in window will "bite off" the workspace of other IDE components when it opens, and not overlap them on top. Pinned mode means that the Armory window will not automatically hide when it loses input focus. Here, you might want to customize this behavior to your taste and monitor size by setting the desired combination of modes.
Now you are ready to set up your workspace. You can create new project trees by dragging a folder, package or class onto special Drop zones, as shown in the animation.
You can read about other ways to add new trees in the help for the program.
Now it’s worth mentioning separately about navigation between the project tree and the editor. The fact is that, unlike the built-in Project View component, the Armory window has a much larger horizontal size. The reason is clear - here we are dealing not with one tree, but with several at once. In this regard, the navigation algorithm in the editor is also changing. By default, Armory uses the keyboard shortcut Ctrl + Enter to navigate from the tree to the editor and vice versa . If for some reason you are used to using this combination in the editor to insert line breaks without moving the cursor (this is its default purpose in IDEA), then you can change this keyboard shortcut in the plugin settings.
If you noticed, when opening a class method from the project tree, the editor does not display the entire class, but only the code of the current method. In fact, all the code before and after the current method is collapsed by two Folding regions. In order to see the whole class, just press Escape twice while in the editor. In the plugin’s settings, you can also change this behavior, for example, instead of collapsing the surrounding code, you can choose to highlight it with the specified background color.
Note that when you navigate to the editor by Ctrl + Enter , the Armory window closes. If you have a large enough monitor and you don’t want to close the window with trees when going to the editor, then you can use the standard navigation keys for IDEA:
- Enter - Open the source code of an element without setting focus in the editor.
- F4 or double-click - Open the source code of the element with the focus in the editor.
Configure the root elements of the tree
As can be seen from the above, the Armory tree may contain a root element that points to a specific node in the project structure. Moreover, each tree may contain several such root elements, pointing to different places in the project. This is useful if we want to configure the tree as a favorite, collecting in it certain classes or packages from different corners of the source code. To add an element as root to any tree, just drag this element to a special area in the tree header, as shown in the next animation.
To add an element as a root element using the keyboard, you can press Ctrl + Up and use the arrows on the keyboard to specify the tree to which this root element should be added.
Removing root elements from the tree is also carried out by pulling it into the header area, or using the hot key Ctrl + Delete .
It is worth saying that all Armory commands are available through the Armory context menu. You can call it by pressing Ctrl + Right-click or keyboard shortcut Ctrl + Menu .
With this approach, both menus (the standard IDEA context menu and the plugin context menu) are always at hand.
Grouping
Grouping tree elements is an indispensable tool for restoring order within a class with a large number of constants and variables. In addition, it is convenient to use it to isolate some class methods, grouping them by meaning. You can group any elements of the tree, including files, folders and packages.
Such a grouping does not wag the source code in any way and is exclusively visual. Deleting a group only leads to the ungrouping of all its constituent elements. To group selected items without using the mouse, use the hot key Ctrl + Alt + Page Down . To ungroup - Ctrl + Alt + Page Up .
Sort items in a tree
The order of the elements in the tree is determined by the current sorting scheme. To change the order of elements, you can either select one of the predefined sorting schemes or create a new sorting scheme in the plugin settings. The following image shows how you can switch the sorting scheme through the button in the toolbar.
You can read about how to create new sorting schemes and edit existing ones in the help for the plugin.
Accent tree elements
As mentioned above, in addition to hiding minor elements in groups or moving them outside the tree's visibility by setting the root element, it is also sometimes useful to visually highlight important elements. At the moment, Armory supports three styles of highlighting - it is bold, italics and underline. Combinations of these are also acceptable. To isolate the elements used for conventional keystrokes editors: Ctrl + B , Ctrl + I and Ctrl + U . You can also apply style through the Armory context menu.
The picture shows the Armory context menu, and on the left is an example of how elements highlighted in different styles look.
Conclusion
In conclusion, I would like to say that all of the above techniques, after some training and addiction, give amazing results. Having at hand a “map” of the source code that remembers its state and user-defined notes “in the margins” you can very quickly recall the context of a previous work and begin to act. Saves time. Save attention and strength.
This can be compared to the fact that instead of walking around the city for hours, we suddenly gain the ability to instantly teleport simply by clicking on the desired point on the map.
We hope that this plugin will benefit you and become a reliable assistant in your work.
If you have your thoughts about what is stated in the article, you disagree with something or you have a suggestion for improving the program, please share this in the comments.
Thanks for attention.