Здравствуйте, prg1000, Вы писали:

P>>>Задача — визуализация данных в виде графиков в реальном времени. Данные приходят с частотой 1 кГц их нужно отобразить на экране.

Для того, чтобы каждую секунду отображать график из 1000 точек, по скорости подойдёт всё что угодно. Поэтому что хорошо знаешь, то и используй.

Здравствуйте, watchmaker, Вы писали:

W>Если вычислительная мощность позволяет, то будет высокий fps.

Ключевое слово — "если". И никто не обещал для какой-нибудь встроенной карточки, что она это позволяет. Может позволяет, может — нет Надо пробовать.


W>Естественно ограничение на fps возникает совсем не в OpenGL, а в средствах вывода — в скорости работы монитора или проектора.

Как насчет обмена между картой и процессором? Карточка будет получать данные от процессора. 1000 раз в секунду. А процессор, помимо подготовки данных (он ведь их, как я понял вопрос ТС, откуда-то читает, с внешнего устройства) и пересылки их карточке будет занят еще кучей других дел.


W>Если же проектор может отобразить 5000 кадров в секунду, то тот же OpenGL вполне может выступать источником таких данных (пример).

Вот с трудом представляю себе, зачем нужен проектор отображающий 5000 кадров в секунду — показывать порно пчелам? Никто из зрителей-людей и не заметит разницы между 5000, 1000, и 200 Гц. И сильно сомневаюсь, что у ТС именно такое устройство отображения. Хотя, кто знает...

Здравствуйте, alexdpp, Вы писали:

A>зачем он нужен если есть бесплатный и мощный Qt?

1. Sciter тоже бесплатный (в binary form) на Windows и Linux. На Mac, да, небесплатный. Традиция на Mac такая — за всё платить.
   
2. Sciter это всего одна DLL размером 4mb (6mb на Mac).
   
3. Sciter это сугубо UI. И никаких попыток обеспечить "счастья всем и бесплатно" в виде QThread и прочего хозяйства. Для этого есть и средства в std namespace и другие более удобные. Кто-то например POCO предпочитает или ненавидит CamelCase. Мало ли какие традиции в компаниях.
   
4. UI в Sciter это одна единственная сушность — HELEMENT (sciter::element в С++). Соответсвенно API это в принципе всего около 30 функций оперирующих HELEMENT. А не тонны классов на каждый чих.
   
5. Sciter использует всплывающие события (event bubbling). Никаких signal-slot костылей не требуется.
   
6. Code-behind-UI в Sciter это либо native code либо script, на выбор. Скрипт больше подходит для code-behind-UI — GC, first class functions, eval и пр.
   
7. CSS selectors как язык запросов (sql::select kind of thing) на DOM tree. Т.е. слабая связанность logic и UI.
   
8. Sciter поддерживает динамические интерфейсы когда UI дословно склеивается из разных html фрагментов.
   
9. Каждый уважающий себя программер должен знать нынче HTML/CSS. Sciter это оно в этом смысле.
   
10. Мода на UI меняется раз в два года. Если не чаще. Нормальный, стандарный CSS это наше всё нынче.

еще продолжать?

Здравствуйте, slava_phirsov, Вы писали:

_> Вот если бы мы были пчелы и "частота мерцания" у нашего зрительного анализатора (глаз + зрительные отделы мозга) была килогерцовой, то OpenGL был бы "заточен" под такую частоту. А так — его писали люди, для людей, и делали это из расчета, что обновлять картинку чаще, чем 100 раз в секунду никому не потребуется.

Откуда такие познания об OpenGL и о людях его писавших? И как именно его «затачивали под такую частоту»? И зачем так делали? И почему «заточенный» OpenGL используется для gpgpu, где пресловутые тысячи кадров в секунду не редкость? И что ему мешает выдавать те же тысячи кадров в секунду при визуализации несчастного графика? Да, как библиотеке рендера, ничего не мешает. Задача OpenGL нарисовать что попросили и сам процесс рендера никто намеренно не тормозит. Если вычислительная мощность позволяет, то будет высокий fps.

