This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
In the API the border painting is independent on a widget where a border is assigned. The best solution would be to pass related-widget as an additional argument to a Border.paint method. Unforunately Border is an interface and therefore it would introduce backward-incompatible change. Therefore there is another proposal for API change: Widget.paintBorder method is introduced with implementation: border.paint (getGraphics (), bounds) This is backward compatible. Later we can create a new WidgetBorder interface with the "widget" parameter in its paint method. More details: http://graph.netbeans.org/servlets/ReadMsg?list=users&msgNo=567
Created attachment 39683 [details] Proposed patch for introducing Widget.paintBorder method
Two notes: -please increment spec version of the library (so that clients can depend on the enhanced version of the library), use @since tag in the javadoc -this change is IMO not compatible: if a custom Widget subclass defined "private void paintBorder () {}" it will not be compilable
I agree that it is not 100% compatible. Another solution could be to introduce WidgetBorder abstract class (derived from Border) with additional paint method parameter.
Actually the change in 100% binary compatible. It is not source compatible. But source compatibility is unachievable anyway if the API gets modified from time to time... I am big fan of final classes, but as this API looks like it looks, we'll probably have to live ocational method additions. Definitely it is ok until first official release - e.g. before 6.0. Y01 Write test. Y02 Increment spec version Y03 Put note to apichanges.xml
The API change has been integrated: Widget.paintBorder method has been introduced. apichanges.WidgetPaintBorderTest visual test added.