Hi again jalviewers. I have one wish for the next version that would make a _huge_ difference for the way at least I am using Jalview. That would be an option to use copy the sequence raw instead of as fasta. The reason is that while analysing alignments I wish to check parts of the sequence in a host of other tools and sometimes fasta format is good, more oftenthe applications puke on it.
For my part the best thing would be to use ctrl-c for raw copy and ctrl-shift-c for fasta copy. This is of course not a good idea as a default for jalview since that would not be backwards compatible but one could always wish for two additions: raw copy on ctrl-shift-c as default and a checkbox in preferences to swap the two copy variants...
As of now I am actually using MEGA in parallel with jalview just for this reason, quite inefficient but stripping out fasta headers all time was even worse
This e-mail, inclusive of attachments, is intended for the person(s) or entity stated above and may contain confidential information. Unauthorised reading, disclosure, copying, distribution or use of this information may violate rights to proprietary information. If you are not an intended recipient, please return this e-mail to the sender and delete your copy. Thank you.
Hi again jalviewers. I have one wish for the next version that would make a _huge_ difference for the way at least I am using Jalview. That would be an option to use copy the sequence raw instead of as fasta. The reason is that while analysing alignments I wish to check parts of the sequence in a host of other tools and sometimes fasta format is good, more oftenthe applications puke on it.
For my part the best thing would be to use ctrl-c for raw copy and ctrl-shift-c for fasta copy. This is of course not a good idea as a default for jalview since that would not be backwards compatible but one could always wish for two additions: raw copy on ctrl-shift-c as default and a checkbox in preferences to swap the two copy variants...
As of now I am actually using MEGA in parallel with jalview just for this reason, quite inefficient but stripping out fasta headers all time was even worse
I'd vote for having a preference (or something) for what jalview uses to copy the data to the clipboard. The application doesn't even touch the clipboard when copies occur internally so internal compatibility for the CTRL-C behaviour isn't really an issue.
From what you said about using MEGA, it sounds like you might be interested in TOPALi (http://www.topali.org) which is developed by one of our colaborators. We've implemented an experimental mechanism (the Vamsas menu in either the jalview desktop or the topali main window) for data exchange between the applications for dealing with exactly the kind of situation your are in - moving data between programs to do combined analysis.
This e-mail, inclusive of attachments, is intended for the person(s) or entity stated above and may contain confidential information. Unauthorised reading, disclosure, copying, distribution or use of this information may violate rights to proprietary information. If you are not an intended recipient, please return this e-mail to the sender and delete your copy. Thank you.
···
On 29-01-2008 at 15:19, James Procter <jimp@compbio.dundee.ac.uk> wrote:
For my part the best thing would be to use ctrl-c for raw copy and ctrl-shift-c
for fasta copy. This is of course not a good idea as a default for jalview
since that would not be backwards compatible but one could always wish for
two additions: raw copy on ctrl-shift-c as default and a checkbox in
preferences to swap the two copy variants...
As of now I am actually using MEGA in parallel with jalview just for this
reason, quite inefficient but stripping out fasta headers all time was even
worse
I'd vote for having a preference (or something) for what jalview uses to
copy the data to the clipboard. The application doesn't even touch the
clipboard when copies occur internally so internal compatibility for the
CTRL-C behaviour isn't really an issue.
