Please create an account to participate in the Slashdot moderation system


Forgot your password?
Trust the World's Fastest VPN with Your Internet Security & Freedom - A Lifetime Subscription of PureVPN at 88% off. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×
Programming Businesses Apple IT Technology

Tuning Java Swing apps for Mac OS X 37

tarkin writes "Sven Van Caekenberghe just finished a tutorial article, 'Tuning Java Swing applications for Mac OS X', that explains how to tune standard Java Swing applications to conform to the Mac OS X User Experience and make them virtually indistinguishable from native Mac OS X applications. Topics include handling basic Apple events, packaging applications, adding a custom icon, file dialogs, about boxes, preferences, customizing the menu bar, supporting Finder drag-and-drop, standard help, and basic multi-document support, as well as using MRJToolkit and MRJAppBuilder. The PDF of the article, as well as a Mac OS X disk image with a binary version of the two demo applications and the source code can downloaded from his home page."
This discussion has been archived. No new comments can be posted.

Tuning Java Swing apps for Mac OS X

Comments Filter:
  • by L. VeGas ( 580015 ) on Wednesday October 09, 2002 @01:10PM (#4418026) Homepage Journal
    Isn't that an old Count Basie song?
  • Not bad... (Score:4, Informative)

    by NetRanger ( 5584 ) on Wednesday October 09, 2002 @01:22PM (#4418135) Homepage
    Swing is much easier to create useful applications with; it's good to see that someone is helping go it cross-platform to the Mac, to where it makes sense with the system paradigm. Unfortunately the controls in the standard Swing package look a little too much like Windows 9X.

    Perhaps the next thing we need is skinnable Swing? :-)
    • Re:Not bad... (Score:4, Informative)

      by smileyy ( 11535 ) <> on Wednesday October 09, 2002 @01:46PM (#4418346)
      You mean the different Swing look-and-feels? Already done.
    • by BoomerSooner ( 308737 ) on Wednesday October 09, 2002 @01:58PM (#4418455) Homepage Journal
      For my apps (that are cross platform) I build the classes in java and the UI in whichever platform I'm using. This allows each program to look good on the intended platform. For Apple Cocoa (java) programming via the Interface Builder is a wonderful tool (and free to boot!). However, I'm not a big fan of Swing. It is very unresponsive on even the fastest systems and even though working with a program can be just as efficient, as all Mac OS 9 users can tell you OS X doesn't "feel" as fast. That is the perception of Java based programs (that aren't native compiled), they are just slow. Sun should really consider a non-backward compatible new set of UI components because Swing was just kiss and make up for AWT (painful beast). I hate the layout managers and building your own, while it is an option really doesn't help in quick development.
      • SWT? (Score:2, Interesting)

        by smileyy ( 11535 )
        What about SWT, as used in eclipse []?
        • More details? What is it a layout manager?
        • I could download and install Borland JBuilder and build and run their sample apps without breaking a sweat.

          I have given up on the Eclipse IDE -- the checklists for downloading samples are all two pages long, their menus and dialogs are all non-standard, and I have not yet figured out what options to specify to actually run any of the samples I have built.

          Is it just me or is Eclipse just impossible to figure out? I have used (for C++) everything from Code Warrior to Borland to VC++, but Eclipse has me completely stumped. I suppose I could figure it out if I devoted a couple weeks to it, but I just don't have that kind of time to evaluate something I am not sure is of any use.

          As to the SWT, isn't that the kind of thing Microsoft got sued for?

          As SWT is tightly coupled through JNI to the target system, you have to distribute a .DLL (some kind of extra software blob) with your SWT app for every possible target system. Yeah, yeah, AWT/Swing has to eventually call something native, but those customizations are part of the Java runtime you install for each target system, not some extra blob that you need to distribute.

          Also, SWT is much more complete on Windows while the Linux version is "in progress" and the OS-X version is a distant dream. Now isn't this kind of write-once, run under Windows just the thing Microsoft got sued for?

          • Re:Eclipse? Feh! (Score:2, Interesting)

            by smileyy ( 11535 )

            eclipse took me a small amount of time to get used to, but to me, its the best Java IDE on the market. Of course, the availability of refactoring is the bar to clear to even enter the competition, so that limits things a bit. JBuilder blows goats in comparison. My recommendation would be to create your own project in eclipse and start using it, rather than using sample apps.

            To be fair, I haven't tried eclipse for Mac OS X, but all new builds of the 2.1 series are being created for Mac OS X as well, including the stable Milestone 1.

            Is it the same as what Microsoft did? I don't think so. I'm pretty sure you had to use MS's JVM to run Microsoft "Java". SWT will work with any JVM, provided the appropriate native libraries are installed. I am a little disheartened by the limited number of alternate platforms available, but more keep coming. Give it time.

    • Perhaps the next thing we need is skinnable Swing? :-)

      I think you typo'd here. Surely you meant to say, "the last thing we need is skinnable Swing."
      • java ... skins ... (Score:2, Interesting)

        by Unordained ( 262962 )
        Isn't part of the aim of Java apps not to know too much about their environment? Maybe I'm only thinking of Java applets, but it seems that if you're going to build stuff in Java, to run in a VM, you should be hoping for the benefit of cross-platform compatibility, not your ability to fake the look and feel of an OS you could have programmed natively for, in, say, C or somesuch. If it's going to be Java ... at least don't force it to look like it was built for only one platform. If MacOS users -really- hate your application because it doesn't look like everything else ... well ... KDE vs. Gnome users can just say "welcome to the club!" ...
  • by anarkhos ( 209172 ) on Wednesday October 09, 2002 @04:59PM (#4420035)
    The best advice I can give Mac OS X users who want to run a Swing app is to change the default L&F to something other than Aqua.

    Swing apps are incapable of behaving like Mac apps. Thus using the Aqua theme for Swing apps is the absolute worst possible combination!

    One of the key reasons Swing apps will NEVER behave like Mac apps is the Java file primitive. The misnomer File class should really be called FilePath. Since (100% Java) Swing apps use file paths as file primitives this implies that file paths are constant. Thus if you move/rename an open file (or host directory/non-root volume) the Swing app will become confused.
    • by Molz ( 87066 ) on Wednesday October 09, 2002 @06:08PM (#4420433) Journal

      One reason for using the Aqua L&F, though, is that it is better optimized for OS X. Try running a complex application in Metal on OS X and again in Aqua. In my experiance the difference was quite aparent. You have a point though that the feel of java apps on OS X is still not quite right, but using Metal isn't any better (it just makes things more ugly).

      Cocoa apps have the same file path problem. NSDocument based apps now use FSRef's as well as NSURL's so they don't, but if you write a Cocoa app that doesn't use NSDocument, its up to you to do the FSRef magic you need to track files based on their HFS+ id number.

      • The advantage of using a non-Aqua theme for Swing apps is you don't get confused. You see a Metal app you expect Swing behavior, then you see an Aqua app you expect Aqua behavior.

        Your assessment of Cocoa apps is correct except I would add that FSRefs also work on UFS volumes (and probably others) with the one caveat that you can't pass an FSRef to another process.

        What Apple ought to do is what they did with the Toolbox more then a dacade ago which is to say deprecate functions (methods) which use file paths as arguments. Instead they ought to use something equivalent to an NSFSRef as a simple file primitive. They should also revise the Aqua HI Guidelines to clarify the behavior of "Save" and "Revert" to reflect the proper Mac behavior which can currently be had by using NSDocuments or FSRefs. They should also clarify that a file's path is variable, not constant.

        Ironically Swing apps behave more like Cocoa apps in at least one aspect: the behavior of text views. NSLayoutManager doesn't behave correctly. For example selecting down on the right side will select the trailing linefeed of the last line selected which doesn't follow the Mac convention.

        Unfortunately these problems are NOT going to be fixed unless more people send Apple feedback and bug reports.
        • Your assessmeYour assessment of Cocoa apps is correct except I would add that FSRefs also work on UFS volumes (and probably others) with the one caveat that you can't pass an FSRef to another process. nt of Cocoa apps is correct except I would add that FSRefs also work on UFS volumes (and probably others) with the one caveat that you can't pass an FSRef to another process.

          Last I heard that on non HFS(+) file systems, FSRefs revert to using path names rather than a file ID, since file ID's don't really exist on UFS (there are inodes, but still not quite the same). Assuming they are still implemented this way they don't provide the same features that they would on HFS(+), but atleast they don't break completely. (and if I am wrong on this, feel free to correct me.)

          Ironically Swing apps behave more like Cocoa apps in at least one aspect: the behavior of text views. NSLayoutManager doesn't behave correctly. For example selecting down on the right side will select the trailing linefeed of the last line selected which doesn't follow the Mac convention.

          It's a behavior left over from NeXT. I prefer the old Mac way of selecting, but it would be great if they would atleast unify it to one or the other.

          • You're wrong.

            FSRefs are an arbitrary 80 byte runtime reference for a file. For HFS+ it may per chance be comprised of a volume name and FileID but that's completely irrelevant because you're not supposed to store FSRefs and with Mac OS X not supposed to pass them to other processes. With UFS, FSRefs behave exactly the same as HFS+. I don't know the internal structure of the FSRef in Mac OS X w/UFS, but I really don't care either. It currently works.

            You're probably thinking about Aliases in which case you would be correct. Aliases are anarbitrary description of how to find a file and on UFS volumes they break like symlinks, which again follows the specification. You can make Aliases on HFS+ volumes which also break like symlinks, just store the path and use null for the FileID and host FolderID.

            As for selection I find the Mac selection behavior by FAR superior since 19 times out of 20 I don't want the trailing linefeed and when I do I can always add it after pasting (or dragging) by pressing return. The problem is even worse if you try drag+drop text. Even if you removed the insane delay, the linefeeds would get in the damned way.

            Apple did change the selection behavior slightly in 10.1 so selecting to the right would be less annoying (it used to be like a bloody Windows app) but it still falls short, and selecting down wasn't imrpoved at all! They also reduced the delay for dragging text in 10.1 which didn't make any more or less sense than the delay in the first place. I swear the AppKit developers just do this to tease me, what other explanation is there?

            What they ought to really do is implement the best of both worlds, and also add some standard cursor icons so you know whether you're hovering over a draggable item like selected text. This would eliminate a lot of the confusion former NeXT-heads had.

            Anyway, file some bug reports |-)
  • by Anonymous Coward
    It will be slow.

    No point trying to dress it up ;)

Prediction is very difficult, especially of the future. - Niels Bohr