Естественно ограничение на fps возникает совсем не в OpenGL, а в средствах вывода — в скорости работы монитора или проектора. Если обновлять изображение быстрее чем монитор его может отобразить, то это лишь отправит в утиль часть картинки и, возможно, приведёт к заметным артефактам в изображении. И если условных 60 fps достаточно, то можно просто ставить рендер на паузу, если он работает слишком быстро. И вот это вот действительно делается. Но обычно для всей графической подсистемы, а не только для OpenGL (хотя многие платформы и предоставляют расширения к API для этой цели).
Если же проектор может отобразить 5000 кадров в секунду, то тот же OpenGL вполне может выступать источником таких данных (пример).

Здравствуйте, Qbit86, Вы писали:

Q>Зачем визуализировать с частотой выше 60 Гц?
чтоб сохранять в файл или видеопоток?

а по сабжу: Qt + QWT.

Здравствуйте, prg1000, Вы писали:

P>Привет.
P>Задача — визуализация данных в виде графиков в реальном времени. Данные приходят с частотой 1 кГц их нужно отобразить на экране.

Вот данные приходят в real time, интегрируются и отображаются.



Это все в Sciter (Кто про что а голый про баню).

1 кГц это одно событие в одну миллисекунду. Стандаратное значение FPS для экранных анимаций — 60, или одно обновление экрана каждые 16ms.
Windows кстати и WM_PAINT чаще слать не будет. Sciter тоже выодит анимации с 60 FPS max.

По любому нужно как-то твой сигнал усреднять, фильтровать — конвертирвать к виду удобному для восприятия человеком.

	Вот минимальное приложение на Sciter (C++)
	#include "sciter-x-window.hpp" class frame: public sciter::window { public: frame() : window(SW_TITLEBAR | SW_RESIZEABLE | SW_CONTROLS | SW_MAIN) {} BEGIN_FUNCTION_MAP FUNCTION_0("helloWorld", helloWorld); END_FUNCTION_MAP sciter::string helloWorld() { return WSTR("Hello World"); } }; int uimain(int argc, WCHAR** argv, std::function<int()> run ) { frame *pwin = new frame(); const char* html = "<html>" "<script type='text/tiscript'>" "$(body).text = view.helloWorld();" "</script>" "<body>" "</body></html>"; pwin->load( aux::chars_of(html) ); pwin->expand(); return run(); }

Здесь создается и показывается окно. Также описана native function (helloWorld()) для скрипта.
Например твоя native function предоставляет данные для скрипта. Скрипт скажем по таймеру опрашивает (вызывает) данную функцию и строит/рисует график.

зачем он нужен если есть бесплатный и мощный Qt?

Здравствуйте, prg1000, Вы писали:

P>Привет.
P>Задача — визуализация данных в виде графиков в реальном времени с частотой 1 кГц.
P>Серьезно с C++ не работал, только C, т.е. на данном этапе мне не важно с чем разбираться (т.к. все равно придется) — Qt, WinAPI, MFC, WTL...
P>Как-то давно писал на чистом WinAPI (тогда Qt даже не было), механизм у WinAPI мне кажется очень прозрачным, а вот скорость разработки, как мне кажется, низкая.
P>Посоветуйте на чем остановиться.

Из предложенного, однозначно Qt.

