LINUX.ORG.RU

Kst 2.0.4

 , kst, ,


1

3

Начался осенний семестр у студентов, первая четверть у школьников — и тут как нельзя кстати подоспел корректирующий выпуск приложения для визуализации данных в KDE, — Kst 2.0.4.

Kst претендует на звание одного из самых быстрых инструментов для построения двумерных графиков как по формулам, так и по табличным данным, в том числе в режиме реального времени: разработчики сообщают об успешном построении в режиме реального времени данных, поступающих с частотой 100 Hz с 48 каналов, включая их спектры. Kst имеет встроенную функциональность для анализа данных, кроме того, возможности приложения могут быть расширены за счёт плагинов и дополнений.

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

Kst может обрабатывать данные, хранящиеся в файлах форматов ASCII, Dirfile, netCDF, CFitsIO, экспортировать в QImage-совместимые типы изображений с возможностью записи (BMP, JPG, JPEG, PNG, PPM, TIFF, XBM, XPM), а также SVG, EPS и PDF.

Kst распространяется на условиях лицензии GPL, доступен для Linux, Mac OS X и Windows, и, что самое важное для тулкитофобов и прочих кедоненавистников, — абсолютно не привязан к библиотекам KDE и может быть запущен без них, однако предоставляет дополнительные возможности при их наличии.

Для сборки из исходных кодов необходимым является лишь наличие библиотек Qt, наличие GNU Scientific Library (на которой основана работа многих полезных плагинов для анализа данных), библиотек GetData (для поддержки формата Dirfile), NetCdf (для поддержки формата netCDF) и muParser (для работы плагина нелинейного сглаживания) требуется опционально.

В этом выпуске:

  • масштабная переработка команды автоматической компоновки (auto-layout);
  • усовершенствования в автоматическом именовании в легенде;
  • исправления для лучшей отрисовки во время операций перетаскивания;
  • «одружелюбливание» пользовательского интерфейса, например, теперь двойной щелчок по меткам или осям откроет соответствующий диалог;
  • начата работа над диалогом Настройки->Темы, в котором уже сейчас можно настроить кисть, стиль линий (аля штрих, штрих-пунктир), шрифт и назначить все эти настройки по умолчанию или применить ко всем открытым объектам;
  • классная новая фича — автодополнение в редакторе уравнений и меток с поддержкой шаблонов;
  • решение проблем с падением многих плагинов;
  • многочисленные исправления и мелкие улучшения.

Все желающие приглашаются к участию в разработке и тестировании: наверное, многим может пригодиться наличие в Kst совместимых с Python, NumPy и SciPy скриптов и возможность использования Kst в качестве бэкенда для построения графиков из Python или даже контроль за рабочей сессией Kst при помощи Python-скрипта! Подробнее о планах разработчиков в списке рассылки и дорожной карте проекта.

Официальный сайт проекта

Страница загрузки на sourceforge

>>> Анонс в списке рассылки

★★★

Проверено: post-factum ()
Последнее исправление: adriano32 (всего исправлений: 3)

Ответ на: комментарий от AlexVR

Ну хочешь я спрошу у Peter Kuemmel, я его сегодня уже спрашивал по поводу ошибок при сборке как у PVOzerski, у меня такие же были, из-за старой версии CMake. Я сам из пофиксил, а оказалось нужно было просто обновить CMake. Потому ещё один пространственный вопрос он вытерпит.

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

Товарищ КО, практика показывает что это все-таки не одно и тоже... Отрисовывать 48 новых точечек на графике 100 раз в секунду или отрисовывать одну точечку 4800 раз в секунду... :)

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

а адриано это от идиот или kst у нас полностью заменяет цифровой осциллограф включая синхронизацию и запуски?

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

Размер графиков 1х1 пиксель и одно значение по х? :)

Это я к этому пёрлу о цифровом осциллографе вспомнил. Общее в том, что в реальном времени картинка движется справа налево, будучи отображаемой в каком-то масштабе. Увеличил масштаб—быстрее бежит, уменьшил — медленнее.

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

> 48 каналов по 100Герц это 4800 Герц. //К.О.

Не. Частота вывода на экран всё равно 100 Гц. Хоть там 100500 каналов, всё равно это 100 Гц. А мне нужно 4 кГц. Что существенно выше возможностей буковой видяхи. Да и ЖКИ, вообще-то. Так что либо накапливание и пачка сразу, либо ФНЧ и передискретизация.

anonymous-
()
Ответ на: комментарий от petrosha

> размечтался :) сам пиши.

Блин! Ну не так уж это и сложно, если человек этим занимается. В чём может быть проблема с VSYNC? Или ты о чём-то другом?

anonymous-
()
Ответ на: комментарий от adriano32

На приведенном тобою ролике вообще не видно с какой частотой обновляется картинка. То что они могут построить график размером в 5кк точек это конечно клево. Еще бы посмотреть на отзывчивость системы при перерисовках.

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

