>>> 2) DataShifter. It might be possible to let DataShifter be called
>>> inside Analysis (I am neither the one who knows nor the one who
>>> would have
>>> to do it). We take note. But it would still work the same way.
>>> The problem
>>> about 'importing native format data' is that the CCPN objects are
>>> linked together. Importing e.g. a peaklist means you must decide
>>> how to
>>> handle all the links that go from the peaks to something else.
>>> That is
>>> often complicated, and it reuires special purpose handwritten
>>> code for
>>> every single case that you decide to support.
>> DataShifter & formatConverter are important for the whole CCPN
>> effort (which is not just analysis) and is an area that certainly
>> deserve some more attention. As well as the means by which
>> existing users go to transfer data between projects, they are the
>> route in for new users - we need them to be slick & documented to
>> the point where users do not feel really comfortable using them.
>> NB this needs detailed and constructive feedback from the users
>> reading this on what functionality is broken/missing and to help
>> with documentation for specific cases.
> I agree with this data transfer is a very important are and it is
> one of the first things many users will see when they start
> My current pet peave is Link reosnances (apologies to wim!), in
> some cases I have to run it over an over again because my
> resonances don't have ranges that overlap (have you ever tried
> importing a restraint list with only long range restraints its
> quite fun!) Also the other thing with link resonances is that often
> i _know_ the information that it is trying very hard to deduce (ie
> most external program only deal with single chain and if I could
> tell analysis what chain that is it would make the import process
> much smoother)
I completely agree - but, as I explained before, the formatConverter
grew organically and was written to be as generic as possible so it
could handle all kinds of imports/exports, with use-of-ease
definitely not a priority. The current GUI is, basically, a direct
reflection of the Python scripts underneath that do all the work - it
takes a long time and a lot of effort to build a customised user-
friendly interface. Unfortunately I have other priorities and don't
have that time any more. We discussed this at a CCPN meeting
yesterday, and it's clear we have to find a solution - this will have
to involve someone else building this interface, and it's not clear
how that is going to happen yet.
In the meantime I'm happy to fix bugs - however, if anyone encounters
any when importing/exporting, the only way I'm going to to be able to
do anything about them is if you let me know.