Unfortunately the presentations do not include video for the demos, so you won’t be able to see the Remote Run and Delayed Commit functionality in action.

The plugin is currently compatible only with IDEA 5.1.x. Demetra compatibility will be provided in the next build of Demetra.

Pythonid was developed by me and Keith Lea. This is not an official JetBrains product; I work on the plugin only in my spare time. The plugin is open-source, and the source code is available at http://pythonid.dev.java.net. People willing to contribute to the plugin development are very much welcome; if you're interested, please contact me to discuss the details.

Before JavaOne, we gave presentations on our products at the Google office. I spoke about Team Server, and Mike Aizatsky demonstrated the HTML, CSS and JavaScript features of IntelliJ IDEA. Our talk was recorded, and the recording is currently available on Google Video.

Enjoy watching, and if you have any comments, feel free to leave them here.

As for JGoodies Forms, there is one kind of support that we can provide with very little effort. We can make it possible to generate source code and bytecode which uses the JGoodies Forms layout manager without making any additions to the design-time experience. (We already support GridBagLayout in a similar way – if you’re curious, look at GridBagLayoutCodeGenerator and GridBagConverter classes in redist\src\src_javac2.zip.) The only issue is that I don’t quite understand what problem it would solve.

Now, of course, JGoodies Forms has a number of features which are not supported by our designer (for example, row/column groups). And if what you really need are these additional features, it will probably make the most sense to support them in our own layout manager, in addition to providing JGoodies Forms support.

So, my request is: if you’re interested in JGoodies Forms support, could you please leave a comment here and describe what exactly you need from such a support?

And in the meantime, here’s a small preview of a different new feature that I’ve been working on today:

We continued to receive feedback on this issue during our work on the version 6.0, and finally we’ve come to a solution for this issue that doesn’t break any of our design principles. The solution works equally well for source code generation and bytecode instrumentation, and does not involve storing source code in the form files.

The solution is in fact very simple. Every component now has a property called “Custom Create”:

If the property is set for a component, the UI Designer does not generate the constructor call for this component. Instead, if at least one component has the “Custom Create” flag set, IntelliJ IDEA creates a special method called createUIComponents(), and inserts a call to this method in the beginning of the generated UI initialization method. The code of createUIComponents() is written by the user, and the user needs to assign values to fields bound to all custom-created components. (A component with the “Custom Create” flag must be bound to a field.)

In design time, components which do not have a public default constructor are represented by instances of superclasses which do have such a constructor, or by JPanel instances if there is no such superclass. The property list shown in the inspector is still taken from the exact class of the component, so you’ll be able to set the values for all properties (although the values of properties that don’t exist in the superclass will not affect the design-time appearance of the component).

A related change that also makes the UI Designer more flexible is a small modification to the source code generation algorithm. Now, if any of the user-written constructors of a class bound to a form calls the UI initialization method explicitly, IntelliJ IDEA no longer generate a class initializer block with a call to the UI initialization method. This allows to initialize the UI at a somewhat later time (for example, after values of the parameters passed to the bound class constructor have been processed).

This solution will become available in the next EAP build of Demetra. In the meantime, feel free to leave feedback here, particularly if the solution does not cover some of the scenarios found in your projects.

Form and Code Separation. This decision hasn’t changed since the initial version of the UI Designer. The principle is simple: Java code is never stored in .form files and never edited in the UI Designer. The Java editor  in IntelliJ IDEA is a much better environment for editing Java code than anything which could be embedded in the UI Designer dialogs, and having all the code in one place (the Java class file) makes it easier to understand and causes much less surprises.

All of this doesn’t preclude the possibility to navigate between code and form files. The possibility to jump from a field declaration to the corresponding UI component in the form and back has been present since the initial version of the UI Designer. Version 6.0 adds another navigation feature: “Navigate to Listener”, allowing to navigate from a component in the form to the event listener classes attached to the component. Here’s a screenshot showing how this works:

One-Step Layout. This is probably the biggest change to the UI Designer made in version 6.0 – or, at least, the most controversial one.

