(cherry-picked to fixAppleCommander/AppleCommander#13 since I've
discovered that I was wrong and it does fix the problem after all!)
cwa.storage.Disk.FileFilter was written for SWT, returning multiple
extensions as a single string with ; separators. For JavaFX, we
actually want individual strings separately or in a list.
The only place these are initialized in cwa.storage.Disk anyway, so what
I've done is change the class to instatiate with separate strings and
join them on demand for SWT. A new getExtensionList() method will
return them as-is for JavaFX.
My fix for the unchecked warning in AppleImage.java was completely dumb
and I had no idea what I was doing. My understanding of how this works
is now greatly improved and the bug I introduced in 292afd2 is fixed.
If you don't request a specific GUI, we try SWT and then Swing. Okay.
But if you do, we don't even try to see if it works—we just assume SWT
works. If the user requested Swing, we just unconditionally spit out an
error message and try to start the GUI anyway. Let's make the errors
conditional on the GUIs being unavailable.
Note, a Swing GUI is available. It is just incomplete and doesn't work
very well. :)
In order to actually start the SWT-based GUI on macOS and have anything
start, you need -XstartOnMainThread. This is a Cocoa limitation. If
you have that (and we do now), you can pass the -swt argument and it
runs. (More than I can say for Linux using the non-integrated SWT
provided by Debian at the moment…)
What doesn't work is the open dialog. No files are selectable unless
you tell it to allow all files, and then .dsk files which the cmdline
jar file can handle fine are somehow an unsupported format. Uh huh.
That much at least should not be too hard to fix. Whether it works
after that is fixed, I cannot say. What I can say is that the problem
does not exist if you don't pass -swt, however the lack of a proper
Swing GUI means it doesn't really matter because you can't do anything
with the files once you've opened them.
The macOS zip file already was automated (though it should really be a
separate target in build.xml), and I have added a note about the
possibility of using Sean Riley's appbundler fork as an alternative to
jarbundler and the universalJavaApplicationStub shell script.
I went with the stub and jarbundler because Oracle has had a bad habit
of regularly changing and deprecating Mac bundling practices, but the
bundling of a JRE should make that a one-click (well, one-doubleclick)
solution for the end user. If the GUI app *worked* that would be a
strong consideration. It's not even a waste of diskspace on a system
using APFS if multiple copies of the JRE are on the system, if they're
the same JRE.
Also noted that CF card access as a raw disk is possible on Windows as
well.
Copy swt.jar to a directory in ${work} rather than ${mac.dir} as there's
no need for droppings all over the build tree. Also cleaned up building
${maczip} a bit to avoid extra file copying, to put the uncompressed
.app in ${dist}, etc. Removed some cruft from .gitignore while I was at
it.
The conditional nature of building macBundle kind of bothers me a little
since if you have the correct swt.jar (which we could provide and have
in some versions of the build system), you could build self-contained
packages for macOS and for Windows. A self-contained package for Linux
is also possible, but doesn't make much sense as Linux software
installation routinely involves installing dependencies, either manually
or automatically.
Rather than trying to use the Eclipse plugin version (which may never
actually work without building using Eclipse), I've changed the default
properties to prefer the all-in-one swt.jar packaged for separate
distribution. That isn't going to make SWT magically start working (of
course not!), but it's got the best chance of us being able to MAKE it
work in the future.
I've elected to put it in /Users/Shared/Java which seems to be the
correct place to put such a thing, but elected to use an unversioned swt
symlink, set up like so:
/Users/Shared/Java/swt@ -> swt-4.7.1a-cocoa-macosx-x86_64
I'm using the current stable release version, as you see here.
