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.
| Summary: | [2004-05-06] Separate and standardize GUI initialization (UIDefaults usage) in core | ||
|---|---|---|---|
| Product: | platform | Reporter: | _ tboudreau <tboudreau> |
| Component: | -- Other -- | Assignee: | _ tboudreau <tboudreau> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | ||
| Priority: | P1 | ||
| Version: | 3.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | TASK | Exception Reporter: | |
| Bug Depends on: | 41702, 42140 | ||
| Bug Blocks: | 26592 | ||
| Attachments: | Javadoc with arch questions answered for review | ||
Creating a branch for this and the tab control cleanup/separation/sliding windows, since they're being worked on in parallel, and that way changes in that issue will also be notified to apireviews. Branch tag is ui_cleanup - base tag for branch is BLD200403281800 Created attachment 14342 [details]
Javadoc with arch questions answered for review
Fixed a couple weeks ago |
I am proposing to separate some code currently in the window system into a standalone library. What I want to accomplish is the following: - Currently, UI initialization in core is messy - custom font sizes are handled in one place, theme support is handled differently, and so forth. For clarity and readability it would be better to do this in one place - Provide a proper place to provide custom UI delegate implementations (such as toolbar UIs - currently this is quite messy except on Aqua, where the UI is already provided in this way). Swing offers a mechanism for handling custom UI delegates; we should use it. Note this does *not* apply to any UI that would need to reference specific classes. - Provide a place for installing custom colors and fonts which are used by NetBeans components - Provide a way to guarantee that commonly used values from UIDefaults (such as the "control" color), etc. are really there, even if they are not supplied by the look and feel directly. Currently in many places in NetBeans code you can see things like: Font f = UIManager.getFont ("controlFont"); if (f == null) { f = UIManager.getFont ("Label.font"); } if (f == null) { f = UIManager.getFont ("Tree.font"); } if (f == null) { f = new Font ("Dialog", Font.PLAIN, 11); } This sort of thing is pretty unreadable and unnecessary. It would be better for core to simply guarantee values for commonly used things, so code in other parts of the codebase can be as straightforward as possible. - Which brings us to the reason for separating this - if components of NetBeans are used in a standalone application, but they are written to expect non-null values for things like "controlFont" from UIManager, they can do that simply by calling an initialization method in a class in this library I will attach a diff with details of the changes in the near future. As a public API (if you can even call it such), this module will offer a single main method that can be called to initialize its contributions to UIDefaults. Since this module will be part of core, it's questionable if that qualifies as API - I leave that up to you. The NetBeans-specific UIManager keys which it puts into UIDefaults can be construed as a "friend" API, possibly. The UI delegate implementations it puts into UIDefaults will simply be alternate, NetBeans-specific implementations of UI delegate classes provided by the JDK (such as our custom toolbar grips for draggable toolbars, things like that).