In previous versions of the UI Designer, building the form layout was a two-step process. First, the user placed components on a form with no layout, with arbitrary positions and sizes. Then, the user selected all or some of the components and invoked one of the layout actions (“Lay Out Horizonally”, “Lay Out Vertically”, “Lay Out in a Grid”). The UI Designer tried to guess the grid structure needed to lay out the components similarly to how the user placed them, and created the grid.

We feel that this approach has a number of problems. First of all, it is confusing for new users: almost no other UI design tools (except for Qt Designer, on which this design was based) have such a two-step process, and there was very little instruction telling the users what they were supposed to do. Second, this procedure inherently lacks feedback. The grid structure is always more limited than the free-form layout, so the layout created by the user is not reproduced exactly. Also, the algorithm is not always predictable, so the user often has to undo the layout process, try to tweak the placement of the components and retry the layout, hoping that the second time will produce better results.

Thus, we have dropped the layout actions in the new version. Now, a grid structure is always created around components placed on a form, and the actions for adding components have been modified so that they can insert grid rows and columns if required. Layout modifications can also be done by dragging components within the grid, and do not require breaking and rebuilding the layout, as was often the case in previous versions.

In fact, the current layout editing experience is considered to be work in progress, and we expect to continue tweaking and improving it in the future EAP builds, to ensure that the behavior always matches user expectations and all necessary operations are easy to accomplish.

UI Inspections. Inspections are heavily used in many areas of IntelliJ IDEA, and we decided to make use of them in the UI Designer as well. Designing forms involves a number of routine operations (assigning mnemonics, placing components in JScrollPanes, grouping radio buttons, linking labels to controls and so on). Of course, we found it desirable to automate the operations. However, rather than doing things fully automatically or popping up modal dialogs asking the user for confirmation, we linked them to the well-used lightbulb and Alt-Enter keyboard shortcut.

For example, here’s how the inspection for assigning mnemonics works:

The designer automatically suggests choices for the text with mnemonics, ensuring that the suggested variants do not overlap with mnemonics of other controls in the form:

Well, looks like I’ve got the major decisions covered, so the following posts will focus on specific new features implemented in the IntelliJ IDEA 6.0 UI Designer. As usual, don’t hesitate to send your feedback – and thanks to everyone who has left comments on previous posts in this blog. :-)

Runtime Requirement. In previous versions of IntelliJ IDEA, the code generated by the UI Designer always required the use of a runtime library (forms_rt.jar), which contains a custom layout manager and a number of additional utility functions. This became a major obstacle for many users who didn’t want to introduce extra dependencies in their applications – some of them rejected the UI Designer completely when they learned of the runtime requirement. The problem was made worse by the fact that, until version 5.0, the license for the source code of forms_rt.jar was not clearly defined, which made it hard to use in open-source projects. Now it’s clearly licensed under the Apache license, but other problems with the runtime remained.

In the new version, we’ve made it possible to generate code which uses only the standard Swing layout managers and does not require any additional runtime. We’ve kept the runtime for those who need full compatibility with forms created in earlier versions of IntelliJ IDEA, and we even added a few new features to our layout manager, but you can easily opt out of its use if you don’t need that.

Bytecode Instrumentation. A related issue is the way code is generated by the UI Designer. We decided to keep both of the options available in version 5.0: source code generation and bytecode instrumentation. We consider bytecode instrumentation the best option for projects which are developed using only IntelliJ IDEA, as it’s cleaner (the generated code is never visible to users) and provides better build performance. For other projects, where multiple IDEs are used or when the entire source code of the application needs to be provided to the customer, source code generation can be used.

In version 6.0, we’ve rewritten the bytecode generator to use ASM instead of BCEL, as it provides better performance and better support for new versions of the .class file format. Also, we plan to improve the source code generator so that it produces cleaner and more readable code.

Form Migration. Using forms created in IDEA with other IDEs is one side of the problem – another is importing into IDEA forms created in other IDEs. Before version 6.0, we didn’t provide any solution to this problem – you always had to draw forms from scratch.

