Building Anathema on a Mac

[wordman]

I'm in the process of building Anathema from source on the Mac. Inevitably, there will be weird little hurdles to jump. I thought I'd log them here.

 

[wordman]

First problem is that Eclipse doesn't have native Subversion support.


Fixed by grabbing Subclipse.


As a side note, I hadn't run Eclipse on my PowerBook for over a year. It is now significantly faster than it used to be, probably due to a much faster VM.

 

[wordman]

After playing with a number of ways to checkout the projects, the way I wanted to do it (with one "anathema" folder in my workspace, with all the projects inside it) doesn't work.


I ended up creating an "anathema" workspace and checking out all the projects to it. You can just select them all at once.


One oddness here is that the "Lib_Gui" project got checked out with the name "LibGui" for some reason. Since nearly every other project uses this one, this caused massive compile problems.


I deleted "LibGui" and checked out "Lib_Gui" again, forcing the name to "Lib_Gui". I imagine there is a reason for Eclipse deciding to eliminate the underscore in this one project alone, but I didn't bother to find out what it was. Probably in the .project file somewhere.

 

[wordman]

Now down to 9 errors, 91 warnings. The errors stem from two projects relying on a JDEMO_HOME classpath variable that doesn't seem to be defined. This will probably turn out to be easy to correct, but I have to go to work. More later.

 

[Thorn Darkblade]

I'm in the process of building Anathema from source on the Mac.

You're my hero,

 

[wordman]

These two articles are probably going to come in handy. And this one.

 

[UrsKR]

Inevitable comments from my side:

As a side note, I hadn't run Eclipse on my PowerBook for over a year. It is now significantly faster than it used to be, probably due to a much faster VM.

The eclipse guys did their part, too, at least if their benchmarks are to be believed.

Now down to 9 errors, 91 warnings. The errors stem from two projects relying on a JDEMO_HOME classpath variable that doesn't seem to be defined. This will probably turn out to be easy to correct, but I have to go to work. More later.

JDemo is a framework for Gui-Demonstrations, as an alternative to cleaning the path-entries you can get the framework at http://www.jdemo.de.
Warnings, as you probably know, depend on your personal settings. I'm currently at 250. Which is about 220 more than I like to have.


200 of them tell me that I hardcoded text into the sourcecode instead of using proper internationalisation. As long as your the program runs fine, don't bother to resolve them.

These two articles are probably going to come in handy. And this one.

Precisly those were the ones I was referring over in the SI-thread.
Thanks for your efforts, I'm interested in hearing how it all turns out. When you're done, could you post some screenshots?

 

[wordman]