Я его только что с ютуба выдернул, наобум. Можешь поискать ещё, чтоб удовлетворить своё любопытство или желание утоптать эту кедоподелку в грязи.

Еще бы посмотреть на отзывчивость системы при перерисовках.

Поставь чтение с винта и отрисовку этих цифровых данных в Kst.

adriano32 ★★★
() автор топика
Ответ на: комментарий от anonymous-

>Или ты о чём-то другом?
я о том, что когда нужно синхронизоваться, то обычно требуется в комп чего-нибудь еще для связи с АЦП (не всех же устраивает 16битный АЦП в звуковушке, как в примере из ролика), самому АЦП требуется конфигурация, общение с ним требует дополнительных усилий, а уж когда ты всю эту маету с данными напишешь, отрисовать картинку на экран нет никакой проблемы и без сторонних софтин.

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

> Твой глазик больше 25 Герц не увидит всё равно, дружище :)

???

С АЦП сыплются данные. Жмакаем датчик. Хотим увидеть реакцию на экране. Видим, но не сейчас, а сильно позже. Хотим сейчас. Сабж умеет, чтобы сейчас?

anonymous-
()
Ответ на: комментарий от adriano32

>желание утоптать эту кедоподелку в грязи.
Ты чего так нервничаешь-то? Мне интересно, потому что переодически приходится выводить кучу графиков и чего уж только мы не пробовали. И Кутешные тулзы с ихним QWT не самые быстрые... Ну а в то что КДЕшные либы быстрее чистого куте, через который все рисуется, извините, не поверю.

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

Ну а в то что КДЕшные либы быстрее чистого куте, через который все рисуется, извините, не поверю.

Ещё один умник ограничился прочтением заголовка. Из зависимостей к KDE только KSharedPtr.

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

Ыыы... ты укуренный кдешнег. Стоит тебе увидеть слово КДЕ в тексте, остальное ты не читаешь :)))

Ладно, давай по другому. Ты сорцы говоришь смотрел, чем они отрисовывают все это?

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

> я о том, что когда нужно синхронизоваться, то обычно требуется в комп чего-нибудь еще для связи с АЦП (не всех же устраивает 16битный АЦП в звуковушке, как в примере из ролика)

Есть девайс. Подключается через некий интерфейс. Интерфейс обеспечивает передачу данных с требуемой скоростью (взяли отсчёт, и он тут же доступен на ПК). Нужно вывести отсчёт на экран. Если тупо в лоб, то отсчёт на экране появится не скоро. Чем дольше работает программа, тем более не скоро. Хочется, чтобы прямо сразу.

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

Есть такая хрень, называется «разделение труда». Ну я вот делаю девайс, а софт для ПК пишет другой чел. Ну так вот оно. И мне хочется получить данные на экран в реальном времени. А не так, как сделано сейчас у «другого чела». Отсюда вопрос к ТС: сабж поможет мне? Если да, то я буду заморочиваться с Qt/KDE. Если нет, то нафига мне время своё драгоценное тратить.

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

>Отсюда вопрос к ТС: сабж поможет мне? Если да, то я буду заморочиваться с Qt/KDE. Если нет, то нафига мне время своё драгоценное тратить.

Не поможет. По крайне мере, не напрямую.

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

QGLWidget видел в инклюдах, QGraphicsScene. Ну и Pen'ы и Brush'и. Ну никак не средства KDE, потому я и смело скопипастил в заметку фразу о том, что ничего кроме Qt не нужно, вместо того, чтобы не глядя на сабж, утверждать, что он медленный, из-за того что тянет за собой 300 метров кедобиблиотек.

Возьми и собери на системе с Qt и без КДЕ, Петроша, увидишь, что не все пользуются кедами для рисования и Qwt.

adriano32 ★★★
() автор топика
Ответ на: O cmake от PVOzerski

Если не поможет, отпишешь, а потом по ссылке проделаешь все исправления, которые я внёс, чтоб собрать со старым cmake.

adriano32 ★★★
() автор топика
Ответ на: комментарий от anonymous-

В сабже минимальный интервал обновления данных 10 милисекунд. За 10 милисекунд тебе в файлик привалит сколько новых отсчётов? Около 40? А дисплей перерисовывается сколько раз? 60 в секунду пускай, да или раз в 17 милисекунд, правильно? Значит каждый рефреш дисплея добавит чуть больше 60 новых отсчётов и сдвинет старые 60. Чтобы ты заметил это, нужно, хотя бы герц 20, а значит около 200 отсчётов.

Выходит при ширине дисплея 1600 пиксел (widescreen), 8 пикселей между точками будет и ты увидишь различимую движущую картину.

petrosha, приступай, ищи ошибки в моих рассуждениях

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

