Source code
/* Copyright (C) 2007 by Peter Eastman
This program is free software; you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE. See the GNU General Public License for more details. */
package artofillusion.ui;
import buoyx.docking.*;
import buoy.widget.*;
import java.awt.*;
/**
* This is a DockableWidget subclass that paints its border using colors obtained from ThemeManager.
*/
public class DefaultDockableWidget extends DockableWidget
{
public DefaultDockableWidget()
{
}
public DefaultDockableWidget(Widget content, String label)
{
super(content, label);
}
protected void paintBorder(Graphics2D g)
{
Rectangle bounds = getBounds();
Insets insets = getBorderInsets();
g.setPaint(new GradientPaint(0, 0, ThemeManager.getDockableBarColor1(), 0, insets.top, ThemeManager.getDockableBarColor2()));
g.fillRect(0, 0, bounds.width, insets.top);
g.setColor(ThemeManager.getDockableBarColor2().darker());
g.drawLine(0, insets.top-1, bounds.width, insets.top-1);
g.setColor(ThemeManager.getDockableTitleColor());
if (getLabel() != null)
{
FontMetrics fm = getComponent().getFontMetrics(getComponent().getFont());
g.drawString(getLabel(), 2, fm.getMaxAscent()+2);
}
}
}
Run 1
The code is logically structured, with clear class responsibility and minimal nesting. Methods are short, focused, and well-named, making intent easy to understand. The paintBorder method uses a flat control flow, mostly one action per line, and follows a natural top-to-bottom progression: bounds, colors, fill, line, then label. The only minor weaknesses are the slightly long gradient creation line and the repeated calls to ThemeManager methods, which could be placed in named variables for improved readability. Overall, it is concise, maintainable, and easy to follow.
Run 2
The code is well-structured, with a clear class definition and logical imports. It uses flat nesting with only one if-statement, making it easy to follow. The purpose of each method is evident: constructors for initialization and paintBorder for custom rendering. The code is concise, avoiding unnecessary verbosity. Each line performs a single action, maintaining good granularity. Reading flow is natural, with the paint logic progressing from background fill to border line to text. Minor readability could be improved by extracting the gradient painting and font metrics into helper methods, but overall it is highly readable.
Run 3
The code is generally readable with a clear purpose: a dockable widget that customizes its border painting. The class structure is logical, with two simple constructors and a single overridden paintBorder method. Nesting is minimal (one if statement), and action granularity is mostly one action per line. The paintBorder method follows a natural flow—get bounds, compute insets, paint gradient, draw line, then draw label. However, readability is reduced by several long lines, especially the GradientPaint constructor call, which packs many arguments into one line. The drawing coordinates (e.g., 'insets.top-1', 'fm.getMaxAscent()+2') are magic numbers without explanation. The empty no-argument constructor is unnecessary and adds clutter. Overall, it is clear and concise, but could benefit from line breaks and explanatory comments for coordinate calculations.
Run 1
Code Structure: The class is logically organized, with constructors followed by a focused border-painting method. Nesting: Only one shallow conditional keeps complexity low. Clarity of intent: The class documentation, descriptive API calls, and theme-related names clearly communicate its purpose; abbreviated variables and unexplained positioning constants slightly reduce clarity. Code length: The implementation is concise without unnecessary logic. Action granularity: Each statement performs one primary action, although the gradient construction combines several arguments and method calls on a long line. Reading flow: Painting proceeds naturally from background to separator to title, with consistent formatting. Separating these visual stages with blank lines, adding an override annotation, and spacing arithmetic expressions would improve readability further.
Run 2
Code Structure: A small, focused class cleanly separates constructors from border rendering. Nesting: Only one conditional, keeping control flow shallow. Clarity of intent: The class documentation and descriptive theme methods clearly explain the purpose; abbreviated variables and unexplained pixel offsets slightly reduce clarity. Code length: Concise, with little unnecessary implementation code, though the gradient construction line is long. Action granularity: Each statement performs one main action, making drawing operations easy to follow. Reading flow: Rendering progresses naturally from background to separator to title, with consistent formatting. Minor improvements would include wrapping the long line, spacing arithmetic operators, and using more descriptive local names.
Run 3
Code Structure: A small, focused subclass cleanly separates constructors from border rendering. Nesting: Only one shallow conditional, making control flow easy to follow. Clarity of intent: The class comment, method names, and theme-color accessors clearly explain the purpose; abbreviated variables and unexplained positioning constants slightly reduce clarity. Code length: Concise implementation with no unnecessary logic, though the gradient construction line is long. Action granularity: Each statement performs a distinct operation, with only modest expression complexity. Reading flow: Rendering proceeds naturally from geometry retrieval to background, separator, and optional title. Consistent formatting supports readability, although spacing around arithmetic operators and an explicit override annotation would improve scanability.