David Schneider wrote:
>Once you have a check configuration defined you still need to enable
>checkstyle on your project.
Ahh, now it works, thanks. Maybe you should add that info to the readme
>> * Peter Dobratz has done a very nice job documenting the
>> Maybe you should use the first sentence of that documentation
>> instead of displaying the constant names in the gui. Would it be
>> helpful if TokenTypes provided a way to access the documentation
>> programmatically, so you don't have to manually copy
>Yes, programmatic access would be useful.
I have added a feature request,
> I'm not happy with how the GUI
>looks when there are a large number of token types on it but that's all I
>had time for. In the future I'd like something that scrolled when the GUI
>get too big. I originally tried more meaningful names for the token types
>but the labels got to big and the windows size got out of hand. All
>suggestions are welcome.
I don't know SWT, so the following is in Swing terminology. I would
suggest a scrollpane that contains a two column table, with a checkbox
and a description, like this:
| active | description |
| x | Assignment operator (=)|A+
| o | Plus operator (+) | +
| o | Minus operator (-) |V+
By using a scrollpane you can limit the vertical size of the table. I
hope SWT allows you to set the column type to boolean and make the
"active" column editable. In swing you do this by setting the column
type to Boolean and make TableModel.isEditable(row, col) return true for
the first column. This allows you to edit inside the table, without the
need to open a dialog.
Note that table cell editing would also be useful for the severity
settings in the toplevel tabbed panes. It would make it more convenient
to turn off all checks in one tab and it would save screen space in the
check configuration dialogs, as the severity combobox would not be required.
>> * How do you generate the help texts, do you manually
>>copy our docs?
>Yes, presently I copied the Checkstyle docs since there was no other easy
>way to reuse the material. There is an XML file inside the plug-in jar that
>contains all the metadata for the check rules, the help text is in that
OK, I see. This seems like a lot of duplicate work, so I guess we should
provide such a file in the checkstyle core...
>> Maybe we should seriously start looking at xdoclet to
>> files from our javadoc.
>Might prove useful.
... by using the javadoc info. Please submit a feature request to the
checkstyle tracker and state excacly what data you need to be available.
Do you have experience using xdoclet?
>> * Does SWT allow you to turn off the cursor in comboboxes
>> "severity" combobox)?
>I don't understand this one, I don't recall seeing a cursor. Can you send me
>a screen shot?
Maybe this is only a problem on Linux/GTK. A screenshot is attached,
note the vertical cursor which is actually blinking and can be moved
using the cursor keys. It does not allow me to type anything, though...
>> * Do you plan to support import of hand-written configurations
>> ("Import Checkstyle Config")? I tried to import a
>> file through "Import Plugin config..." and did not get
>>a new entry
>> in the configuration list, but no error message either.
>The import is only for the plug-in exported file. I thought a lot about how
>to do this and the main problem is that someone can have their own rule
>classes in a standard config file. The function correctly the plug-in needs
>some additional metadata about the rule in order to build the GUI which it
>would not have. Currently, you can only import config files in the plug-in
I see, and I guess that's no problem, just use the eclipse editor as
All in all the plugin works fine. Here are a few more small issues I
found when experimenting with the plugin:
When I click on a checkstyle task, the cursor moves to the line *after*
the problem, although the correct line is marked (blue). Is it possible
to include the column data in the AuditEvent in the task data, so
eclipse can jump to the exact error location? This is available in
Emacs, and in combination with "go to next error" it speeds up error
The config dialog input fields seem to strip leading whitepace. I tried
to change the Generic regexp settings to " $" to disallow whitespace at
the end of line (maybe that would also be a better default). The plugin
marked all lines, and when I reopened the editor, the leading space was
lost in the input field.
I notice that Eclipse has a few features that overlap with checkstyle.
For example the user will get TODO comment tasks twice. Maybe you should
set the default severity to "Ignore" where checkstyle and Eclipse overlap.
Eclipse also has code formating feature. Long term suggestion: Would it
be possible to extract these settings (like maximum line length) and
reuse them as the default in the checkstyle configuration?
OK, that's all I can say right now, hope this feedback helps you to
polish your plugin a bit.
PS: I have to say that Eclipse seems quite good now, much better than
last time I had a look at it about a year ago...