There are a number of possibilities to solving this. It’s possible to import the XML form definition files created by specific designers (for example, JFormDesigner .jfd or NetBeans .form). Another option is to reverse-engineer the Java source code used to create the form (either generated or hand-written) and to extract the information about the component layout and properties (this is the approach used by Eclipse Visual Editor).

However, we decided that importing only specific XML form file formats would be too restricted, and creating a general reverse engineering engine that works in a sufficiently broad number of cases (including hand-written code) is too risky and resource-consuming. Instead, we have implemented the possibility to import form files from the most simple and universal structure of the form data: the run-time tree of Swing components. We inject our component, called Swing Inspector, in the Java virtual machine where the user application runs. When the user presses a button or a keyboard shortcut, a window showing the entire hierarchy of Swing components is displayed. The user can choose any part of that tree (the contents of an entire frame or dialog, a panel containing some of the components, and so on), and that part is saved as a .form file. The entire component layout structure and most of the component properties are saved. Later, the user can open the .form file in UI Designer and modify it as required.

The initial version of the Swing Inspector will be included in the next EAP build of IntelliJ IDEA. Here’s a screenshot showing how it works:

Well, that’s enough for today – stay tuned for more design decisions next week. And don’t forget to send feedback! :-)

I’m very eager to receive any kind of feedback, positive or negative, on our work and its underlying decisions. Don’t hesitate to leave comments here or come to the forum or newsgroup. It’s still not too late for us to make major and significant changes in the product. And of course, the version of the UI Designer available in recent EAP builds is not final, and we have a lot of work remaining in our plans, and some cool feature ideas too. And if the current EAP version falls short of accomplishing some of the goals, rest assured that the situation will improve a lot in the final release.

So, first of all, let me state our goal: To create the most productive environment for designing and maintaining Swing interfaces of any complexity.

There are a number of key points in it. The first is the most productive. Of course, we would like our UI Designer to be the best in existence (who wouldn’t?), but there are too many ways to decide which one is the best, so we had to focus on one aspect of best. Our choice – productivity – shouldn’t come as a surprise for those familiar with our products.

Productivity, in my view, comes from a number of factors. The actions not essential for accomplishing the most common tasks should be removed from the workflow for those tasks. Every time the IDE can do part of the user’s work by itself, it should do so, or offer the user to do so. Every bit of information that the IDE can use to do its work better should be used. All common errors made by the user should be detected as soon as possible, and the IDE should offer to fix those of them that can be fixed automatically. The interface should always provide adequate feedback on the result of the user’s actions so that the user does not make these errors in the first place.

Later I’ll show how these factors come into play in specific features of the UI Designer.

The second key point is designing and maintaining. A piece of code written in a few hours or days usually gets maintained for many months or even years, so the ease of maintaining (expanding or modifying) existing UI forms is just as important for us as the ease of creating new forms. An interface that allows to build a form from a clean slate very quickly but provides unexpected results when the user starts dropping components into the middle of an existing form would not be acceptable for us. Also, it should be very easy to understand the structure of an existing form and its connections to other code. (Forms are in general much easier to figure out than Java code, but still the UI Designer should help as much as possible.)

The Swing interfaces point represents a limitation of our focus for this release (we’re not touching SWT or midlet form design, for example). It also means that we’re going to significantly expand the coverage of different Swing features in the designer. We’ve already done much work in that area (support for more property types, standard Swing layout managers, button groups and so on), and there’s also much work remaining to do before the final release.

Finally, of any complexity means that the designer should be equally suited for both simple and complex forms. For simple forms, we need to provide very easy ways to accomplish the most common tasks. For complex forms, we need to support building forms from multiple parts, easy possibility to combine hand-written UI components with UI Designer forms, easy ways to modify the form structure, and so on.

In the next post, I’m going to cover the key decisions on which the current UI Designer is based, some of which are new for Demetra and others have remained unchanged since previous versions of IDEA.