В продолжение попыток собрать

cmake ./cmake - конечно, не помогло. Вообще есть у меня одно подозрение... Правда, я на С++ никогда не программировал и рискну обратиться к своему опыту работы с Delphi и FreePascal, поэтому, возможно, скажу глупость. Так вот, почему компилятор выдает здесь ошибку, а не warning (с потерей старших байт и автоприведением типов)? И нельзя ли заставить поступать его именно по второму варианту с помощью каких-то ключей?

PVOzerski ★★★
()
Ответ на: В продолжение попыток собрать от PVOzerski

Можно, наверное. Ты видел, как я поступил, там, да? Это число вылазит за пределы unsigned long, так что либо указать, что эта константа в unsigned long long, либо заменить, как я, по смыслу оно не сильно влияет врод

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

Да понял я...

Просто не хочется код править - а то забуду на каком-нибудь следующем релизе (если прога понравится, конечно) и опять споткнусь. А ключ компилятора - штука универсальная.

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

> Интересно, как у сабжа дела с этим обстоят? Умеет ли оно делать накапливание n отсчётов, а потом все n — сразу пачкой на экран

я поковырял сабжик чуть. Там несколько режимов обновления графика. Среди них: отображать даные по мере обновления файла-источника или обновлять через фиксированый интервал времени. Пределы диапазона интервалов не уточнял.

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

обновлять через фиксированый интервал времени. Пределы диапазона интервалов не уточнял.

От 10 милисекунд до 60000 милисекунд

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

Собрал в итоге с Вашим патчем...

С одной стороны - спасибо Вам! С другой - почему разработчики не приняли Ваш патч - совершенно не понятно. Похоже, что они собирали только 64-разрядную версию, либо использовали какой-то другой компилятор - не gcc.

PVOzerski ★★★
()
Ответ на: Собрал в итоге с Вашим патчем... от PVOzerski

20 минут назад пришло:

SVN commit 1253670 by joshuanetterfield:

Allows for in- and out- of-source builds with qmake using Andriy Shinkarchuck's fixes/suggestions.

The problem with SIZE_LIMITED_NAME is already fixed in svn, but I probably missed the 2.0.4 tag. Apologies!
Пофиксили типо, сейчас посмотрю как.

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

Скорее уж тогда выслал склонных к насилию психопатов за разрабами.

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

Локализации нет?

aspotashev, что-то не нашёл файлов переводов. Непорядок? Добавить tr()'ы и перевести? :)

Кстати, если вы знакомы с мейнтейнерами KDE в одном из дистров, стуканите им о Kst, вот письмецо разраба, у них скоро изменения в системе сборки произойдут, отказываются от qmake.

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

> Добавить tr()'ы и перевести? :)

tr() и i18n() уже используются, вопрос в следующем: 1. кто напишет скрипт для извлечения строк? (Messages.sh) 2. будут ли разработчики выпускать Kst с переводами в общем tarball-е?

Написал в рассылку Kst: http://mail.kde.org/pipermail/kst/2011-September/020089.html

Кстати, если вы знакомы с мейнтейнерами KDE в одном из дистров, стуканите им о Kst

Лучше начать с самостоятельного опакечивания: в Gentoo — написания ebuild'а, в Archlinux — PKGBUILD в AUR.

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

>QGLWidget видел в инклюдах, QGraphicsScene. Ну и Pen'ы и Brush'и.
Ну собсна в этом и был вопрос. Спасибо


Ну никак не средства KDE, потому я и смело скопипастил в заметку фразу о том, что ничего кроме Qt не нужно, вместо того, чтобы не глядя на сабж, утверждать, что он медленный, из-за того что тянет за собой 300 метров кедобиблиотек.

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

увидишь, что не все пользуются кедами для рисования и Qwt.

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

Вот бы выдрать рисовалку из этой софтины в отдельную библиотеку и попытаться поюзать.

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

>приступай, ищи ошибки в моих рассуждениях
Сам ищи ошибки в своем бреде... У меня в такой манере даже третьекурсники не изъясняют свои мысли.

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

Какой смысл использовать жадные трекеры, на которых считают ратио, когда полно открытых трекеров без регистрации?
Это всего один из многих примеров нормальных программ, написанных еа Qt без привязки к ужасным kdelibs.

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

Насчет смысла уже сто раз жевано-пережевано. Никакой русскоязычный трекер и рядом не валялся по количеству и качеству раздач арт-хауса и просто фильмов, причем у меня от момента «нашел фильм на imdb» до «начал смотреть этот фильм» как правило проходит меньше одной минуты. Открытые трекеры как правило являются помойками, где нет сидов, искать три часа, качать три дня. Насчет нормальной программы тоже можно поспорить, у меня в нем иногда потребление памяти доходило до 200Мб. Но то, что это один из самых адекватных клиентов под линукс, это факт.

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