bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] New Options menu


From: Jim Segrave
Subject: Re: [Bug-gnubg] New Options menu
Date: Fri, 17 Jan 2003 16:56:01 +0100
User-agent: Mutt/1.4i

On Fri 17 Jan 2003 (13:29 +0000), Joern Thyssen wrote:
> On Fri, Jan 17, 2003 at 02:04:41PM +0100, Jim Segrave wrote
> > 
> > Does Windows have an equivalent to /usr/share/misc/magic?
> 
> No, otherwise we would not have those discussion regarding whether gnubg
> should automatically add extensions or not!
> 
> > Is there a way to get a new magic entry distributed among Unices?
> 
> I'm curious about that as well, because I've would like to write an SGF
> entry.

Looking on google at a Linux man page (file.1), suggests that a
certain Christos Zoulas (address@hidden) seems to be
co-ordinating an RFC and a central repository of magic numbers. 

But, even if they aren't in peoples distributed magic database (which
on Linux and FreeBSD is then compiled using the file -C option), we
could install our own magic file just for games, screens, mets,
rollout dbs, etc in the gnubg directory. The file command on Linux,
Free/Open/Net/Bsd, and Solaris can be run with the -m option, which
allows specifying a magic file to be used, which need not be compiled
and whose location we will have chosen. So we could run a file command
from withing gnubg with a specified magic file without requiring root
to install an addition or having the magic numbers added to Unix
distributions.

Now more interesting would be to hack the source of file to make a
callable function which determines which files are of a desired type,
using our own supplied definitions. 

I noticed while googling that there is a Cygwin port of the file
command. Which suggests that it may be possible to actually build such
a tool. 

But all of this may be an enormous amount of work for little gain
(although getting additions to the magic file would be nice). 

How many file types are we interested in gnubg being able to
recognise? 
How hard is it to use the file command's most common approach of
looking at a few (16K in file's case) characaters at the start to
identify potential files of interest?

I assume for the moment we want to recognise the various importable
game/match formats, board XMLs, bearoff databases, weights files, and
met files.

Some of these already have identifiers - the bearoff databases, the
MET XML files. I've not looked at any match formats except .sgf, which
is pretty easy to identify (actually, exporting an .sgf to a .mat
tells me those are pretty easy to identify as well).

The board and met files can easily have an XML coment to make them
identifiable.

>From all this I would conclude that we could probably supply a simple
routine and a small set of rules which would allow gnubg to find
candidate files for importing games/match/session (any files which
appear to match one of the recognised formats), boards (any files
whose XML comment says it's a gnubg board file), mets (any files whose
XML comment says it's a met gnubg file), etc. There would need to be a
user option to say if the file list should be prunded this way, as it
would be very expensive in a big directory (or pointless for users who
save match files and only match files in a directory).

I haven't looked at how the current file selectors work, so I don't
know if you can point one at a path and give it a function to call to
decide if a file should/should not be put in the selector window. If
something like this is not possible, we could build our own scrollable
window which allowed selecting an item and clicking an OK button, but
this seems sub-optimal.

-- 
Jim Segrave           address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]