Re: [Adonthell-devel] Editors & Recent Files

[James Nash]

My 2¢ below...
 
On 2 May 2011, at 21:47, Kai Sterker wrote:

> Yesterday I implemented a recent file list for mapedit, based on the
> functionality that is part of GTK+ since a couple of years now. Today
> I replaced my homegrown recent file mechanism in dlgedit with the new
> code.
> 
> That's fine and seems to work perfectly within the application. But
> I've also noticed, that the files you edit with the two will now
> appear in Gnomes global Recent Documents list. Unfortunately,
> selecting them there will not open them with our tools. So that
> grabbed my interest and I began to investigate a bit:
> 
> Provided we'd register a proper mime-type and an application to handle
> that type, we'd be able to start our tools by clicking on a data file
> or picking it from the global list. I went through the couple steps
> with dlgedit and have it working locally, but I am unsure if I should
> proceed. Here are the issues I see:
> 
> * 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.


> * 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.

- 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. I don't know about GNOME, 
but Symbian OS for example doesn't rely only on filename extensions but also 
examines files (typically the first few bytes for binary formats) to guess 
their type and find an appropriate app to open them. I suspect other OSes do 
this too, so having something like a DOCTYPE can be useful since it's easy to 
check.

- 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.


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

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?


> * How will it work on other linux desktops? KDE, and the numerous smaller 
> ones?

If we have unique extensions, mime-types and identifying marks in the files 
then I'm pretty sure there's enough there for any OS file-handling framework to 
work with. 


> * 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.


> * 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! :-)


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

                - James