LINUX.ORG.RU
ФорумTalks

Схема метаболических путей


0

0

Народ, у меня что-то творческий кризис. Давно зреет идея сделать интерактивную карту метаболических путей. Вот вроде теперь дошли руки до ее реализации. Дня 2 последние усиленно думал, как же воплотить в жизнь задумку.

Метаболическая карта с высоты птичьего полета: Хочется показать основные пути, общие для многих организмов. Например, гликолиз, цикл Кребса, пентозофосфатный путь, путь Энтнера-Дудорова и т.д. и т.п., желательно со всеми шунтами, или только основными, например, метилглиоксалевый шунт, глиоксилатный шунт и т.д. В общем, хотелось бы показать это все переплетение в общем виде. В перспективе неплохо бы добавлять пути свойственные отдельным группам организмов, например, метилотрофы и др.

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

Вот. И в общем, голову ломаю, как бы все это сделать, на чем. Читать данные из спец. сформированного файла и строить с помощью Cairo? Не микроскопом ли это гвозди забивать? Хорошо, предположим строим с Cairo. Как выделить элементы, как обработать на них клик? Статически, разделив поле на шахматку и прописав координаты в файл? Костыль. И так клик мышью будет не точен. Динамически, вычисляя координаты элементов по их порядку в реакциях? Сложно, да и не менее костыльно.

Может быть веб-программирование подойдет? Но я там дуб полный. PHP, javascript? Флеш?

В общем, как быть? Что посоветуете?

★★★★★

Можно все обрабатывать не на низком уровне, с помощью Cairo, а с помощью Gtk. Оформить все элементы в виде виджетов, разместить их на каком-нибудь контейнере с абсолютным позиционированием. И дальше уже не так сложно.

mono ★★★★★ ()
Ответ на: комментарий от mono

Можно, да. Только этот метод: a) сильно уступает в производительности при большом количестве элементов б) не универсален в) тулкитофилия/тулкитофобия и садо-мазохизм

codebuger ()
Ответ на: комментарий от codebuger

>a) сильно уступает в производительности при большом количестве элементов

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

б) не универсален

gtk то не универсален?

в) тулкитофилия/тулкитофобия и садо-мазохизм

тулкитофобией и тулкитофилией страдают только школьники и глупые тролли на лоре.

а где тут садо-мазохизм? наоборот удобно. Всю черную работу делает тулкит, остается только написать логику.

mono ★★★★★ ()
Ответ на: комментарий от mono

А я думал у меня появилась глуповатая идея о хранении матрицы координат ветвей/деревьев/элементов/или ещё чего...

wyldrodney ()
Ответ на: комментарий от mono

> ничего подобного. наоборот это будет намного быстрее, чем самому вручную все перерисовывать и обрабатывать, потому что тут рисованием занимается тулкит, а не вася-программист, только что изучивший как си плюс плюс.

Нет, ты серьезно чтоли? Ты правда уверен что несколько тысяч виджетов для GTK не проблема? Я вот не очень.

gtk то не универсален?

Описаный тобой подход не универсален: как допустим будешь делать красивый кликательный график/диаграму с возможностью перетаскивания точек мышью и отображением всяческой информации при наведении/клике в определенном месте картинки? На cairo это муторно и грустно, твое решение тут выглядит просто убого.

а где тут садо-мазохизм? наоборот удобно. Всю черную работу делает тулкит, остается только написать логику.

Все так, с одной лишь маленькой поправкой - GTK все-таки gui toolkit а не graphic framework. Qt graphic тоже делает за тебя всю черную работу и при этом является именно graphic framework'ом (включая определение коллизий и прочие плюшки).

P.S.: я не C++/Qt фанбой если что, просто ничего лучше Qt для своей задачи не нашел в свое время.

codebuger ()

graphviz

http://hypergraph.sourceforge.net/

как то так...

вообщем надо базу вести «что из чего», базу «путей» как совокупность «что из чего». Ну а когда надо рассмотреть несколько путей одновременно или конкретную реакцию то выборку делать из базы по цепочке реакций, или по иным признакам висящим на «что из чего».

