http://java-ace.svn.sourceforge.net/viewvc/java-ace?revision=316&view=revision
It's a big changelist. And I'm not done yet.
Jace has two things in-flight right now:
1) All modal dialogs are managed internally so that they don't have to be shown as pop-up windows. What that means is that the UI can be easily re-adapted to a format that doesn't allow popup frames, such as a Java Applet. The Jace application (app) will continue to use pop-up windows as it does today. But internally, they are now controlled in one place and that can change depending on if the program is running as an App or as an Applet.
The majority of re-coding needed for this to work is done and included in this commit -- the work of creating an actual applet is pending and not started yet, but it's not really a horrific amount of work compared to other things I'm trying to finish.
2) Media management. It's a monster. And now there is enough UI bits and pieces that if you were to compile this thing you'd see it start coming together but it's not yet useable yet -- there are still more bugs than there are features and not everything is hooked up. Is this a bad thing? Well, no not really because you have to consider things in the scale that I'm building them. I had to check it in because it's been aging on my drive for a couple of months and I really don't want to lose any of it.
First of all, the concept of Media had to be rewritten in the emulator down to the disk drive implementations themselves. Media used to just be filenames passed around as strings. Media is now a full-fledged set of objects supporting useful metadata (name, author, year, publisher) as well as file snapshots (revisions, if you will). Revisions will be expanded later on, right now I'm just building in the internal hooks so that version/rollback (undo anyone?) can be implemented later on without having to break things all over again.
This all sounds extreme, but not really... the result is better than the mess it caused. Disk drives are all now media consumers, and they decide what types of media they can handle, be it a raw memory dump, a disk image or a HDV image. Having this level of flexibility means that the next part for inserting disks becomes much easier... read on.
The media management UI is what users will employ for swapping disks and so on. It allows browsing by name (broken down by alpha), also by category/subcategory, by author, by recently used, and also by favorites. So if you favorite something, it automatically goes into that bucket so you don't have to fumble around for it again. The layout is something like this:
/Local\________________
Tree Toolbar
..
.. Media Drives
.. Entries ..
.. .. ..
So the tree changes based on how you browse the media and might consist of categories, or letters (if browsing by name). Media entries will list only the media that corresponds to what you selected in the tree. Drives are all disk/hard drive devices you can drag/drop media to. The toolbar presents buttons for add, view/edit, delete and marking favorites
Inserting disks is performed by dragging the media entry (disk) on to the desired drive. The icons are exactly the same as the existing indicator icons that rolled out last year, so you see slot/drive info on the icon. As you drag the title over the drive icon, the drives that don't support that type will be greyed out. This simplifies things a bit. I'm totally open to suggestions on alternate approaches -- I haven't finished out the UI interaction for that part yet, but I do have a nice shiny drive list that is dynamically updated now.
I'm just finishing up the ability to add a new media entry. It seems to work, but there are bugs in the overall view still. One thing after another, and so on. But it is significant progress -- it required a lot of changes under the hood to carry it out and I'm glad that 95% of the emulation was not affected by this new feature.
So how can you help? Well, if you know Java and are not totally offended by my style of code I always accept patches. There are so many bugs and only one developer fixing them (me.) I am grateful to those out there who have beta-tested in the past and have been patient with my slow rate of bug fixes. I will get back to bug fixes once this new feature set has cemented a little and all the major kinks are out of it.
As always, I am totally open to discuss and prioritizing the next set of features in the pipeline. Being a one-person dev team means that ideas don't see the light of day unless I somehow just randomly dream them up. So it's nice to have had some conversations with a few folks about the future direction of things -- it helps me assert that I'm at least not totally crazy for doing this. :-D
Q: Why applets?
A: Because it seemed like a logical progression being a pure java app and all. Also JNLP would be nice too, so that people don't have to "install" the program to use it. Of course, if Oracle keeps screwing up java security I might just have to port the darn thing. Don't bet on it though.
Q: Why this big media manager?
A: My hard drive is a mess and I'm tired of digging for things. Also, this will eventually replace the haphazard media organization of Apple Game Server. If things go well, Apple Game Server will be absorbed into Jace at some point in time. Managing hundreds of images seemed like a good place to start for this eventual goal.
Q: Is there something you're not telling us?
A: Well, maybe. Depends on who's asking. ;-) All will be clear soon. There are a few surprise features.
Q: What do you do with donations?
A: That's a good question. It's primarily a morale booster. I use the funds to enhance my existing fleet of Apple // gear, build replacement cables, and amass parts for new hardware projects. It's easier to fund hobby projects from paypal donations that it is to petition my CFO for hobby project money. ;-)
Off to bed....
-Brendan