I want a desktop equivalent of Applet and Servlet called Application. It would provide hooks to all of the other things we are going to design with regards to native integration and packaging. It would have subclasses for specific types of applications to take care of most of the boilerplate that most apps have. For the most part these are frameworks where you can override just what you need. More ApplicationNotes ex:

• Application
• SingleWindowApplication^? (for quick apps)
  • take a look at the MainWindow class of the opensource uic (API / WebStartable Demo) -- TZ
• DocumentApplication^? (manages toolbars, tracks windows, MDI vs free floating support, native file open hooks)
• FullScreenApplication^? (has warnings about changing the window. restores on exit. stores system prefs)
• ScreenSaverApplication^? (with native hooks for making screensavers)

A better file chooser. Fixes all of the bugs. Looks more native. Supports platform specific links and shortcuts. Easier to extend. Better defaults.

• See the beta version in the opensource UIC (WebStartable Demo) -- TZ

An equivalent of Cocoa's NIB files which define all ui resources. Preferably with a good WYSIWYG builder.

Best practice documentation specifically tailored towards desktop applications in Java. Detailed patterns, approaches, etc. that lead to more elegant, scalable and extendible GUI applications.

Outlook style button bar with sliding panels (and animation?)

Prefab three pane outlook style window (is that overkill?)

Collection of prefab text input boxes for different data formats (zip, state, telephone number, ipaddress, hostname (dns lookup?))

A prefab dialog/component which contains two lists and lets you add/remove items from one list to another. A prefab control panel dialog panel with a list of panels on the side. Like in FireFox^?.

APIs: Would like to see a set of wrapper APIs for Swing to speed up development. A number of ideas:

1. create a Table model from common file formats: CSV/tab-delimited, fixed-width. E.G. FileModelBuilder.newCSVTableModel(localFile)
2. create a TreeModel^? from XML format in one go: FileModelBuilder.newXMLTreeModel(localFile)
3. JComponents with automatically-threaded events using SwingWorker/FoxTrot/UICompiler, maybe through a Factory
4. Decorators to provide useful functionality to JComponents. For example, a Decorator that can localize the text on a JButton by working with a localization utility, or change GUI stuff by working with a CSS utility (lookup fonts, colors, borders on instantiation, receive messages when CSS is changed), or link components to JavaHelp^? file stuff

Proper double-click/single-click support or at least access to the double-click speed in the system. Even though a double-click should be something extending the single-click from a UI design perspective, that does not apply to the code level, there should be an event modeling the single-click as in: "mouse button was clicked and a potential double-click timed out".

Better inbuild support for rendering shapes on a canvas, in a model similar to SVG. Think vector drawing apps and graph visualizations.

DPI-indepence: MS Avalon is going to have it and people will want it. And it makes sense to have the font size proportional to the physical screen size, not to the resolution. Up the resolution to get nicer fonts etc, not to make them smaller.

Inbuild session management: windows should store their position and other layout aspects (sliders, etc.) between sessions unless we tell them not to. They could have unique names in the context of their parent to implement that.

Inbuild i18n: instead of having to setText(..) in the code and then translate that, the text should be assigned to a component in a defined way. Something like:

MyDialog.OkButton.text="Annehmen"

Where MyDialog is the class name and "OkButton" is something assigned to a JButton as its name. A bit like the old Windows API which enforce i18n. In Swing I have to make up and maintain my own labeling scheme.

Is Better Formatting of This Wiki Possible?

Percieved Swing Slowness Fix (GridBayLayout^? Improvement)

Here's a thought: Is it possible to optimize the layout manager to copy from the offscreen buffer more often? Is it possible with some simple checks (no weight, ...) to determine if the component can be copied instead of redrawn? I suspect that the math to figure out the new component sizes happens instantly and if perhaps the layout manager could be smart enough to temporarily cache (the old offscreen buffer location/size) which components can be copied maybe the cached components could be moved first (maybe even by using a fast moveto() using only the graphics card memory). I can already see overdraw problems so some more texture/image caches will have to be made available. Maybe instead of using a large offscreen buffer each component could have its own individual offscreen buffer residing on the video card. re-assembling windows might be slightly slower in the "dumb" case but perhaps potentially much faster in the GridBag^? case. Maybe as long as the user is wildly resizing the screen OpenGL^? texture scaling could be used. When the user lets go of the mouse the affected components are redrawn then. If you did this even a slow TNT-2 could provide refresh rates of over 30fps when wildly scaling/resizing.

With a few changes I think the GridBagLayout^? could be made vastly faster and folks wouldn't point at this corner case anymore. I think James Todd already did most of the work by enabling OpenGL^? texture support for BufferedImages^? in Java 1.5. The rest of the work is mostly just simple management of the individual component textures. Thoughts?

-- Main.markswanson - 27 May 2004