Хотел бы тут обсудить ряд вопросов связанных с 3D просмоторщиком молекул. В UGENE есть свой, но он по ряду параметров уступает VMD
http://www.ks.uiuc.edu/Research/vmd/

вопрос к тем кто разбирается в лицензиях - как и на каких условиях можно использовать/переделывать код VMD?

Интересно что означает на практике
"Можно распостранять не более 1/2 исходного кода без комментариев и не более 1/10 измененного кода без комментариев."

Можно ли:

1. Переделать VMD, откомпилировать и распространять скажем только .dll библиотеку без исходного кода (но естественно, использовать его при компиляции)

2. Что означает 1/2 исходного кода без комментариев - т.е. взять их исходники и просто распространять сами нельзя? Но можно если взять только половину ? Или если хотим больше скажем 80%, то нужно комментировать в 30% файлов - что комментировать и как?

3. Если же мы изменили их код, ну скажем так или иначе затронули понемногу каждый их файл. Тогда что? Только одну десятую можно распространять? А если хотим опять же больше, что комментировать надо?

Особый вопрос вызывает понятие "распространять без комментариев"? Достаточно ли в заголовок файла, скажем поместить, комментарий - что и с какой целью изменялось в этом файле?


А шапка эта: "This software includes code developed by the Theoretical and Computational Biophysics Group in the Beckman Institute for Advanced Science and Technology at the University of Illinois at Urbana-Champaign." ?

Ну, хорошо ... видимо с лицензией потенциально можно разобраться, но не очень просто. Дело в том, что я делал реинжиниринг VMD для своих нужд и немного разобрался в их коде. Задача у меня была убрать их пользовательский интерфейс, который сделан сравнительно плохо и уметь внешнее (через .dll) управлять графическим окном. Но это была так сказать тестовая попытка, но этим можно занять более качественно теперь со знанием дела.

Теперь почему этим имеет смысл заниматься. Ну, во первых у них это полноценный просмотрщик 3D молекул с достаточно большим числом функций. Другие и ваш в том числе думаю несколько отстают по функциональности.

Но давайте начнем обсуждать с чего-то маленького и конкретного. Поставьте себе VMD, чтобы вы могли на это реально посмотреть. И сравнить. Если откроете любой pdb, то сравните управление вращением в VMD и у вас.

Не знаю как это описать, но обратите внимание на удобство поворота молекулы. В VMD молекула вращается так сказать легко и непринужденно во все стороны, а потом происходит вращение по инерции. Я часто работаю с этим - и это очень удобно. У вас же движение какое-то менее естественное, приторможенное и без вращения по инерции.

Может это покажется мелочью - но думаю пользователю как и мне это важно. В любом случае если вам нравится ваш стиль, и он был сделан таким намерено. То добавив второй стиль управления вращения мышью думаю UGENE в целом выиграет.

Это конечно лишь маленький пример. Более детальное сравнение можно будет сделать позже, если вы согласитесь что в этом направлении надо работать.

Но хотелось бы понять принципиально. Готовы ли вы тут на революционные изменения - выкинуть ваш просмотрщик, и начать базироваться на VMD. Что будет много проще при разработке и думаю эффективнее по введенной функциональности.

Или вам его жалко (ну, понятно писали сами, и он ваш - "родной"), и вы готовы только к эволюционным изменениям, понемножку, по чуть, чуть добавляя в него улучшения ? (Но может, это и стоило бы пересмотреть, т.к. это нас будет тянуть (затягивать введение улучшений) на многие месяца, а ведь можно было бы адаптировать VMD более быстро ? )

Тога давайте наметим некий план - ТЗ (техническое задание).

Мне хотелось бы, чтобы я работал бы в паре с кем то, кто реализовывал ваш 3D просмотрщик и в сферу его ответственности входило бы думать как и хотя бы частично реализовывать связь нового кода из VMD с текущим вашим. Это возможно?

Код VMD довольно обширный, и его встраивание надо разделить на этапы. При этом идти по пути наращивания функциональности видимой пользователю в данном случае не правильно.

Скажем на первом этапе можно из VMD выделить так сказать библиотеку низкого уровня - обеспечивает базовые математические функции, классы программных конструкций (типа классы матриц, стэков), и все прочие, что имеет малую связность.

Тут важно понять - как мы поступим, будем ли разбираться для чего нужен тот или иной код в VMD, есть ли аналог у вас, и как этот код совмещать? Или же мы добавим часть кода VMD "в слепую", без подробного анализа что он делает, а лишь будем ориентироваться на уже видимую пользователю функциональность?

