First cut at support for Retina displays

[cbfiddle]

This is a first cut at supporting Retina displays. Very much a work in progress, but I don't think it breaks anything. There are some changes needed to support this code which would be good to get in place now.

Retina support is provided by a new Java 1.8 dependent LAF. It is experimental and must be explicitly requested; see the Ant task 1.8x. My approach is to start with the Aqua look and feel (which already supports Retina displays) and add features one at a time. Currently, the only additions are the file chooser, the color chooser, and the new Yosemite system font. I chose this approach because the Quaqua painting extensions are not compatible with Retina displays and I don't think it is worth the effort to convert them. Using native Aqua painting is pretty decent in 1.8.

[karlvr]

Very interesting! So my understanding of this is that you're stripping out most of Quaqua's functionality, and just using file chooser, color chooser and font. Is that correct?

Is the intention to then migrate other Quaqua components that are improvements over their build-in alternatives? I have tried the Aqua LF a few times recently in Charles and it seems there are still several things that aren't so good; from memory, Toolbars and perhaps Split panes? I didn't look very closely. So I think that this is an interesting idea, but I think we might need to pick and choose a few more bits to include? Do you have any thoughts about a process to do this?

What are the implications of this pull request on existing Quaqua users?

There are a few whitespace changes that are probably superfluous. If it isn't too much trouble it would be great to exclude those and push again, just so we limit the scope of the changes.

[cbfiddle]

On Nov 10, 2014, at 1:28 PM, Karl von Randow [email protected] wrote:

Very interesting! So my understanding of this is that you're stripping out most of Quaqua's functionality, and just using file chooser, color chooser and font. Is that correct?

Yes, but only for this new, unfinished, experimental LAF.

Is the intention to then migrate other Quaqua components that are improvements over their build-in alternatives? I have tried the Aqua LF a few times recently in Charles and it seems there are still several things that aren't so good; from memory, Toolbars and perhaps Split panes? I didn't look very closely. So I think that this is an interesting idea, but I think we might need to pick and choose a few more bits to include? Do you have any thoughts about a process to do this?

I agree that more will be needed, but maybe not that much. I don’t have a process in mind beyond looking into things that bother me! Migrating may not be trivial, however. I think the goal should be to leverage as much of the Aqua LAF as possible, tweaking and extending rather than replacing wherever possible. Presumably, the Aqua LAF will be improved over time.

What are the implications of this pull request on existing Quaqua users?

Hopefully, none.

There are a few whitespace changes that are probably superfluous. If it isn't too much trouble it would be great to exclude those and push again, just so we limit the scope of the changes.

I understand, but for me it is too much trouble. IDEA has a global option to strip trailing whitespace when saving. I don’t want to try to keep that in sync with different projects.

Alan

[karlvr]

Have you tried compiling this using the ant script? I get 3 errors trying to compile. I suspect that some classes need to be compiled with Java 8?

    [javac] /Users/karlvr/Development/Quaqua/Quaqua/src/ch/randelshofer/quaqua/QuaquaIconSupport18.java:80: error: cannot find symbol
    [javac]         implements sun.awt.image.MultiResolutionImage
    [javac]                                 ^
    [javac]   symbol:   class MultiResolutionImage
    [javac]   location: package sun.awt.image
    [javac] /Users/karlvr/Development/Quaqua/Quaqua/src/ch/randelshofer/quaqua/QuaquaIconSupport18.java:119: error: method does not override or implement a method from a supertype
    [javac]         @Override
    [javac]         ^
    [javac] /Users/karlvr/Development/Quaqua/Quaqua/src/ch/randelshofer/quaqua/QuaquaIconSupport18.java:124: error: method does not override or implement a method from a supertype
    [javac]         @Override
    [javac]         ^
    [javac] 3 errors
    [javac] 1 warning

[karlvr]

Sorry, false alarm. I had a cheeky EA of 1.8.0_40.

[karlvr]

I'm interested in this approach. It's really interesting seeing my app in Helvetica Neue. I see you've done some more work on this. I'd like to watch this and I'll test my app (Charles) on it - just let me know when you've done some more work.

The biggest thing that Charles uses that is awful in plain-Aqua is the toolbar and buttons on it - the default buttons get borders, but Quaqua tides them up nicely.

In your r2 branch, the split panes are looking a bit funky - I'm guessing it's work in progress.

When it comes time to merge this back in, I will have to do a manual merge to avoid all of the superfluous whitespace changes. I want to maintain a clean repo history, especially for such big changes. I'm also a fan of several small commits, for a big piece of work like this, rather than lump-sum ones. So feel free to work like that if you prefer.

[cbfiddle]

Looking at the NSSplitView documentation, there are three styles - thick, thin, and pane splitter. What I implemented was pane splitter, but now I think thick is the proper default. It should match your expectations. The other two styles can be provided using a client property.

Alan

On Dec 4, 2014, at 1:21 AM, Karl von Randow [email protected] wrote:

In your r2 branch, the split panes are looking a bit funky - I'm guessing it's work in progress.