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.

Bug 106550 - Decoration support
Summary: Decoration support
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Graph (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@platform
Depends on:
Reported: 2007-06-13 17:31 UTC by Sergey Petrov
Modified: 2007-06-14 16:14 UTC (History)
0 users

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Petrov 2007-06-13 17:31:57 UTC
It's good to have widget decoration support (may be implemented in projects using graph library, but may be it have
sense to add support to the library)
What I mean by decorations:
-currently there is build in support for selection border, but it's not good to use borders in this case because borders
affect client area, area available for children, bounds etc (for example I have to adjust bounds of parent when it's
selected, or use transparent borders, but what should I do for children), decoration should be drawing only without such
-similar case may be for focus highlighting borders which may be used more  often for children
Comment 1 David Kaspar 2007-06-14 08:22:30 UTC
The basic problem of this "decorations" is its definition. What exactly these decorations should do and how they are
assigned/invoked to procced their changes.

In general, it is hard to implement a generic decoration since they has to be aware of every Widget in the library and
change them accordingly.

For now there is a Widget.notifyStateChanged method. This method is notifying on each object-related widget when a state
of the object is changed. It is totally up to the developer of such Widget to install/update a particular Look&Feel.

Regarding the border-recalculation - you can wrap your Widget (with resizing) into a top-level Widget that would have a
Vertical Flow Layout. Then the top-level widget will always start from [0,0] point and the border insets of original
widget with eliminated.
Comment 2 Sergey Petrov 2007-06-14 13:32:07 UTC
Yes, I'll solve my cases in current lib, it was just a question if it possible/have sense to add library support for
such feature.
Comment 3 David Kaspar 2007-06-14 16:14:29 UTC
The whole problem is the definition of the feature. If you have a patch for the library, feel free to attach it to the
issue. I am leaving the issue opened.