From jrvalverde at cnb.uam.es Wed May 11 10:26:42 2005 From: jrvalverde at cnb.uam.es (=?ISO-8859-15?Q?Jos=E9?= R. Valverde) Date: Wed, 11 May 2005 16:26:42 +0200 Subject: ACD suggestion Message-ID: <20050511162642.5da55393.jrvalverde@cnb.uam.es> This is to suggest an addition to ACD datatypes: I'm looking for an easy way to allow users select among a list of choices that may vary across different versions of the program (for an embassy package) but the same happens for options that may change from installation to installation (like, e.g. the list of available blast or fasta datasets) and even time to time. The idea I come up with is a 'dynlist' datatype: it would work much like a list, but would obtain the choices from a directory listing somewhere or from a file. This way, one would define e.g. dynlist: params [ required: Y min: 1 max: 1 header: "Select Force Field" values: "/somewhere/params/*.prm" showpath: Y info: "Force Field parameters to use in the computation" ] or ... values: "@/somewhere/params/FILE" ... to use the contents of FILE as the options listing... Then, on running the user would get a listing of options, possibly stripped of the path (e.g. with basename(3)) and choose whichever he wanted. ACD would return the selection to the program (possibly with the pathname stripped if so requested). This is akin to GUI OpenFile routines which list a series of files and let the user choose, hence it may have more applications than suggested. But, at any rate, it simplifies handling of these kind of datafiles that may experience high variation. Alternately, it might be nice to have a way to plug-in to emboss.defaults, allowing programmers to retrieve preferences/option lists from it. But this I find more problematic. j -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.open-bio.org/pipermail/emboss-dev/attachments/20050511/e87cceb9/attachment.bin From pmr at ebi.ac.uk Wed May 11 10:45:48 2005 From: pmr at ebi.ac.uk (Peter Rice) Date: Wed, 11 May 2005 15:45:48 +0100 Subject: ACD suggestion In-Reply-To: <20050511162642.5da55393.jrvalverde@cnb.uam.es> References: <20050511162642.5da55393.jrvalverde@cnb.uam.es> Message-ID: <42821A9C.6040104@ebi.ac.uk> Jos? R. Valverde wrote: > The idea I come up with is a 'dynlist' datatype: it would work > much like a list, but would obtain the choices from a directory listing > somewhere or from a file. This way, one would define e.g. > > dynlist: params [ > required: Y > min: 1 > max: 1 > header: "Select Force Field" > values: "/somewhere/params/*.prm" > showpath: Y > info: "Force Field parameters to use in the computation" > ] > > or > ... > values: "@/somewhere/params/FILE" > ... > to use the contents of FILE as the options listing... > > Then, on running the user would get a listing of options, possibly stripped > of the path (e.g. with basename(3)) and choose whichever he wanted. ACD would > return the selection to the program (possibly with the pathname stripped if > so requested). > > This is akin to GUI OpenFile routines which list a series of files and let > the user choose, hence it may have more applications than suggested. But, > at any rate, it simplifies handling of these kind of datafiles that may > experience high variation. > > Alternately, it might be nice to have a way to plug-in to emboss.defaults, > allowing programmers to retrieve preferences/option lists from it. But this > I find more problematic. This is very similar to the proposal I posted recently for codon usage files and genetic codes. We can add "resource" definitions to emboss.defaults and/or use some expression as the values field for a list or selection ACD type - it may not even need a new ACD dynlist type. The showpath attribute would be tricky - that is pathname specific, so would be better encoded as part of the values string. I would be very interested in any other suggestions and use cases. regards, Peter From jrvalverde at cnb.uam.es Wed May 11 14:26:42 2005 From: jrvalverde at cnb.uam.es (=?ISO-8859-15?Q?Jos=E9?= R. Valverde) Date: Wed, 11 May 2005 16:26:42 +0200 Subject: ACD suggestion Message-ID: <20050511162642.5da55393.jrvalverde@cnb.uam.es> This is to suggest an addition to ACD datatypes: I'm looking for an easy way to allow users select among a list of choices that may vary across different versions of the program (for an embassy package) but the same happens for options that may change from installation to installation (like, e.g. the list of available blast or fasta datasets) and even time to time. The idea I come up with is a 'dynlist' datatype: it would work much like a list, but would obtain the choices from a directory listing somewhere or from a file. This way, one would define e.g. dynlist: params [ required: Y min: 1 max: 1 header: "Select Force Field" values: "/somewhere/params/*.prm" showpath: Y info: "Force Field parameters to use in the computation" ] or ... values: "@/somewhere/params/FILE" ... to use the contents of FILE as the options listing... Then, on running the user would get a listing of options, possibly stripped of the path (e.g. with basename(3)) and choose whichever he wanted. ACD would return the selection to the program (possibly with the pathname stripped if so requested). This is akin to GUI OpenFile routines which list a series of files and let the user choose, hence it may have more applications than suggested. But, at any rate, it simplifies handling of these kind of datafiles that may experience high variation. Alternately, it might be nice to have a way to plug-in to emboss.defaults, allowing programmers to retrieve preferences/option lists from it. But this I find more problematic. j -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pmr at ebi.ac.uk Wed May 11 14:45:48 2005 From: pmr at ebi.ac.uk (Peter Rice) Date: Wed, 11 May 2005 15:45:48 +0100 Subject: ACD suggestion In-Reply-To: <20050511162642.5da55393.jrvalverde@cnb.uam.es> References: <20050511162642.5da55393.jrvalverde@cnb.uam.es> Message-ID: <42821A9C.6040104@ebi.ac.uk> Jos? R. Valverde wrote: > The idea I come up with is a 'dynlist' datatype: it would work > much like a list, but would obtain the choices from a directory listing > somewhere or from a file. This way, one would define e.g. > > dynlist: params [ > required: Y > min: 1 > max: 1 > header: "Select Force Field" > values: "/somewhere/params/*.prm" > showpath: Y > info: "Force Field parameters to use in the computation" > ] > > or > ... > values: "@/somewhere/params/FILE" > ... > to use the contents of FILE as the options listing... > > Then, on running the user would get a listing of options, possibly stripped > of the path (e.g. with basename(3)) and choose whichever he wanted. ACD would > return the selection to the program (possibly with the pathname stripped if > so requested). > > This is akin to GUI OpenFile routines which list a series of files and let > the user choose, hence it may have more applications than suggested. But, > at any rate, it simplifies handling of these kind of datafiles that may > experience high variation. > > Alternately, it might be nice to have a way to plug-in to emboss.defaults, > allowing programmers to retrieve preferences/option lists from it. But this > I find more problematic. This is very similar to the proposal I posted recently for codon usage files and genetic codes. We can add "resource" definitions to emboss.defaults and/or use some expression as the values field for a list or selection ACD type - it may not even need a new ACD dynlist type. The showpath attribute would be tricky - that is pathname specific, so would be better encoded as part of the values string. I would be very interested in any other suggestions and use cases. regards, Peter