Как альтернатива: гуи на WPF (C#) c C++ бекэндом.

Здравствуйте, prg1000, Вы писали:

P>Задача — визуализация данных в виде графиков в реальном времени с частотой 1 кГц.

Зачем визуализировать с частотой выше 60 Гц?

Здравствуйте, prg1000, Вы писали:

P>Спасибо. Вот тут меня как раз интересует насколько свободно я смогу пользоваться возможностями OpenGL в Qt. Хватит ли этого для задачи?

Боюсь, что скорее нет. Вот если бы мы были пчелы и "частота мерцания" у нашего зрительного анализатора (глаз + зрительные отделы мозга) была килогерцовой, то OpenGL был бы "заточен" под такую частоту. А так — его писали люди, для людей, и делали это из расчета, что обновлять картинку чаще, чем 100 раз в секунду никому не потребуется. А ты хочешь — 1000 раз в секунду. Впрочем, попробуй, вдруг что получится. Было бы интересно узнать о результатах, но, повторюсь, я бы так делать не стал.

Здравствуйте, slava_phirsov, Вы писали:


W>>Если вычислительная мощность позволяет, то будет высокий fps.
_>Ключевое слово — "если". И никто не обещал для какой-нибудь встроенной карточки, что она это позволяет. Может позволяет, может — нет Надо пробовать.
OMG. «Если» написано для того чтобы фраза включала и более ресурсоёмкие задачи, ибо они всегда существуют. Что же касается встроенных видеокарточек, то для объёмов, указанных автором темы, скорость рендеринга вполне достигает десятка тысяч кадров в секунду, glxgears как пример тому.

_>Как насчет обмена между картой и процессором? Карточка будет получать данные от процессора. 1000 раз в секунду.
Для указанных объёмов — это мелочи.

W>>Если же проектор может отобразить 5000 кадров в секунду, то тот же OpenGL вполне может выступать источником таких данных (пример).

_>Вот с трудом представляю себе, зачем нужен проектор отображающий 5000 кадров в секунду — показывать порно пчелам?
По ссылке есть и описание, и демонстрация.
_>Никто из зрителей-людей и не заметит разницы между 5000, 1000, и 200 Гц.
Отнюдь. Для вышепоказанного проектора это было бы очень заметно.

_>И сильно сомневаюсь, что у ТС именно такое устройство отображения. Хотя, кто знает...
У автора темы вообще не стоит задача показывать что-то чаще обновления монитора — прочти тему

Автор: prg1000
Дата: 08.10.14

.

Здравствуйте, MTD, Вы писали:

MTD>Зачем? Оператор все равно разницы не увидит между 60 и 1000, а задачу ты усложняешь сильно.

А Вы видели когда-нибудь визуализацию звука? 44КГц?

Здравствуйте, GarryIV, Вы писали:

GIV>Плевались от лапши, где в куче код бизнес логики, код представления и все остальное.

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

Здравствуйте, c-smile, Вы писали:

CS>не нужно оно никому
CS>кроме посетителей детского сада "Ромашка".

Показательное отношение к пользователям.

CS>Я подозреваю что ты не писал комеерческих приложений ...

Не спортивно так быстро сливаться.

CS>Пользователь по статистике принимает решение про покупку программы в течение первых 40 секунд. Включая время загрузки.
CS>Size matters.

Вот возьмем дистрибутив продукта где используется твоя поделка — Norton Antivirus. Его размер около 220 Мб, используй они Qt дистрибутив потолстел бы до 225 Мб. Size matters my ass.

CS>>>Sciter это сугубо UI.

MTD>>А вот это уже минус. Например, на WinCE в свое время словил достаточно проблем из-за того, что в стандартной библиотеке нет locale, в то время как Qt собирал на разной экзотике и всегда без проблем. Использовать дополнительные средства Qt никто не заставляет — используй, что угодно, видел много проектов где бизнес логика без капли Qt стыковалась с гуем через адептеры.

CS><html lang=ru> или <html lang=jp> и будет нужный locale handling при отображении. Твой business layer и знать про него не должен.

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

CS>Архитектура Web UI так и построена.

Знаю, знаю, вместо того чтобы дернуть метод объекта, который к тому же удобно забиндить и который удобно подскажет автокомплит, надо открывать доку и искать какой кусок XML сунуть в один из 30 мега-методов.

CS>И на Web как-то UI побогаче будет.

В чем измерять?

CS>И самого UI куда как поболее будет чем всех QT приложений вместе взятых.

Это о чем? И при чем тут QuickTime?

CS>>>Sciter использует всплывающие события (event bubbling). Никаких signal-slot костылей не требуется.
MTD>>И в чем костыльность? Без идеологического булшита про "нестандартный" С++ и препроцессор, а с практической точки зрения.

CS>Там много всяких "булшитных" штук про политики владения и, например, forever loop на singnal/slot-ах когда события по кругу ходят.

Я же просил без буллшита, конкретный пример.

CS>Ну да это в общем-то неважно если принципов не знаешь.

Экак тебя задела критика, второй раз на личности переходишь. Ну не виноват, я что твоя поделка и близко с Qt не стоит, что подтверждается ее популярностью.

CS>Какой еще религией? functional programming это по идее более удачная метафора для UI чем OOP. Это еще Smalltalk продемонстрировал.
CS>Reflection опять же... вельми полезная фича в UI и т.д.

Может быть, в Qt тоже эти модные штуки есть. Я правда не понял прелести, можешь пару примеров привести?

MTD>>Ой вот не надо сказок про то, как DOM ослабляет связи. Во-первых, не ослабляет, во-вторых, появляется куча кода который занимается сериализацией-десеарелизацией.

CS>А "сериализацией-десеарелизацией" при чём?

А как мои данные попадут в DOM и как данные от пользователя вытащить из DOM?

CS>Ну дык если захочешь построить динамические интерфейсы в QT то ты получишь Sciter. Толко в пятикратном размере дистрибуции.

И снова бла-бла-бла, пример будет?

Привет.
Задача — визуализация данных в виде графиков в реальном времени. Данные приходят с частотой 1 кГц их нужно отобразить на экране.
Серьезно с C++ не работал, только C, т.е. на данном этапе мне не важно с чем разбираться (т.к. все равно придется) — Qt, WinAPI, MFC, WTL...
Как-то давно писал на чистом WinAPI (тогда Qt даже не было), механизм у WinAPI мне кажется очень прозрачным, а вот скорость разработки, как мне кажется, низкая.
Посоветуйте на чем остановиться.
Платформа — только Windows.

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, Qbit86, Вы писали:

Q>>Зачем визуализировать с частотой выше 60 Гц?
X>чтоб сохранять в файл или видеопоток?

X>а по сабжу: Qt + QWT.

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

Здравствуйте, prg1000, Вы писали:

P>Задача — визуализация данных в виде графиков в реальном времени. Данные приходят с частотой 1 кГц их нужно отобразить на экране.

Я бы сказал, что это OpenGL в режиме 2D. В Qt для OpenGL есть специальные возможности.

Здравствуйте, prg1000, Вы писали:

P>Неправильно написал — данные приходят с такой частотой, их нужно отобразить на экране.

Если хочется тупо использовать компьютер в качестве олдскульного электронно-лучевого осциллографа, то таки да, без OpenGL или DirectX какого-нибудь не обойтись. И не факт, что сработает. Впрочем, даже если и будет работать "немножко не так", например, с пропуском (возможно, существенной) части сигнала, то обнаружить это будет тяжело, а доказать — практически невозможно Но я бы так не делал, если честно, а попробовал бы что-нибудь типа стробоскопии или накопления ("быстрый", возможно даже, ассемблерный код набирает отсчеты, а "медленный", высокоуровневый — отображает накопленный, скажем, за 100мс массив данных). QwtPlot (Qwt тут кто-то выше советовал) — вариант, но лично мне он не нравится исключительно из эстетических соображений.

Здравствуйте, prg1000, Вы писали:

P>Задача — визуализация данных в виде графиков в реальном времени. Данные приходят с частотой 1 кГц их нужно отобразить на экране.

Зачем? Оператор все равно разницы не увидит между 60 и 1000, а задачу ты усложняешь сильно.

Кстати, Windows и реальное время несовместимы. Так что не усложняй на ровном месте.

Здравствуйте, prg1000, Вы писали:

P>Задача — визуализация данных в виде графиков в реальном времени. Данные приходят с частотой 1 кГц их нужно отобразить на экране.

А что из себя представляют эти данные? Их же не надо отображать с частотой 1 кГц?

Здравствуйте, MTD, Вы писали:

MTD>Кстати, Windows и реальное время несовместимы.

Это другое значение реального времени.

Здравствуйте, slava_phirsov, Вы писали:

_>Если хочется тупо использовать компьютер в качестве олдскульного электронно-лучевого осциллографа, то таки да, без OpenGL или DirectX какого-нибудь не обойтись. И не факт, что сработает. Впрочем, даже если и будет работать "немножко не так", например, с пропуском (возможно, существенной) части сигнала, то обнаружить это будет тяжело, а доказать — практически невозможно Но я бы так не делал, если честно, а попробовал бы что-нибудь типа стробоскопии или накопления ("быстрый", возможно даже, ассемблерный код набирает отсчеты, а "медленный", высокоуровневый — отображает накопленный, скажем, за 100мс массив данных). QwtPlot (Qwt тут кто-то выше советовал) — вариант, но лично мне он не нравится исключительно из эстетических соображений.

Спасибо. Вот тут меня как раз интересует насколько свободно я смогу пользоваться возможностями OpenGL в Qt. Хватит ли этого для задачи?

Здравствуйте, ArtDenis, Вы писали:

AD>Здравствуйте, prg1000, Вы писали:

P>>Задача — визуализация данных в виде графиков в реальном времени. Данные приходят с частотой 1 кГц их нужно отобразить на экране.

AD>А что из себя представляют эти данные? Их же не надо отображать с частотой 1 кГц?

Конечно нет. У меня раз в секунду приходит 1000 точек, вот их мне каждую секунду и нужно видеть на экране. Тут уже дело реализации, конечно. Можно ведь их обновлять на экране каждую секунду, а можно и чаще, но не более чем частота обновления экрана монитора естественно (и уж точно не 1 кГц)))

