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 _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/adonthell-devel