psv1967 ★★★★★ ()
Ответ на: комментарий от codebuger

Чтобы не быть голословным, счет идет лишь на несклько десятков реакций. Это ведь только основные пути. Но если проект удастся, было бы здорово добавлять в программу и узкоспецифичные пути.

Путь Энтнера-Дудорова тоже не у всех идет, однако он все-равно относится к центральным путям.

hibou ★★★★★ ()
Ответ на: комментарий от codebuger

>Нет, ты серьезно чтоли? Ты правда уверен что несколько тысяч виджетов для GTK не проблема? Я вот не очень.

Да, я серьезно. Нет не проблема. Ты видимо просто не понимаешь как это все работает.. или считаешь gtk «тормозным говном». Хотя конечно все зависит от того какие будут виджеты.

Идем далее, ты действительно считаешь, что отрисовка нескольких тысяч виджетов будет тормозить сильнее, чем их обработка? Хотя тут тоже все зависит от того как все описать.

как допустим будешь делать красивый кликательный график/диаграму с возможностью перетаскивания точек мышью и отображением всяческой информации при наведении/клике в определенном месте картинки? На cairo это муторно и грустно, твое решение тут выглядит просто убого.

более того, на чистом cairo никто накие вещи и не пишет. Тут нужно использовать тот же самый подход с созданием собственных виджетов, очень сложные участки рисовать самостоятельно. И если же все-таки будет тормозить или будут сложные с графической точки зрения участки, то нужно задействовать Clutter. Если же и с Clutter'ом будет тормозить, то идти лечить руки.

Все так, с одной лишь маленькой поправкой - GTK все-таки gui toolkit а не graphic framework. Qt graphic тоже делает за тебя всю черную работу и при этом является именно graphic framework'ом (включая определение коллизий и прочие плюшки).

мне кажется с подобной задачей вполне справится и Gtk+Cairo.

P.S.: я не C++/Qt фанбой если что, просто ничего лучше Qt для своей задачи не нашел в свое время.

Нет, ты не C++/Qt фанбой, ты просто не разбираешься в теме, а пытаешься критиковать.

Я, кстати, не говорю, что gtk подойдет лучше, я просто предложил способ решения.

Говорить что лучше, а что хуже нельзя, потому что все зависит от того как это будешь писать. Возможности gtk/Qt примерно одинаковы, и выбор должен зависеть только от того что ты лучше знаешь и в чем лучше разбираешься.

mono ★★★★★ ()
Ответ на: комментарий от mono

> или считаешь gtk «тормозным говном»

Ну что ты? Я его года 3 использую. Но для обычных интерфейсов с кнопками и инпутами.

Идем далее, ты действительно считаешь, что отрисовка нескольких тысяч виджетов будет тормозить сильнее, чем их обработка? Хотя тут тоже все зависит от того как все описать.

Разве я говорил что-то про скорость отрисовки? Помнится мне отрисовка GTK виджетов делается через cairo, так что проблем быть не должно. А вот насчет всего остального - не уверен.

более того, на чистом cairo никто накие вещи и не пишет.

Ну это не совсем так - над cairo делают собственную обвертку с нужными элементами (на sf десятки всяческих *-canvas) и используют ее.

Нет, ты не C++/Qt фанбой, ты просто не разбираешься в теме, а пытаешься критиковать.

Пока не пытался. Но использование UI-виджетов для графики по-прежнему считаю странным. Покажешь живой пример приложения, с интерактивной 2D графикой, сделанной таким образом, чтобы «разобраться»?

Говорить что лучше, а что хуже нельзя, потому что все зависит от того как это будешь писать.

Согласен.

Возможности gtk/Qt примерно одинаковы, и выбор должен зависеть только от того что ты лучше знаешь и в чем лучше разбираешься.

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

codebuger ()
Ответ на: комментарий от hibou

> Чтобы не быть голословным, счет идет лишь на несклько десятков реакций. Это ведь только основные пути. Но если проект удастся, было бы здорово добавлять в программу и узкоспецифичные пути.

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

isden ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.