As predicted, the JDEMO_HOME problem was solved easily by downloading and installing the Eclipse plugin from the JDemo site. (They don't have a decent site.xml file, though, at least that I could see, so you have to install manually).


Once built, the code I checked out a few days ago looks like this:

 

[wordman]

Checking out the latest code contains changes to use the Aqua look and feel. Building those results in the app looking like this:

Various oddities with this look are:

1. Custom tab control doesn't use an Aqua appearance
   
2. Menus appear in window instead of menu bar, and the font metrics are slightly off.
   
3. Application name in menu bar is main class name.
   
4. Fonts in main pane on the larger side.

 

[wordman]

Adding the following VM options to the "Anathema" run set:


-Dapple.laf.useScreenMenuBar=true


-Dcom.apple.mrj.application.apple.menu.about.name="Anathema"


Makes the menu bar look a bit better.

Some Mac specific changes that would be needed to the menus:

1. The programs "Anathema" menu looks odd next to the one generated by OS X. A more Mac-like title for this menu would be "File". This menu should also have "Page Setup…" and "Print…" items.
   
2. Key bindings are missing or use control key instead of command key.
   
3. Names for options that open dialogs are missing ….
   
4. "Exit" menu item can be eliminated, as standard Quit item in the OS X generated "Anathema" menu (called the application menu).
   
5. Standard location for "Preferences…" on OS is in the application menu.
   
6. Missing a standard Mac "Edit" menu (Cut, Copy, Paste, etc.)

 

[wordman]

By the way, I'm not sure what the "Pariphrase" field is for, but the correct spelling is "Paraphrase".

 

[UrsKR]

Thanks for posting screenshots! It's good to know my changes had some effect at least. Do  you consider them an improvement, too, or should I undo them?


For all the things you adressed, if you find a way to change them in the code without breaking too much, I'd be glad to receive your submissions.


In the following comments, whenever I say "I don't know" or "I won't", it means exactly that - I will not.


It doesn't mean that I don't want the program to support it if anyone knows how to do it and does it himself or explains it to me.


Comments


Do you know whether the properties controlling the screen menu bar can be set at runtime? If so, it shouldn't be hard to include some code to do it.


The custom tab is, well, custom. We use it mainly because it allows to add a button to close it. They have a webstart demo available at http://www.infonode.net/index.html?itpdemo, complete with adjustable L&Fs. If you find anything in there that looks more Mac to you, I'm sure there is a way to change it in Anathema.


Does anyone here know whether this function, as offered by "Substance" look and feel (https://substance.dev.java.net/), can be used while using a standard Windows or Mac L&F?


I believe, though, that the Swing Tabbed Pane in Java 6 will have a similar function, so we might kick the custom one altogether.


I have no idea what to do to improve the font without breaking the entire program on other OSs. Can one set a general default font for all newly instantiated components?


The "Anathema" menu name I've grown oddly fond with - it's an issue for windows users, too. It looks especially odd in this case.


Hm, maybe we could use another internationalization for the menu based on the OS running.


I don't believe that we're (as in "the core team") are going to do it - sounds a bit too complex/specific -, but  what should the "Page Setup" item do?


Also, as I'm not familar with the notation: The "…" item you keep mentioning is something akin to an ellipse ("...")? It's a good point, I've made a note.


As for the remaining menus and the redistribution of items between them, I am not sure this is supported by our current infrastructure. And I don't have a clue how to put things in an OS X generated menu.


I believe the matter of adjusting the (few existing) key bindings to use the command key instead of control was adressed in the series of articles you linked to.


Finally, you're off when it comes to the "periphrase". It's a figure of speech.


I'm off, too. It's spelled "periphrasis" in english. And the field is used only when you print the "character description".


Now, thanks for all your effort. As said in the introduction, if you're interested in improving the user experience on the mac (by changing code, building an application package, anything you can think of), please do.


Bye


-Urs

 

[wordman]

Do you know whether the properties controlling the screen menu bar can be set at runtime?

I'm pretty sure you can programattically override -D options, but I'm not positive. System.setProperty("apple.laf.useScreenMenuBar", "true");, I think, though you probably need to set it early.

what should the "Page Setup" item do?

This is a Mac-ism that basically opens the print driver's preferences dialog. It tends to be the same for every application, because it's a driver-based thing. Chances are there is a two line way of doing this in Java.

The "…" item you keep mentioning is something akin to an ellipse ("...")

The … is the HTML entity for the elipsis (...). I guess the forum code doesn't translate these.

 

[UrsKR]

I've added code for the menubar properties. Could you give it a try?


Also, there is another series of articles, this time dedicated solely to the Mac:


http://java.sun.com/developer/technical ... JavaToMac/


http://java.sun.com/developer/technical ... avaToMac2/


http://java.sun.com/developer/technical ... avaToMac3/


It's quite interesting and shows how to adress some more of your issues. The changes they make to the code are too direct for my tastes, but they outline what to do.


In the third article, they talk about a program to create ".app" folders for Java applications, and show a program "Jar Bundler" which does this automatically. The screenshot shown has an option to improve the fonts used, maybe there is a system property for this, too?


I couldn't find anything about the Page Setup.


I'll adress the "File" menu next time, and have a look at moving "About" and "Preferences" to the application menu.


Do you know what to do to use the command key for key bindings?

 

[wordman]

BTW, I'm using XCode to assemble the latest production version (0.10, plus patch) into a double-clickable Mac app. I did this with 0.9 with no problem, but my five-minute effort with 0.10 last night had a problem of some kind. Once I get it working, I make a .dmg out of it. UrsKR, if I mail you a private link to it, could you host the download on SourceForge? (I go by 'wordman' on Source Forge as well, btw.)


Edit: I've never heard of Jar Bundler. Looks slightly easier than the XCode method (which is not particularly difficult). When I get home, I'll see is this is still in the dev tools, or if they ditched it in favor of XCode.


Actually, might just be easier to use Ant eventually. I should be able to create a build.xml file that will create the .app bundle on any platform. Not that you can create a .dmg to release it, but still.

 

[UrsKR]

but my five-minute effort with 0.10 last night had a problem of some kind.

Using current development code or the released version? Dev. code can have compile errors at times.

Once I get it working, I make a .dmg out of it. UrsKR, if I mail you a private link to it, could you host the download on SourceForge? (I go by 'wordman' on Source Forge as well, btw.)

Of course you do, I know who you are. As far as the 'net permits, that is.
If you get it done, I'll host it for sure.


If you create an Ant-Task to bundle the .jar into an .app, even better, I'll include it into the regular build process and upload it whenever we release. (This would depend on your feedback, of course, as you know I cannot ensure these things are working.)


Contact me anytime, you'll find my email-address on the Anathema website.


Can you explain the difference between the .dmg and the .app? I thought that an .app was all it took to run java programs like "native" applications on Mac OS, while .dmg appears to be another kind of archive (according to Google). Is .dmg the format most commonly used on Mac OS?

 

[wordman]

Using current development code or the released version? Dev. code can have compile errors at times.

The released version. Less hassle.

Can you explain the difference between the .dmg and the .app?

Your understanding of .app is correct. A .dmg is a disk image. Essentially, you double click it and it "mounts" like a read-only hard drive. This makes them convenient for distribution. Other reasons that make them the preferred method of delivering Mac apps is that a) they have built-in compression, so no need to unzip, untar, etc. and b) they transfer clean over the internet. Some Mac files have multiple "forks" that really confuse other platforms, which tend to ignore and strip them. Usage of such files isn't nearly as bad as it used to be, but the .dmg format wraps all of this stuff up so you don't have to care either way. Linux people might think of a .dmg file as sort of .tgz file that hides some funky encodings and also contains a visual representation of how folders and files look when opened in a window (with background art). It sounds a little bizarre, but once you use it a couple of times, delivery mechanisms like .tar and .zip -- and especially installer applications -- become irritating.