Здравствуйте, watchmaker, Вы писали:

_>>Как насчет обмена между картой и процессором? Карточка будет получать данные от процессора. 1000 раз в секунду.
W>Для указанных объёмов — это мелочи.

Сила не в объеме. Для начала, процессор должен прочитать и обработать данные (неустановленным образом), а затем вызовом соответствующих функций API OpenGL (glDrawArrays ) отрисовать график. Он это будет успевать делать в реальном времени, 1000 раз в секунду, без перебоев? Почему-то думаю, что нет.


W>Отнюдь. Для вышепоказанного проектора это было бы очень заметно.

Я не видел, ты не видел, так что это уже из серии "сколько демонов уместится на кончике иглы"...


W>У автора темы вообще не стоит задача показывать что-то чаще обновления монитора — прочти тему

Автор: prg1000
Дата: 08.10.14

.

Задача — визуализация данных в виде графиков в реальном времени. Данные приходят с частотой 1 кГц их нужно отобразить на экране.

Автор, как я понял, хочет решить задачу "в лоб": пришли данные — перерисовал картинку. Вопрос: сработает ли такой подход с использованием аппаратного ускорения (OpenGL, DirectX). Я считаю — вряд ли.


P.S. "реальное время" отменяется — ТС написал ниже, что отображать данные достаточно 1 раз в секунду. 1000 точек. В таком случае применение OpenGL просто теряет смысл.

