On May 4, 2:21 am, Roedy Green <see_webs...@mindprod.com.invalid>
wrote:

Verified on 10.5, Safari 3.0.4, up-to-date Java 1.5.0.

If you mean "the JAR is inside a ZIP file":

- download the ZIP.  Safari will, by default, unzip it for you; if it
doesn't, the ZIP file will be in ~/Downloads (10.5) or on the Desktop
(10.4 and earlier).
- double-click on the JAR to run it.

If you mean "the JAR itself needs to be unpacked":

- fix your build :)
- download the JAR.  Safari will, by default, place it in the same
locations mentioned above.
- open Terminal.app (/Applications/Utilities/Terminal).
- cd ~/Downloads # for 10.5
or cd ~/Desktop   # for earlier releases
- jar xf [name of JAR file]

The shell on a Mac is bash (in 10.4 and later releases) or tcsh (in
10.0 through 10.3); all of the usual shell-isms and unix-isms are
there.  Relying on GNU quirks (like expecting 'rm' or 'cd' to accept
options at the end of the line) is unwise; it often won't work as the
core utilities are derived from the parent BSD code.

-o

Define "scrambled".

On my Mac, I get the same results, whether I run the applet in Opera or  
Safari, or run the standalone JAR file.  It's not what I'd call  
"scrambled", but it's not right either.

I don't have the time, and possibly not the experience, to try to debug it  
myself at the moment.  But I can describe what I see.  Basically, the UI  
is presented in a window of a specific size, and the components in that  
window appear to be laid out from the bottom up, exceeding the size of the  
window.

In other words, I (mostly) see everything at the bottom of your layout, up  
to the "PST" line of the tool.

Interestingly: in both Opera and Safari, until I scroll the window  
containing the web page, the contents of the tool are actually laid out  
such that the top part is visible.  It's only as I scroll down that it  
winds up reflowing.

With the standalone, it's wrong from the outset, but I can easily resize  
the window so that everything shows.

I can email screen shots to you if you like.

OS X is basically Unix, and yes...there's a command line.  However, the  
GUI understands ZIP and JAR files.  Double-clicking either will "do the  
right thing".  ZIP files get decompressed into a new directory in the same  
directory where the ZIP file is stored.  JAR files will be executed as if  
you typed the java command line (though of course without any of the  
command-line options that can't be set in the JAR file itself and which  
might have been typed on the command-line).

IMHO, whether things wind up using up more pixels on the Mac or not (and  
frankly, this isn't typically an issue), it's bad behavior for the tool to  
be reflowing the components in the window such that they aren't visible in  
the window.

I'm less familiar with how Java applets work, but it seems like a bad idea  
to hard-code the size of something that's not a plain bitmap image in a  
web page.  There are too many different ways for rich text to not be the  
same size on different clients than on yours.  Surely there's a way to  
allow the applet to be sized according to its own needs.

As far as the standalone version goes, that seems even worse since you're  
not constrained by a browser window or anything like that at all.  The  
Java frame should just be sized to accommodate the components contained  
within.

Maybe there's something else going on here that I don't understand, but if  
this is really just a case of you specifying some hard-coded size for the  
presentation, that's just not appropriate, especially not in a  
cross-client/cross-platform environment like Java.

Pete

I see the same thing in the applet, the applet launcher, and the
application: the instructions JLabel is filling a tall, narrow column in
the bottom, center of the window. This forces other components up, until
pstLabel/PST is at the top of the content pane. Commenting out the
corresponding add() eliminates the problem.

It's an intriguing problem in GridBag sorcery, which is why I use nested
BoxLayout:-)

I followed the instruction on the download page, ignoring the "J:\" part.

Yes, we have a choice of shells:

$ cat /etc/shells
[...]
/bin/bash
/bin/csh
/bin/ksh
/bin/sh
/bin/tcsh
/bin/zsh

John