More screenshots. This long post is to explain the screenshots and tell y'all where I'm going, because I just did some work that makes it possible for someone to come in and do other stuff if they want.
I got kind of bored working on the map editor itself and kept thinking about how it'll look as a generic resource editor and decided to work on making it a generic resource editor. The two screenshots show it with two editors, the map editor and a generic editor. In the map editor screenshot, you'll notice two things. First, there's an extra toolbar at the top for map elements. Second, there's an empty space to the right of the editor. That empty space is going to hold a properties editor, where you click an item on the map and the properties editor will be filled in with all available properties for that item.
So, to make a new resource editor, you have to provide two things (only one of which exists right now), and optionally two other things. The two things you have to provide are a mechanism for creating new files (more later), and an editor, which could just be a reference to the existing generic editor. The two optional things you can provide are a toolbox widget (to go in that blank space on the right) and a list of QActions, which will be used to build a menu (not done yet) and a toolbar (done now). Since you provide these things, it should be easy for you to wire up the pieces to make the editor work.
Creating new resources will happen when someone clicks the new button (either in the menu or on the toolbar), and it'll popup a dialog listing known resource types. They'll pick one, and then a new tab will be created and the widgets used will be setup, and the resource data will be filled in with some reasonable default. I haven't worked out how this will actually work yet.
So, if anybody wants to jump in, here are the things that mostly need work.
* The buttons need to be wired up, including designing the "create new resource" feature I just mentioned. The only button currently wired is the "open" button. Wiring up the save buttons isn't so obvious how to do that. They need to tell the editor to save, and the editor needs to do it a certain way. Internally, python's minidom is used (but a larger dom library can be used if need be). I want resources to have dreamweaver's roundtrip feature, where anything in the file that the editor doesn't understand isn't modified. So when you're going to save a resource, you need to commit your resource to the dom somehow, then python's minidom will be used to render it to xml. For this, the path will be completely specified by the user. However, a "package" button needs to be created still that will save the file according to our filepath specification. If the file loaded was already compliant with the spec, then a prompt to change the version number should be provided if the resource changed.
* The generic editor needs syntax highlighting. Qt provides a QSyntaxHighlighter for that.
* The dom is very important here, and here's another reason why. Another feature I want is an "edit source" feature. So this task is about adding more abstraction. An editor should be added to a QStackedWidget instead, and a "edit source" button provided, and acme itself will use the generic editor to provide this. So when switching from edit source to the graphical editor (when available), the source needs to be committed and the graphical editor updated accordingly, and vice versa when going the other way. This opens up a third possibility, a dom tree widget.
* Parse the dtd files themselves to find out what a resource looks like. If we have a dom tree widget, this is pretty much required or else you can't build a ui for unknown resources (which you can do if you parse the dtd to find out what the resource is). It also allows the map editor and any other resource that someone has customized to support those customizations in a general fashion and still show a properties dialog that works. I consider making it capable of editing CTF maps to be a sufficient proof-of-concept here.
There's one more important thing here. Acme shouldn't have a graphics editor, music editor, etc. There are already good programs for that, no reason to make our own. But when we have resources that can contain many files, acme should support them somehow. But it should not support them by creating more tabs. In the UI you see in these screenshots, each resource gets one and only one tab, and it needs to stay that way. One of my pet peeves about Quanta as an html editor is that it doesn't obey this rule, so a tab means different things depending on what buttons you clicked. Here, a tab means a resource, and everything you need to edit that resource should be contained in that tab. It's ok for acme to launch external applications to edit files, or to create files, or whatever, but acme's representation of the resource should be in one tab and contain all files used in whatever fashion makes the most sense for the given resource.
I think that's it. Of course, if someone wants to hack on the map editor itself, they're welcome to it, or to make a cockpit editor (hint hint). Of what's in place now, I don't see anything changing that would effect the editors themselves other than allowing them to, you know, save their contents.