Здравствуйте, alexdpp, Вы писали:

A>зачем он нужен если есть бесплатный и мощный Qt?

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

Здравствуйте, c-smile, Вы писали:

CS>А кстати, вот ту картинку в моем сообщении... Сколько займет QT программеру воспороизвести? И какие классы (виджеты) требуются для этого? Кто-нибудь из QT профи может хотя бы вчерне описать?
Хм, не знаю часа 2-3 наверное, я с qwt не работал, сколько графику прикручивать не знаю, а так, стандартные классы + qss + qwt.
Классы: QLabel, QPushButton, QButtonGroup
QTabWidget — может нужно может нет, зависит от того что умеет qwt.

Здравствуйте, c-smile, Вы писали:

CS>Sciter тоже бесплатный (в binary form) на Windows и Linux. На Mac, да, небесплатный. Традиция на Mac такая — за всё платить.

Исходники доступны? И таки платный — это минус.

CS>Sciter это всего одна DLL размером 4mb (6mb на Mac).

Времена дискет в прошлом, сомнительно, что это большое достоинство.

CS>Sciter это сугубо UI.

А вот это уже минус. Например, на WinCE в свое время словил достаточно проблем из-за того, что в стандартной библиотеке нет locale, в то время как Qt собирал на разной экзотике и всегда без проблем. Использовать дополнительные средства Qt никто не заставляет — используй, что угодно, видел много проектов где бизнес логика без капли Qt стыковалась с гуем через адептеры.

