Patrick Wright

Hi Dmitry

Thanks for your feedback. We don't agree on all points, but I'm pleased that you took the time to think it over and respond.

A couple of quick notes.

- My list of plugins has 366 entries--going back to 2004. I am sure a number of those are for features which are no longer useful (being in the newer versions of IDEA already).

This request is not really specific to plugin development - this is a general issue of checking out code from a repository and creating a project for it. We've improved support for this scenario in version 7.0, and if you have specific suggestions how to improve it even further, feel free to post JIRA issues.

Spend a few minutes on the plugins website, for example, category "Editor". How many of the first 10 have source code linked, even the ones listed as "free software"? I count 2 out of 10. In some cases, it may be available--great, go to the Wiki page, scroll down until you find it.

I'm sure we can do better.

I think the risk IntelliJ faces is that the plugin repository is a becoming a dumping ground. At least that's my experience of it. Many of the plugins I try out are unstable, incomplete, or throw exceptions (but keep running). That was my experience with jEdit plugins as well. Some strategy to encourage feedback, rating and involvement seems necessary.

But that's just my opinion--again, thanks for listening.

Regards
Patrick


I added the following issues to the tracker:
pull source with plugin
http://www.jetbrains.net/jira/browse/IDEA-16254

see votes in plugin dialog
http://www.jetbrains.net/jira/browse/IDEA-16255

comment/rate plugins
http://www.jetbrains.net/jira/browse/IDEA-16256

plugin exception reporting
http://www.jetbrains.net/jira/browse/IDEA-16257

obsolete plugins
http://www.jetbrains.net/jira/browse/IDEA-16258

Hi Dmitry

I've used NetBeans, jEdit, IntelliJ, Firefox, among other plugin-extensible tools. One problem these all have--including IntelliJ--is that apart from those officially supported, plugins are generally not tested, reviewed or recommended by the makers of the tool itself. In the worst case (true for all those tools) the plugin repository includes quite a few "junk" or incubator-quality plugins that don't deserve to be used in a serious development tool. What I periodically find is that plugins that aren't actively maintained throw exceptions, for example, and when this becomes enough of an annoyance I pull the plug and remove the plugin. The current system of tracking plugin quality via voting, and commenting via a discussion page (and unmaintained wiki) doesn't take us far enough.

I would love to see some sort of review system by IntelliJ for plugins. I see and appreciate the voting system, appreciate that JetBrains has lots of work on its hands, etc.--but I feel the current system includes too many unstable plugins and something in the process could be improved.

Here are some practical ideas:
1) if the plugin is open-source, plugin developers should be required to distribute it with (an) IntelliJ project file(s) so that one can easily retrieve, debug and improve the plugin.
1a) would be nice to have a dialog or feature to pull plugin source down with the plugin (jEdit supports this), optionally pulling in the plugin project or plugin module(s)
1b) some way to encourage collaboration would be useful. for example, if plugin developers were hosted on site X (sourceforge, google code, codehaus, java.net), it would nice neat if IntelliJ could take care of the grunt work of getting CVS/SVN set up so that source code could be downloaded, and patches could be submitted more easily

2) the JetBrains team could help by marking older plugins which have been superseded by features in newer releases of IntelliJ. currently there is no filtering on the plugin list, which includes very old plugins that are no longer useful past a certain version.

3) the plugin dialog could be extended
3a) to include links to the source (and maybe a checkbox to download it)
3b) to show the number of votes on a plugin

4) a quick tool to vote on plugins would be useful--for example, when disabling or removing a plugin, an option to vote and comment (to be posted to the plugins website)

5) some way to capture activity in plugin development would be helpful--e.g. plugins released just once would have a lower rating than those regularly updated

6) include vote categories for "stability", "configurability"

7) when a plugin throws an exception (or is suspected as the cause), it would be great to be able to
7a) disable the plugin immediately
7b) vote on it
7c) file an issue or
7d) submit a comment to the plugins site
7e) track the number of exceptions thrown per plugin, across users (optional, of course, as this info would be uploaded)

8) i get a very bad feeling from plugins distributed as binaries, with no email address, plugin home page, or developer home page provided.

9) nice to have--assuming the source was available, a PMD or Checkstyle configuration could verify (and warn) if the plugin performs IO, network operations, etc. (esp. for plugins with no email address or home page).

Sorry, that's a long list! But you have such a great start in the current plugin set that it's worth asking for it to be first-class.

If you think any of these are worthwhile, and might be implemented in the future, I'm glad to add any or all suggestions as feature requests in JIRA.