Тот или иной путь, конечно имеет свои достоинства и недостатки.
1. Можно потратить много не нужного времени на совмещение разного кода, но который делает нечто близкое по сути. Особенно займет много время анализ что возможно дублируется, что лучше (их код или ваш в конкретном месте) и почему. И тогда за деревьями не увидим лес.
2. Потратим меньше времени на совмещение/анализ, но появится частично дублирующие вещи, не будем в деталях знать что для чего, и скорее получится два варианта одного и того же - как минимум на первом этапе. Но зато будут встроено быстрее и больше функциональности видимой пользователю. И после такого совмещения на высоком уровне уже можно будет занять совмещением на более низком уровне.

Т.е. по сути вопрос в том, как поступим - совместим "снизу вверх" или "сверху вниз"?

В общем, я предлагаю поступить так. Я попробую сделать из VMD отдельную библиотеку (.dll) с определенным API. Оно будет полностью ответственно за графический экран, но и только - все связи с интерфейсом - это не её дело. И тогда вы поможете мне:
1. Вызывая команды API этой dll включить в интерфейс UGENE
2. Если что-то надо подцепить, что у вас уже разработано в текущем просмотрщике (и такого нет в VMD - думаю такого будет сильно мало) - перенесем это как API этой dll.

Думаю так будет наиболее эффективно по скорости разработки, так и по отделению кода графики от интерфейса.

Далее, что для меня достаточно важно - решая вопрос с лицензией за мной должны остаться ровно такие же права как при соблюдении лицензии VMD. Т.е. чтобы я мог использовать эту разработанную dll (и распространять её исходный код) в академических целях как часть любых моих программ.

Если для вас это приемлемо - можно начать разработку. Было бы хорошо - если бы вы открыли в своем репозитории ветку, куда я смог коммитеть постепенно изменяемый код VMD с целью превратить его в нужную нам dll (кстати ей надо дать название например Molecular3DScreen (M3DS) - годится? ). Тогда бы мы сохранили бы историю изменений и вы легко могли бы следить за процессом и помогать используя код из этой ветки.

Я все таки говорю о независимой .dll . Указанные же вами плагины - компилируются вместе с UGENE и имеют множество связей с другими файлами UGENE. Это не самый лучший путь.

Другое дело, что как раз интерфейс к Molecular3DScreen.dll можно написать как плагин.

А вообще, я бы на вашем месте пересмотрел бы архитектуру и развитие плагинов, ИМХО, они должы компилироваться отдельно от UGENE - но сейчас из-за сильных связей с UGENE я так понимаю это не возможно. Но это так в сторону от основной линии ...

Так что на счет человека с которым я мог бы осуществить эту разработку в паре (вы за это возьметесь?), и выделении у вас ветки в SVN под такую разработку?

Я тогда хотел бы закоммитеть первоначальную версию будущей Molecular3DScreen.dll, так сказать Repack VMD. В ней я пересобрал VMD, убрав всякие внешние зависимости (они используют целый ряд библиотек, плагинов, в частности на питоне, и много челого другого) оставив только базовое ядро. (Кстати, чтобы вы понимали масштаб - VMD по сути не меньше чем весь UGENE вмести взятый, в моем Repack`е после очистки остаются около 370 файлов)

Хотел бы что вы по крайней мере попробовали это откомпилировать и запустить. Затем можно будет перейти ко второму шагу - убрать от туда GUI от VMD.

Затем только третьим шагом (коммитом) можно попробовать пристыковать это к UGENE - и тут я хотел бы рассчитывать на вашу помощь.

Четвертым шагом, если останутся и будут у вас силы - можно подумать о совмещении функциональности Molecular3DScreen.dll с вашим biostruct3d_view .

Konstantin Okonechnikov wrote on Mar 21^st, 2013 at 6:19am:


Нельзя сказать, что я не ожидал такого вопроса. Но в самом начале я говорил с вашим коллегой о том, что я не разрабатываю вещи под что то другое кроме Win (принципиально). VMD по сути поддерживает Linux и Maci и все остальные "глупости"  - специально я это из кода VMD не убираю, но тут могут быть проблемы и заниматься подобной поддержкой лично я не буду ... если вы не хотите мне в этом помогать и настраивать VMD - то думаю тогда стоит закончить разговор не начав.

Что же касается функциональности, которая останется (осталось бы - если бы вы были заинтересованны поддерживать другие OS - а по моим оценкам это достаточно просто, если быть знакомым со средой других OS, и конечно, не стоит в сравнении в том, какую работу я провожу по тому чтобы убрать лишние и нормализовать код VMD)  - то ядро VMD обеспечивает достаточно много, документа нет ... но вы вполне могли бы посмотреть на это - если бы захотели бы откомпилировать мой Repack ... там практически все - убраны только плагины, которые не на Си, и текстовые интерпретаторы (при необходимости могу пояснять детально, но вы должны быть готовы к обзору кода - понятно что не детально, а в общем - но на пальцах объяснять не возможно.) - все это сделано у них не качественно. по сути пользователь - даже не заметит разницы, если не был профи в VMD. Но повторюсь - если будем работать все-таки вместе я надеюсь на вашу помощь, а не просто на прием кода "free".