CS>UI в Sciter это одна единственная сушность — HELEMENT (sciter::element в С++). Соответсвенно API это в принципе всего около 30 функций оперирующих HELEMENT. А не тонны классов на каждый чих.

Не понял чем это хорошо. Деление на разные классы для кнопок и меню логично и удобно. В Qt я забыв как точно называется метод, увижу подсказку автокомплита, у тебя видимо надо прочесть доку чтобы понять какой кусок XML сунуть в один из 30 мега-супер методов?

CS>Sciter использует всплывающие события (event bubbling). Никаких signal-slot костылей не требуется.

И в чем костыльность? Без идеологического булшита про "нестандартный" С++ и препроцессор, а с практической точки зрения.

CS>Code-behind-UI в Sciter это либо native code либо script, на выбор. Скрипт больше подходит для code-behind-UI — GC, first class functions, eval и пр.

Что все это означает? Пока что опять попахивает религией.

CS>CSS selectors как язык запросов (sql::select kind of thing) на DOM tree. Т.е. слабая связанность logic и UI.

Ой вот не надо сказок про то, как DOM ослабляет связи. Во-первых, не ослабляет, во-вторых, появляется куча кода который занимается сериализацией-десеарелизацией.

CS>Sciter поддерживает динамические интерфейсы когда UI дословно склеивается из разных html фрагментов.

В Qt я тоже могу легко строить динамические интерфейсы.

CS>Каждый уважающий себя программер должен знать нынче HTML/CSS. Sciter это оно в этом смысле.

Зачем?

CS>Мода на UI меняется раз в два года. Если не чаще. Нормальный, стандарный CSS это наше всё нынче.

В Qt это тоже есть.

CS>еще продолжать?

Пока не увидел ни одного плюса

Здравствуйте, c-smile, Вы писали:

CS>А кстати, вот ту картинку в моем сообщении... Сколько займет QT программеру воспороизвести? И какие классы (виджеты) требуются для этого? Кто-нибудь из QT профи может хотя бы вчерне описать?

Там для дизайнера работа — написать стили для виджетов, программист набросает и свяжет виджеты за час. Классы самые обычные, типа кнопка.

Здравствуйте, c-smile, Вы писали:

CS> frame() : window(SW_TITLEBAR | SW_RESIZEABLE | SW_CONTROLS | SW_MAIN) {}

Привет, 90-е!

CS> BEGIN_FUNCTION_MAP
CS> FUNCTION_0("helloWorld", helloWorld);
CS> END_FUNCTION_MAP

И снова привет, 90-е, привет милый MFC!

CS> sciter::string helloWorld() { return WSTR("Hello World"); }

Шо свои строки? Ай-ай, навязываем счастье бесплатно.

CS> const char* html =
CS> "<html>"
CS> "<script type='text/tiscript'>"
CS> "$(body).text = view.helloWorld();"
CS> "</script>"
CS> "<body>"
CS> "</body></html>";

Хардкод HTML в коде и аля JSP вызывающий у всего мирового Java сообщества лет 15 рвотные позывы — не понял, при дизайне была задача взять все худшие практики?

CS>> const char* html =
CS>> "<html>"
CS>> "<script type='text/tiscript'>"
CS>> "$(body).text = view.helloWorld();"
CS>> "</script>"
CS>> "<body>"
CS>> "</body></html>";

MTD>Хардкод HTML в коде и аля JSP вызывающий у всего мирового Java сообщества лет 15 рвотные позывы — не понял, при дизайне была задача взять все худшие практики?

Совершенно не за такой код блевали. Там была лапша sql, html и java.

Здравствуйте, GarryIV, Вы писали:

GIV>Совершенно не за такой код блевали. Там была лапша sql, html и java.

Там тоже в примерах более-менее казалось или ты тут кода в HTML не видишь?

MTD>>Зачем? Оператор все равно разницы не увидит между 60 и 1000, а задачу ты усложняешь сильно.

VF>А Вы видели когда-нибудь визуализацию звука? 44КГц?

А что смешного-то???

Здравствуйте, MTD, Вы писали:

GIV>>Совершенно не за такой код блевали. Там была лапша sql, html и java.