Today we have started the EAP for our new product – JetBrains Team Server, codename “Albus”. Its features were announced some time ago in the “Team Support” section of the Demetra roadmap, however, we decided to make it a separate product independent from IntelliJ IDEA. In fact, the product is not tied to Java either – support for building .NET applications will be provided as well.

OK, enough explaining for now – head over to the Download and Installation page to grab the bits, read the FAQ, and send your feedback in the forums and bug tracker. And I wish you many successful builds. :-)

I’m so tired of writing announcements that I won’t go into more detail right now, but I’ll definitely do so later… stay tuned to this blog. :-)

The major areas where new APIs have been added are:

PSI and Repository

• Package-level annotations support: PsiPackage.getAnnotationList(). Version 5.1 has improved support for processing and validating package-level annotations, and the new method provides access to the annotation list.
• Hierarchical method signatures: PsiClass.getVisibleSignatures(). The main motivation for this API is performance: it allows to calculate the information about the super methods of a method only once and not repeat any calculations for every superclass.
• Indexing occurrences of specified regex patterns in comments: IndexPatternProvider and IndexPatternSearch. This is effectively a generalization of the TODO API: TODO has been decoupled from the word index system, and it’s now possible to extend the word indexing. Possible uses for this API are, for example, finding occurrences of bug tracker request IDs in the comments. The query framework on which the IndexPatternSearch API is based (QueryFactory, QueryExecutor and related classes) has been backported from Demetra, and will be used much more extensively in the new version.
• Possibility to delegate getChildAttributes() processing to a child block of the current block: ChildAttributes.DELEGATE_TO_PREV_CHILD and ChildAttributes.DELEGATE_TO_NEXT_CHILD. In additional to these API additions, there have been a number of fixes in the formatter core (in particular, the fixes are required for correct operation of the Python formatter).

Version Control Integration

• Checkin handlers: CheckinHandlerFactory, CheckinHandler. This API allows any plugin to add actions which are executed before and/or after files are checked in to VCS. The new feature of version 5.1 “Before check-in / Perform code analysis on affected files” is based on this API, and in fact the entire source code of that feature is supplied in the CodeAnalysisBeforeCheckinHandler class.
• Code analysis API: AbstractVcsHelper.findCodeSmells(), CodeSmellInfo. These APIs are used by the “Perform code analysis on affected files” feature, but can also be useful for some other cases.
• Custom actions in the “Commit Project” dialog: Vcs.MessageActionGroup standard action group. There are no new APIs here besides the action group ID: all actions added to this group are shown as buttons in the Commit Project dialog. The standard “History” button is now provided by such an action, and its source code is supplied as ShowMessageHistoryAction class.
• External access to the “Browse Changes” functionality of VCS plugins: AbstractVcs.getVersionsProvider(). An extrernal plugin can now query that interface from a particular VCS and use it to load the history of changes for a file, directory or an entire project.

IDE and User Interface

• Querying the complete list of registered actions: ActionManager.getActionIds(), ActionManager.isGroup(). The APIs are used in the “New Action…” dialog of the DevKit plugin.
• API for creating classes from templates: CreateElementActionBase and PsiDirectory.createClass(name, templateName). Sample usages of this API are CreateClassAction in the OpenAPI and GeneratePluginClassAction in the DevKit plugin. The IdeView interface and DataConstants.IDE_VIEW have been moved to the OpenAPI because they are used by this code.
• Clickable annotations in the editor gutter: EditorGutterAction. Sample can be found in the implementation of the “Annotate” action of the Perforce plugin (PerforceFileAnnotation.PerforceRevisionAnnotationAspect).
• Automatic mnemonic registration: MnemonicHelper class. Used everywhere in IDEA, and particularly in the DialogWrapper class.

There are also a number of smaller changes and additions (for example, some new methods in the utility classes).

