That kind of thing has been suggested a few times, and in principle is a better way of doing things. One problem we face, is that we're a collaboration rather than a single project, and it is not always possible to adopt neat solutions across the suite. Which is partly why ccp4i was designed to be totally separate from the underlying programs.
I should stress that I'm not offering to do all the ideas raised today ;-) (I'm already behind on enough projects). But we'll try to fix a few things soon within the current ccp4i design. The other suggestions from today will go into the melting pot for longer term development (my plan b from earlier). But we do appreciate the ideas and feedback. Cheers Martyn -----Original Message----- From: CCP4 bulletin board on behalf of Peter Adrian Meyer Sent: Thu 5/10/2007 5:37 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] CCP4 GUI Hopefully my offhand remark wasn't taken as a criticism of ccp4i (it wasn't meant as such); but seeing as I don't use it, it's not a place where I could tell someone how to find an option. > As developers, we also have to think about long-term maintainability. > Options, in particular little-used options, can soon become out-of-date. This is might be a bad idea*, but I'll throw it out there anyhow: What about the storing program keywords in a grammer file (something along the lines of yacc/lex), reading gui options from the grammer, and generating a parser subroutine from the grammer for the data-processing programs? This would mean changes to the parser library (and to a large number of existing programs which already work), but would eliminate the issue of keeping the gui options in sync with the program options. Pete *specifically, bad idea type #2 - probably more trouble than it's worth Pete Meyer Fu Lab BMCB grad student Cornell University
