Re: [Adonthell-devel] Editors & Recent Files

[Kai Sterker]

On Tue, May 3, 2011 at 8:19 PM, James Nash <address@hidden> wrote:

>> * In order to work, the program must be installed (in /usr/local/bin),
>> but our tools have quite generic names. That's one of the reasons why
>> I have written the build system to not install the editors. We could
>> prefix them with adonthell or something, maybe.
>
> Sounds reasonable. Besides, if you can launch these by clicking files / icons 
> the actual binary name isn't all that visible anyway so it doesn't matter so 
> much if it's a bit long or ugly.

That is somethng I hadn't considered, but it's true. Guess I am too
entrenched in my set ways of launching stuff via the command line.
Besides, if I recall correctly, the launcher script for v0.3 was also
called adonthell-wastesedge, so why not adonthell-dlgedit,
adonthell-mapedit, adonthell-modeller ...

>> * In order to register a new mime-type, you need to be able to
>> uniquely identify the files. Dead simple for dlgedits .adlg files, but
>> what to do with mapedits .xml's? Use a different extension? Or add
>> some file magic?
>
> Since I started looking into the sprite XML files the other day I had some 
> thoughts on this that may also be relevant to this discussion:
>
> - So far we use a generic .xml extension. I was going to suggest we invent 
> our own extensions for them - if nothing else it makes it easier to tell 
> sprites, config files, maps etc. apart on the command line. I imagine this 
> will help with GUI file-handling too.

It would help alot and I was playing with that thought already. My
biggest gripe right now is that the engine uses the file extension to
determine the file format (XML vs. binary). It assumes that everything
ending in .xml is just that and all the rest is gz-compressed binary.
Of course, the easiest thing would be to peek inside the file as well.
We're going to open it anyway, so it's not a big performance loss.
Just requires a small code change.


> - Perhaps we should investigate adding a DOCTYPE, XML namespace or similar 
> (XSD?) to our files. Apart from being able to use tools like validators to 
> detect syntax errors and suchlike early on, it would also help for operating 
> systems that peak into files to determine their type.

It's what they usually call file-magic. GNOME does it too, though I'm
not exactly sure what takes precedence. So having a unique file
extension would still be preferrable. Although if the OS implements
this right, it should work regardless.


> - On related note: I think we should version the various formats for future 
> proofing. I can easily imagine that we'll extend or alter the syntax over 
> time to accommodate new features. Having something in the files that 
> identifies which version of the format they use makes it easy for our engine 
> and tools to handle them accordingly (or reject them if they're too old/new). 
> Additionally we could maintain tools/scripts to convert between versions (so 
> we can batch update existing files) and they could use this info to 
> automatically detect the input format.
>        - The XML files are obvious candidates for this sort of thing, but we 
> should perhaps consider it for other formats too.

The good thing about v0.4 files is that they all stored using the same
mechanism. There are just two different parsers/writers that will
either save XML or gz-compressed binary. Both formats are equivalent
and can be converted from one to the other without loosing
information. There's a python script in adonthell/test that does that.

Furthermore, all the data in the files is stored as key/value pairs,
so adding new data should almost always retain forward-compatibility.
I.e. older versions of the engine should be able to read newer data,
but they will not be able to use the newly added items. Of course,
when the structure as a whole changes, or items get removed or
renamed, then there is a problem.

As such, I would suggest the following versioning scheme: <major>.<minor>

A minor change means that older versions can still use the file. A
major change means that older versions can no longer use the file.

I.e. version 0.0 can use all 0.x files, but 0.5 can only use formats
from version 0.5 onwards.
Version 0.x cannot use formats 1.x. And so on. Would mean that we had
to bump the version in the existing files with every version change,
but that would be simple with a little script. I also would tend
towards having one file version across all our files (but separate
from the actual engine version), as it means more updating of files,
but less room for confusion. And the version checking code could be
centralised.


> In terms of mime-types, I guess we'd initially use ones like:
> application/x-adonthell-...
> text/x-adonthell-...
> etc.

So far I've got application/x-adonthell-dlg and
application/x-adonthell-map. Since the actual content could be either
binary or text, I'd go with that. Unless you'd suggest different
extensions for the two flavours.

> The added bonus of having these would be that, with a suitable web-server 
> setup, we could host such files on the web and clicking them in a web-browser 
> will open them in the correct tool on your computer :-) Maybe we can have a 
> web-based sprite & mapobject catalogue someday?

Sounds like a good idea :-).


>> * Will it work on all distros or break installation? All that is
>> required are the two programs "update-mime-database" and
>> "update-desktop-database". They were already present on my Ubuntu, but
>> what if they are missing? Make the registration an optional step of
>> the build (--configure flag)? But then might as well leave it away.
>> Who checks for non-standard configure options when installing stuff?
>
> Perhaps it's safest to make it optional for now.

I imagine it could be based on the presence of  "update-mime-database"
and "update-desktop-database". If both are there, they will be used,
if not configure will just print a little warning message or
something.


>> * What to do on Windows or OSX? Should be working fine inside the
>> application still, but certainly no integration into the OS. Is it
>> worth the extra work, to just have this working on GNU/Linux?
>
> I think it's enough if we focus on GNOME though. If other wish to contribute 
> integrations with other OSes that would be lovely though! :-)

Yeah, lets start with GNOME first. I don't even have a development
environment for Windows right now, and a hard time to get my hand on
contemporary hardware that runs OSX :-).

> So, does this mean I should start designing some icons for our tools & their 
> respective file formats? ;-)

Please go ahead! It'll work without specific icons, but it would
certainly lack style :-)

Kai