I’m very happy to announce this release because it’s the first major release of IntelliJ IDEA in which I was significantly involved. I joined the IDEA team at the end of 5.0 release cycle, and my contributions to the 5.0 release were mostly limited to documentation and occasional bugfixes. In this release, I was involved to some degree in three of the four main new features: i18n support, JavaScript support (originally developed for 6.0 and then mostly back-ported to 5.1) and plug-in development support. However, what I personally consider the most important for this release is the very large amount of work that the entire team has spent on bugfixing and performance improvements. It’s our users who will make the final judgement on the quality of version 5.1, but the perception of our team is that the quality is noticeably better than the last release, version 5.0.2.

Develop with Pleasure!

JavaDoc contributions are also welcome. However, we can produce JavaDocs pretty fast internally, so it may be sufficient to file a JIRA request specifying the classes that you would like to see documented.

If you would like to write an article covering some part of the OpenAPI, please contact me (yole@jetbrains.com) in advance and let me know about the topics you’re going to cover, so that we can avoid work duplication. Also, a new introductory plugin development tutorial will be published with the 5.1 release, so articles covering the very basics of plugin development are not in the highest demand now.

And thanks for your offer to contribute, Arik!

In previous versions of IntelliJ IDEA, the inspection profile was a user’s personal setting; it was possible to export and import inspection profiles, but having a single inspection profile shared between all developers working on the project was quite cumbersome. There was no simple way to propagate the inspection profile changes to all users if the profile was changed after initial configuration. Also, the only way to have different inspection settings in different files of the project was to disable inspections on per-file basis using an icon in the status bar. (In fact, the name for the icon – “Hector the Inspector” – was initially suggested by one of our EAP members, but we liked it so much that we started using it even in the names of classes related to implementing its functionality.)

IntelliJ IDEA 6.0 makes this much more flexible: it is now possible to store inspection profiles in the project file, and the custom scopes mechanism can be used to associate different inspection profiles with different parts of the project.

As you can see, we have a separate inspection profile for test sources (where the error strictness is much less important), another for the OpenAPI (where JavaDoc errors are highlighted), and yet another for runtime classes which need to be compatible with JDK 1.3 (so all Java 5 features and API methods are forbidden). The scope definition language is very flexible: for example, the OpenAPI profile is defined as “all modules which have openapi as part of the name”.

We have also made a number of extensions to the scope definition language. For example, it can now apply to files of any type and not only to Java classes, and it supports module groups (so you can define a scope as “all modules in this module group”).

When a new inspection profile is created, you can choose whether it should be saved as your personal profile (IDE profile), or as a shared profile in the .ipr file.

The status bar now shows the profile which is used to inspect the file currently open in the editor, and provides a quick way to access the profile settings. Note that we have dropped the old possibility to disable inspections on per-file basis: the scopes functionality is much more powerful, and if single-file suppressions are indeed what you need, you can create single-file scopes and associate empty inspection profiles with them.

I started working on Pythonid as a spare time project before I joined the IDEA team, while I was still working on Omea. After I started working on IDEA, I no longer had much spare time – and, frankly speaking, had enough IDEA-related coding in the daytime. Because of that, the development of the plugin pretty much stalled. However, I did send the plugin sources to several developers who expressed interest in the plugin newsgroup, and one of them – Keith Lea – was sufficiently interested to pick up the project and adapt it for use in the company where he’s working. Keith was also the one who arranged the release of the plugin at java.net.

The main problem currently preventing the release of the plugin is lack of a formatter. Otherwise, the plugin has roughly achieved feature parity with the JavaScript plugin as of IntelliJ IDEA 5.0. The formatter implementation has been problematic because of the issues with the formatter core – the Python indentation and whitespace handling is quite different from that of Java, so the core sometimes needs to be extended in order to support Python well.

I expect to make a “real” release of the plugin (and upload it to the Plugin Manager) as soon as either the formatter reaches somewhat working state, or it becomes clear that it will not be possible to achieve a sufficiently working formatter with IntelliJ IDEA 5.1. In the latter case, the plugin will be released with the formatter disabled.

There is still lots and lots of work to do on the plugin, so if you’re interested in contributing, feel free to contact me.

Update: Chris Miller has kindly provided instructions for checking out and building the plugin.