Napkin.next Plan

Intermixing formal and napkin in the same GUI

• Given the original idea that provisional look is to match provisional implementation, as you get each subsystem down for real (say, to alpha) you want to turn that part of the UI into the UI that you'll ship with (say, native). That's the LAF that I think of as "formal" (vs. napkin as "informal").
• What I want to know is whether this actually works with the two co-existing or not. It might just work, and then this is 95% done.
• There are swing utilities to set a LAF on a subtree, which is a start. If it all works and we can't think of a significant improvement on the swing utilities, then we're all done. Otherwise we design a way to make this easier.
• The ultimate test - Substance as formal L&F (watching them crash is fun enough! )

Proposed Solution	Issues	Merits
UIManager.setLAF(formalLAF), SwingUtilities.updateCT(node), UIManager.setLAF(Napkin)	Currently Napkin will hook a global component uninstallUI() event when it is uninstalled by UIManager	Simple-minded enough
Replace ComponentUI entries in UIDefaults, SwingUtilities.updateCT(node), restore entries	UIDefaults from the formal L&F will not be present	NapkinRepaintManager in 1.1-SNAPSHOT takes care of repaint of underlying Napkin components

Current solution under test

• Ctrl+Shift+Space toggles between formality switch mode
• Under formality switch mode, a glass pane is laid on top of the JFrame to catch Mouse Event
• User can click to select components to switch from / to Napkin
• Implemented in SwingSet^? Demo

Improvements:

• Work for all JFrames under Napkin
• Work for JMenuBar^? and JFrame (need reloading of Window)
• Configurable keyboard combination for formality switch mode toggling
• Graphical indications of formality switch mode using the glass pane
• As components are being added, inherit from parent whether formality mode is on or not

Working with 1.6 if it's there

List of things that need to take care of in Mustang:

• JComboBox's drop-down list has its scroll-bar broken again.
• There are new methods introduced in Mustang for several classes, RepaintManager for instance.

The idea:

• Have .class files for the classes that need to differ under 1.6.
• On startup, do some test for 1.6 (should be several ways to do this).
• If it's 1.6, add a class loader that will load those classes preferentially.

Another idea:

• compile the classes with Mustang JDK, with source & target set to 1.5.
• since the new methods will be present in the new JDK, compilation will complete successfully.
• earlier libraries will never call these new methods (because they don't know about them), so everything will just work.

• MacOS users will not be able to compile because they have yet to have a working JSE 6 on their systems.
• The new methods will be available when others write applications against our API, so it is possible that they call these new methods; since most of them are delegations, it will end up calling the Tiger Classes and ended up with MethodNotFoundException.

A "sketching" filter for their images (Done!)

Imagine an image filter that could do this and/or this. We could set it up so that images the user displays would be (optionally) automatically filtered like this, making their own images also "sketched". Maybe there's a better filter, but that's the basic idea.

• a setIcon() (smart?) listener
• get an edge image using an edge-finding filter
• then just quantise the colours of the original icon to fewer levels and overlay it with the edge image
• actually one can do some random perturbation to the edge image (or both) before putting them back together
• sounds good enough?

Current solution

• SketchifiedImage^?
  • ImageObserver^? used for handling resketchification of dynamic images
• SketchifiedIcon^?
  • basically uses the logic in Sketchified Image
• renamed SketchedIcon^? to DrawnIcon^? to make things clear

Making blueprint more blueprint-y

• Testing whether blueprint should be inverted in colors -- most modern blueprints have blue lines, not blue background.
• Nearly straight lines with angular and length variances. (Nearly straight because architects are better than average at drawing straight lines.)

Themes that affect the way lines are fudged

A calligraphy theme.

• because it is a good thing to have

Algorithmic crumpling of the napkin

• Assuming that the texture pattern is small, we can separate the texture layer (let it be painted onto the background undistorted), then generate a (fractal?) alpha mask which is a large enough BufferedImage in memory to generate the crumpling effects. Hence we can achieve large (or infinite) period of repetition without the need to store a really large image in the Napkin package.
• Another possibly simpler idea is to rotate the present paper at a random angle so that the repetition looks more subtle.

Algorithmic erasing for disabled components

• do alpha brushing similar to the progress bar scribble fills, but will thicker stroke and at a different (random?) angle.

Benchmarking -- is it better to choose from 100 pre-calculated checkmarks (say) than generating each one?

• If it is significantly faster and it still looks random it might be worth it, although there's something quite emotionally satisfying with being able to say "Each checkmark is randomly generated" instead of "We pick from a set of varying checkmarks". The most likely place this would be useful is for the small drawn icons, which have more lines, etc.

-- Main.alexlamsl - 26 Apr 2006