MTD>Там тоже в примерах более-менее казалось или ты тут кода в HTML не видишь?

Да я вижу разницу между лапшой, и этим.
Этот const char* html влегкую можно в отдельный html файл убрать.

Здравствуйте, MTD, Вы писали:

MTD>Здравствуйте, c-smile, Вы писали:

CS>> frame() : window(SW_TITLEBAR | SW_RESIZEABLE | SW_CONTROLS | SW_MAIN) {}

MTD>Привет, 90-е!

Не понял этого вот ... Что не так?

CS>> BEGIN_FUNCTION_MAP
CS>> FUNCTION_0("helloWorld", helloWorld);
CS>> END_FUNCTION_MAP

MTD>И снова привет, 90-е, привет милый MFC!

И это не понял ... в чем проблема-то?

CS>> sciter::string helloWorld() { return WSTR("Hello World"); }

MTD>Шо свои строки? Ай-ай, навязываем счастье бесплатно.

Ну ты хоть для прикола в SDK глянул-то ...

namespace sciter
  {
    ....
    // wide (utf16) string
    typedef std::basic_string<WCHAR> string;
    // ascii or utf8 string
    typedef std::basic_string<char>  astring;

  }

Ну т.е. явно не QT с его QString и пр. велосипедами.

WCHAR это или wchar_t или char16_t — UTF16 строки.

CS>> const char* html =
CS>> "<html>"
CS>> "<script type='text/tiscript'>"
CS>> "$(body).text = view.helloWorld();"
CS>> "</script>"
CS>> "<body>"
CS>> "</body></html>";

MTD>Хардкод HTML в коде и аля JSP вызывающий у всего мирового Java сообщества лет 15 рвотные позывы — не понял, при дизайне была задача взять все худшие практики?

Мимо кассы, это пример типа вот этого. В реальности все ресурсы сидят в resource section, VS поддерживает нативно HTML, CSS, script ресурсы.

Здравствуйте, GarryIV, Вы писали:

GIV>Этот const char* html влегкую можно в отдельный html файл убрать.

Давай, без бла-бла, чем это отличается от JSP?

<UL>
  <LI><B>Выражение.</B><BR>
      Имя вашего хоста: <%= request.getRemoteHost() %>.
  </LI>
</UL>

И ведь тоже в отдельный файл можно убрать, хоть в html, хоть в jsp!

CS>>> frame() : window(SW_TITLEBAR | SW_RESIZEABLE | SW_CONTROLS | SW_MAIN) {}

CS>Не понял этого вот ... Что не так?

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

MTD>>И снова привет, 90-е, привет милый MFC!

CS>И это не понял ... в чем проблема-то?

Ну если для тебя проблемы нет

CS>Ну ты хоть для прикола в SDK глянул-то ...

Как-то не горю желанием — код желание отбил.

CS>Ну т.е. явно не QT с его QString и пр. велосипедами.

Которые оказываются крайне кстати при кроссплатформенной разработке.

CS>WCHAR это или wchar_t или char16_t — UTF16 строки.

Почему именно UTF16? На Linux и Mac wchar_t 4 байта, под UTF32.

CS>Мимо кассы, это пример типа вот этого.

Чем то что у тебя отличается от JSP?

CS>В реальности все ресурсы сидят в resource section, VS поддерживает нативно HTML, CSS, script ресурсы.

Да-да, "в реальности представление у нас в jsp файлах и отделено от логики", проходили, знаем.

Здравствуйте, MTD, Вы писали:

MTD>Давай, без бла-бла, чем это отличается от JSP?

MTD>

MTD><UL>
MTD>  <LI><B>Выражение.</B><BR>
MTD>      Имя вашего хоста: <%= request.getRemoteHost() %>.
MTD>  </LI>
MTD></UL>
MTD>

MTD>И ведь тоже в отдельный файл можно убрать, хоть в html, хоть в jsp!

Еще раз, плевались не от этого. И тот html нормальный и эта jsp, только c:out забыли.
Плевались от лапши, где в куче код бизнес логики, код представления и все остальное.

Тут впрочем это злостный оффтопик, завязываю.

Здравствуйте, MTD, Вы писали:

MTD>Здравствуйте, c-smile, Вы писали:

CS>>Sciter тоже бесплатный (в binary form) на Windows и Linux. На Mac, да, небесплатный. Традиция на Mac такая — за всё платить.

MTD>Исходники доступны? И таки платный — это минус.

Исходники достуаны, я предоставлял доступ к моему SVN девелоперам которые выразили желание что-то добавить сделать самим.
Напимер таким образом был написан порт на WinMobile. Просто так ловить форки и все остальное — у меня просто нет времени да и не нужно оно никому
кроме посетителей детского сада "Ромашка".

CS>>Sciter это всего одна DLL размером 4mb (6mb на Mac).

MTD>Времена дискет в прошлом, сомнительно, что это большое достоинство.

Я подозреваю что ты не писал комеерческих приложений ...
Пользователь по статистике принимает решение про покупку программы в течение первых 40 секунд. Включая время загрузки.
Size matters.

CS>>Sciter это сугубо UI.

MTD>А вот это уже минус. Например, на WinCE в свое время словил достаточно проблем из-за того, что в стандартной библиотеке нет locale, в то время как Qt собирал на разной экзотике и всегда без проблем. Использовать дополнительные средства Qt никто не заставляет — используй, что угодно, видел много проектов где бизнес логика без капли Qt стыковалась с гуем через адептеры.

<html lang=ru> или <html lang=jp> и будет нужный locale handling при отображении. Твой business layer и знать про него не должен.

CS>>UI в Sciter это одна единственная сушность — HELEMENT (sciter::element в С++). Соответсвенно API это в принципе всего около 30 функций оперирующих HELEMENT. А не тонны классов на каждый чих.

MTD>Не понял чем это хорошо. Деление на разные классы для кнопок и меню логично и удобно. В Qt я забыв как точно называется метод, увижу подсказку автокомплита, у тебя видимо надо прочесть доку чтобы понять какой кусок XML сунуть в один из 30 мега-супер методов?

Ну тут хозяин — барин. 30 функций это все что нужно знать про взаимодейтсвет кода с UI layer.
Архитектура Web UI так и построена. И на Web как-то UI побогаче будет. И самого UI куда как поболее будет чем всех QT приложений вместе взятых.

CS>>Sciter использует всплывающие события (event bubbling). Никаких signal-slot костылей не требуется.
MTD>И в чем костыльность? Без идеологического булшита про "нестандартный" С++ и препроцессор, а с практической точки зрения.

Там много всяких "булшитных" штук про политики владения и, например, forever loop на singnal/slot-ах когда события по кругу ходят.
Ну да это в общем-то неважно если принципов не знаешь.

CS>>Code-behind-UI в Sciter это либо native code либо script, на выбор. Скрипт больше подходит для code-behind-UI — GC, first class functions, eval и пр.

MTD>Что все это означает? Пока что опять попахивает религией.

Какой еще религией? functional programming это по идее более удачная метафора для UI чем OOP. Это еще Smalltalk продемонстрировал.
Reflection опять же... вельми полезная фича в UI и т.д.

CS>>CSS selectors как язык запросов (sql::select kind of thing) на DOM tree. Т.е. слабая связанность logic и UI.

MTD>Ой вот не надо сказок про то, как DOM ослабляет связи. Во-первых, не ослабляет, во-вторых, появляется куча кода который занимается сериализацией-десеарелизацией.

А "сериализацией-десеарелизацией" при чём?

CS>>Sciter поддерживает динамические интерфейсы когда UI дословно склеивается из разных html фрагментов.

MTD>В Qt я тоже могу легко строить динамические интерфейсы.

Ну дык если захочешь построить динамические интерфейсы в QT то ты получишь Sciter. Толко в пятикратном размере дистрибуции.

Успешно использовал:
1) WinAPI или WTL + ActiveX-компонент NTGraph.
Могу выслать пример на WTL. Из минусов: нет легенды в принципе, нет зума.

2) Графики в Ultimate++ — 30Mb сама среда программирования, графики из под коробки (зума также нету).
Ultimate++ крайне рекомендую для таких утилит, Qt здесь не нужен.