Generally, once you have a .dmg file built, the user downloads it, opens it, watches the exact window that you want them to see open. Then they drag the (usually) sole icon in the window to their Applications folder (or wherever). Installation complete.

 

[UrsKR]

Sounds neat. I envy you.


I guess, the only existing platform with a better distribution format would be the Super Nintendo. :roll:


You said that I couldn't build .dmgs in Ant. Is this due to my choice of platform, or is there no Ant task to do it?


How do people build them?


Everyone's open-source poster child Azureus distributes .dmgs for OS X, maybe we (you, if it's mac-exclusive) could have a look at their algorithms.

 

[wordman]

You said that I couldn't build .dmgs in Ant.

I didn't mean to give that impression. It's possible to build the proper directory structure for an application bundle with Ant. As far as I know, however, there are two steps that can only be done on a mac.


The first is a "blessing" of the application directory that turns it into an app bundle. This requires a command-line tool from the Mac Developer Tools. Actual command is:


/Developer/Tools/SetFile -a B ${appdir}


The second is the creation of a .dmg. To my knowlege, this can only be done with a Mac OS X GUI app called Disk Utility. There may be a command line way to do it, but I don't know of one. Only takes a couple of seconds to run this on a directory, though. So I can build them if necessary.

 

[wordman]

I've managed to assemble a version of version 0.10 (Patch 1) into a mac app, and have sent versions to UrsKR for distribution. This sreenshot doesn't show the cursor hovering over the dock icon, but it is. Looks like this:

 

[UrsKR]

Impressive, thank you.


I've uploaded the files to SF.net for the general public. I hope they are working without problems, but I trust they will given Apples reputation.


I'm busy with things right now, so the File menu has to wait for a while.


Regards


-Urs

 

[wordman]

It's been a while since I posted here. I have not been working on further "Macifying" meuns and such for Anathema. For the one or two that may care, this is why. A slightly less inflammatory versions here and here. Either way, it means I haven't been able to meaningfully compile the code for quite a while.


Note that it is likely that Java 6, even once it is released, will only be available in Leopard. Not sure how this will (or should) affect Anathema on the Mac.

 

[UrsKR]

I hope there won't be any problems running our Java 6 code with Apple Java, but I am more than willing to help fixing the problems that come up.


Will you upgrade to Leopard once it's available?


As for your parting remark, I'll keep compiling against Java 5 and leave the code that hides the Java 6 API in place, so older versions of MacOS should continue to run Anathema just fine for the time being.

 

[wordman]

It appears that Apple's strategy (if you can call it that) for Java 6 is even more irritating than expected. They have finally released a "gold" Java 6 version, but it not only requires Leopard, it requires a 64-bit Intel processor. So, it appears that Apple will make Java the first technology that completely abandons their PowerPC architecture.

 

[Flagg]

Hooray for closed source proprietary software!