Ben Hague wrote: Hi!
>> VB is windows only, and distribution unzip, well at some point we'll end >> up with a ready to run Linux CD just to run Scid. The canonical tool >> would just be unzip for ZIP, but people might think using other >> compression tools. > > Well, looking into it further it does appear that TCL 8.6 will include > unzipping by default, if I understand http://wiki.tcl.tk/4610 correctly, > so any external program would only be short-term. I was thinking of > using unzip where it can be reasonably be expected to be found and > adding one where it can't. There doesn't seem to be a nice way to do > it. That could be a way. However, I'd not add unzip to the Scid distribution but a pointer where to get it. I'd add a stanza in the config which tells scid which unzip to use and a config dialogue where you can set it up. >> But, frankly, given the recent discussion about usabilty, which is >> mainly about some bitmaps and fonts, I don't think we have a majority if >> I tell the people that vi is a very nice gui for editing connector files >> of the above kind and that it is very easy, just set up the correct >> regexp. Especially, as Tcl seems a bit picky about escapes here as I >> recently learned. (I'd want a solution that allows this, but does not >> require it.) > > I wouldn't anticipate end-users ever coming into contact with this. Agree. > I'd envisage one central file containing all the definitions and the > end-user contacting a maintainer if they want a new site adding. Agree. I'd suggest to place this connector outside of Scid main tree so it can be updated without the need to update Scid. (Similar to say Endnote connection files.) > You might want a local file as well for some special cases but I would > imagine only a small minority of advanced users ever needing that. Probably a subdir of ScidDataDir can hold the local collection and Scid crawl trough it. >> Given we agree that we want such a fetch function, which I feel is the >> case, your suggestion is the way I'll do it. I'd just supply the above >> connector for a bunch of sites. I'm not sure about the usage of XML for >> the connectors, however. (I think it would be good but it also rises >> deps for Scid). But I'd suggest to supply the connector defs via Scid >> probably add a fetch function which gets the file in question from the >> Scid website if needs be. > > I would suggest XML because it gives more flexibility. Perfectly agree. It's just that for whatever reason the Tcl/XML-lib dropped out of some distributions for a time appeared back so status was a bit unclear here. And this is why I'd not require it as long as possible to avoid it. > I.e. if some other program wants to use it as well then it should be much > easier if > it's in a standardish format. Agree again. I see we've very much the same ideas. > Also, there's a chance of an XML parser > being built into TCL It is actually, based on the standard parser. As far as I got it the main problem is that Tcl is not really a mainstream language (anymore?) > which there isn't if we use our own format. Agree. However, it can be quite simple to parse as well, if you have a look at Scid config. Anyway, XML also eases up some coding quite a bit as well. I'll try to contact Mark if it's ok to hook up Twic and start working on the issue. I've also some other sources in mind and am in contact with one of the site owners already. -- Kind regards, / War is Peace. | Freedom is Slavery. Alexander Wagner | Ignorance is Strength. | | Theory : G. Orwell, "1984" / In practice: USA, since 2001 ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Scid-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scid-users