Thanks!
Patrick

Hi Dmitry

I use IntelliJ for all my coding at this point, but I still find I need to keep a copy of jEdit or another editor around to edit random files. While I can open any file in IntelliJ, the editor is really project-based, and doesn't make it easy or comfortable for me to work with files outside of my project.

The way I see it, IntelliJ belongs to a class of tools that are project-based, where the developer's focus is on a set of files that belong (usually) to one top-level directory. Within that structure, the editor has good knowledge of how the files relate to the project and to each other.

jEdit on the other hand, is basically a super-text editor, which, for files matching some pattern (name pattern, for example), it can provide syntax highlighting, plugin support, etc. I find I can't get 100% of my job done--or anywhere close--if I don't have a regular text editor at hand.

IntelliJ seems to already have most of the functionality one would want, however, it would need to be organized somewhat differently. For example, in jEdit, settings for the buffer can be per-buffer or per "file type" (where file type may be based on a name match, for example). We already have good search functionality and there is at least one "file browser" plugin. Some features are missing, for example decent scripting support.

Question is--does JetBrains have any interest in expanding the scope of what IntelliJ is aimed to support to include this use-case?


Thanks
Patrick

Thanks to both of you for your replies. I now have a better idea of what's involved. I've started to read the sections in the book that you referred to, also very helpful.

Cheers!
Patrick

Hi Chet

Thanks for the reply. I asked the question in part because I was having trouble understanding when the buffering takes place. If I follow you correctly, graphics operations on the Graphics instance passed to any JComponent are written directly to the back buffer, and there is only 1, large, back buffer. Is that more or less it? I was under the impression that there was 1 buffer per component, and that we might be disabling it by taking control of the full panel rendering space.

What was confusing to me is that while on one level, you could say we have lightweight components (as in really lightweight, since we need so many of them to satisfy the layout model), Swing just treats it as a JPanel which is handling its own rendering, and buffers it just like any other component.

As a follow-up to that, this also means that as far as the standard RepaintManager is concerned, if a change takes place within our rendering model (that's the model that corresponds to items on-screen, like lines of text and such) the RM won't be able to track what exactly changed, since it only has access to the single "dirty" state of the whole panel. Right now the only "dynamic" changes we support are related to mouse hover over elements, and only support model changes that don't affect the layout--things like changing the background color or border color. Still, we have the issue that as the mouse moves over the panel, it may trigger a change in just one element of our model and in principle we would want only that region to be updated.

However, as a plugin library, e.g. as a utility people use within a larger application, it seems wrong for us to install a custom RepaintManager which could track smaller dirty regions within our panel. Our model elements can track that, though. What is the correct way to approach this? I'm still confused about the relationship between repaint (when a component is dirty) and the back buffer. Ideally we'd like everything in the buffer to remain the same, and only repaint the area in our panel affected by the hover. The performance of this in fact is very good, but I'd like to understand the responsibilities, strategies and optimizations people are recommended to use.

Here's an example. Suppose I'm writing a game of life program where I want to draw the entire grid (10 * 10) myself. I have a model that can track each cell in the grid and paint each cell individually. In the first generation I start out with three living cells at 0,0 to 0,2. In generation 2, the model is updated so that cell 1,1 is alive. The panel is now dirty (from Swing's perspective). What is my responsibility, as component owner, to redraw? Do I have to keep my own back buffer for the panel and update the just clip for just the affected cell on my buffer, then copy the buffer back on to the Graphics instance?

TIA
Patrick

Hi

I've started to read Filthy Rich Clients and I have (at least) one question related to buffering in Swing. The Swing library will normally buffer individual components into a back-buffer without any extra coding on the programmer's part. But what if you're taking control of an entire panel and rendering directly using Graphics2D? I'm thinking about this in terms of Flying Saucer, wondering if we are doing the right thing. What we don't do is create 1 Swing component for every renderable, positionable item that appears on a page, except for form elements and images--there is an in-memory rendering and layout model, but it's used to direct the direct rendering operations themselves. When Swing (and not, say, PDF) is the output target, we're working with a single JPanel subclass embedded in a JScrollPane.

It seems to me that the RepaintManager won't be able to track what changes--but I assume the entire panel is still double-buffered automatically?

The rendering engine we have is not my domain but the question still interests me...

A separate (but for me, related) question is how ScrollPanes are optimized--how much of the scrollable content is in memory, when it gets there, if it's buffered, etc.


TIA
Patrick