Comments 23
Напишите, пожалуйста, обзор основных функций, преимуществ и сравните, к примеру, с wxWidgets и Qt. Не знаю, как другим, но мне было бы интересно почитать.
не туда написал — см. в корень
Я тоже заинтересовался. Скажите, а с изображениями как обстоит работа у этого фреймворка? В частности математические методы обработки. Приходилось сталкиваться?
З.Ы. Мне тоже необходимо будет для диссера реализовать программную часть, вот и интересуюсь.
З.Ы. Мне тоже необходимо будет для диссера реализовать программную часть, вот и интересуюсь.
Сам я пользовался базовыми возможности (загрузка иконок, соханения принтскринов и т.д.), глубоко не копал. Но на сайте (http://www.fox-toolkit.org/) у них доступны для загрузки библиотеки:
JPEG Image Support
PNG Image Support
TIFF Image Support
TIFF LZW Support
Качните, посмотрите в доках что они там предлагают.
JPEG Image Support
PNG Image Support
TIFF Image Support
TIFF LZW Support
Качните, посмотрите в доках что они там предлагают.
Сравнить, к сожалению, могу только с MFC — ни с Qt ни с wxWidgets не работал. Посмотрю обзоры этих фреймворков — попробую что-нибдуь выудить.
С полпинка — FOX не такой громоздкий как например Qt. Но база проработана достаточно хорошо. И из того что я знаю — FOX один из самых быстрых фреймворков. Преимущества фокса следует искать именно в этом. А еще в лицензии, в кросплатформенности (а у wxWidgets с этим по-моему проблемы). Вобщем попробую развить тему.
С полпинка — FOX не такой громоздкий как например Qt. Но база проработана достаточно хорошо. И из того что я знаю — FOX один из самых быстрых фреймворков. Преимущества фокса следует искать именно в этом. А еще в лицензии, в кросплатформенности (а у wxWidgets с этим по-моему проблемы). Вобщем попробую развить тему.
Хм… а что там в Qt более громозздкого?
Кстати. А по какой теме вообще дисер и при чем тут GUI? Ведь для проведения расчетов вполне подходит Matlab, Statistica или там Femlab + нормальный САПР в духе Компаса и тратить время на разработку GUI-я… мне кажется изобретать велосипед.
Я бы еще понял создание ПО в котором реализован какой-то новый, разрабатываемый вами алгоритм вычислений на основании какого-то нового математического метода. Из тех примеров подобного ПО о которых мне приходилось слышать ни один не обладал графическим интерфейсом. На выходе максимум графики.
Кстати. А по какой теме вообще дисер и при чем тут GUI? Ведь для проведения расчетов вполне подходит Matlab, Statistica или там Femlab + нормальный САПР в духе Компаса и тратить время на разработку GUI-я… мне кажется изобретать велосипед.
Я бы еще понял создание ПО в котором реализован какой-то новый, разрабатываемый вами алгоритм вычислений на основании какого-то нового математического метода. Из тех примеров подобного ПО о которых мне приходилось слышать ни один не обладал графическим интерфейсом. На выходе максимум графики.
Громоздкого? Точно не скажу. Читал. Но не пробовал. А вы сами FOX пробовали — а то ведь будет говорить как слепой с глухим :)
Дисер по аэрогидродинамике.
В основе расчетов собственная модификация существующего метода, приминимо к решению узкого круга задач. Ну а поскольку достаточно небольшие модели (далекие от реальных) решаются по несколько десятков часов — то необходимо была оптимизация приложения во всех отношениях: распаралеливание изсходя из внутренней структуры данных, оптимизация внутренней (достаточно громоздкой) стрктуры данных и т.д.
Кроме того, как я говорил, FOX содержит набор классов для работы с 3Д (начиная от запуска oepngl и заканчивая такими моментами как выделение (и множественное выделение) и перемещение объектов на сцене), перенсим (полностью компилируется в exe-шник не требуя никаких билиотек).
А если учесть, что все это связано с большим количеством эксперементов, с учетом и без учета большого количества свойств жидкостей, приминимо к данным задачам — то, сами пнимаете, при таких сроках расчета эксперементировать можно всю жизнь :)
ПОдобные проекты это как правило препроцессор (работа с графикой и GUI при создании модели, формировании начальных условий), решатель (расчетная часть) и постпроцессор (графика и GUI для расчета и просмотра полей скоростей и давлений по решению задачи). Поэтом по совокупности — пре- и пост-процессор было решено писать на FOX а решатель делать на С++ с использованием того же FOX.
Дисер по аэрогидродинамике.
В основе расчетов собственная модификация существующего метода, приминимо к решению узкого круга задач. Ну а поскольку достаточно небольшие модели (далекие от реальных) решаются по несколько десятков часов — то необходимо была оптимизация приложения во всех отношениях: распаралеливание изсходя из внутренней структуры данных, оптимизация внутренней (достаточно громоздкой) стрктуры данных и т.д.
Кроме того, как я говорил, FOX содержит набор классов для работы с 3Д (начиная от запуска oepngl и заканчивая такими моментами как выделение (и множественное выделение) и перемещение объектов на сцене), перенсим (полностью компилируется в exe-шник не требуя никаких билиотек).
А если учесть, что все это связано с большим количеством эксперементов, с учетом и без учета большого количества свойств жидкостей, приминимо к данным задачам — то, сами пнимаете, при таких сроках расчета эксперементировать можно всю жизнь :)
ПОдобные проекты это как правило препроцессор (работа с графикой и GUI при создании модели, формировании начальных условий), решатель (расчетная часть) и постпроцессор (графика и GUI для расчета и просмотра полей скоростей и давлений по решению задачи). Поэтом по совокупности — пре- и пост-процессор было решено писать на FOX а решатель делать на С++ с использованием того же FOX.
Нет, я FOX не пробовал. До сего момента дане про него не слышал. Ведь сейчас Qt можно считать дефакто библиотекой при кросс платформеной разработке. И не зря. Хотя конечно каждому свое…
Все же смысл GUI-я для данной задачи я так и не уловил. Препроцессор да, нужен, но он не обязательно должен иметь графический интерфейс потому как геометрию можно выполнить в САПРе в каком либо известном формате, а перечень начальных условий не такой уж обычно и большой. Без решателя ясное дело ни куда. Постпроцессор как GUI не более, чем наглядное представление данных, не более, чем любопытная фича которая совершенно не обязательна.
Ведь существует немалого готовых решений. Я, к примеру, для термодинамических расчетов использовал Femlab+Компас. Единсвенное чего хотелось это быстрый решатель. Очень было бы любопытно реализовать его с использованием GPU. Но так и заглохло. А знакомые авиционщики работали в Ansys-е, просчитывали термополе лопаток турбины и возникающие нагрузки.
Именно поэтому я и не улавливаю. Обычно есть работа не связана по теме с созданием чего либо вычислительного, то используются готовые решения. Поэтому меня и удивляет чисто программерская разработка в чисто не программерском проекте, собственно поэтому и уточнил про тему.
Все же смысл GUI-я для данной задачи я так и не уловил. Препроцессор да, нужен, но он не обязательно должен иметь графический интерфейс потому как геометрию можно выполнить в САПРе в каком либо известном формате, а перечень начальных условий не такой уж обычно и большой. Без решателя ясное дело ни куда. Постпроцессор как GUI не более, чем наглядное представление данных, не более, чем любопытная фича которая совершенно не обязательна.
Ведь существует немалого готовых решений. Я, к примеру, для термодинамических расчетов использовал Femlab+Компас. Единсвенное чего хотелось это быстрый решатель. Очень было бы любопытно реализовать его с использованием GPU. Но так и заглохло. А знакомые авиционщики работали в Ansys-е, просчитывали термополе лопаток турбины и возникающие нагрузки.
Именно поэтому я и не улавливаю. Обычно есть работа не связана по теме с созданием чего либо вычислительного, то используются готовые решения. Поэтому меня и удивляет чисто программерская разработка в чисто не программерском проекте, собственно поэтому и уточнил про тему.
Вы немного путаете задачи.
Проекты которые испльзовали FOX (в которых я работал) были как раз пре- и пост- процессорами.
Лично я писал в них интерфейсы для работы с солверами (если знаете: Permas, ABAQUS, Ansys, отчасти Nastran, топологические оптимизаторы OptiStruct, Tosca) поэтому я прекрасно понимаю о чем вы говорите. Есть набор типичных условий и набор интегральных характеристик в виде результатов.
Но в моем случае задачи ставились нетипичные. А для анализа промежуточных результатов требовались нетипичные интегральные характеристики.
Так чтобы не особо вдаваться в подробности…
Метод, который я развиваю на новый круг задач — очень чувствителен к дискретизации исследуемых (обтекаемых) поверхностей. Тоесть представте себе, что для обтекания сферы она (сфера) должны быть дискретизирована панелями строго определенным образом (так же как земля — паралели и мередианы). Решение с любой другой дискретизацией дает абсолютно неверный результат.
Далее. Данный метод не предполагает автоматического определения мест отрыва потока от поверхности — они задаются вручную.
Просмотр результатов так же имеет свои особенности. Иногда нужно посмотреть всю картину формирования вихревой пелены за объектом, то нужно получить ее срез, то нужно получить распределение скорости по этому срезу, но нужо получить пограниченые значения давления при подходе к поверхнсти с одной и другой стороны и т.д. Тоесть это речь еще не идет о типичных результатах Cx, Cy, полях скоростей и давлений.
Вы просто представте, что решалась не конкретная задача. А создавалась новая мат-модель, модификация метода. И, аналогично как и в программировании, вы ставите какие-то breakpoints, смотрите на промежуточные значения, отключаете временно определнные расчетные блоки и т.д. И когда на все это можно смотреть только на 3д — поскольку просмотр цифр вам не дает общей картины — приходится создавать интерфейсы. А еще если учесть что экспериментальная задача может считаться ночь, но увидеть неверное поведение решения можно буквально на ранних итерациях — нужна была возможность считать и смотреть уже решенные итерации одновременно. Как тут без GUI?
А там где можно было использовать что-то вншнее — это делалось. Для линейно алгебры использовались BLAS, LAPACK.
ПРИМЕР:
Нужно было получить эффект один на струе. Используя этот ментод его еще никто не получал. Вот сидел так, эксперементировал, наделал кучу всего для отлавливания условий в которых этот эффект проявляется — ничерта. Нет эффекта и все тут. А потом таки получил. При чем данный метод выдает этот физический эффект в гораздо более узких условиях. К примеру, в жизни он наблюдается на струях газа вытекающих в газ той же плотнтости и на струях жидкости вытекающих в газ. А метод его показывает только на струях жидкости. Значит его можно испльзовать на задачах именно жидкость-газ.
И на эту тему эксперементировал я долго — года полтора наверно. Помимо решения других задач.
Проекты которые испльзовали FOX (в которых я работал) были как раз пре- и пост- процессорами.
Лично я писал в них интерфейсы для работы с солверами (если знаете: Permas, ABAQUS, Ansys, отчасти Nastran, топологические оптимизаторы OptiStruct, Tosca) поэтому я прекрасно понимаю о чем вы говорите. Есть набор типичных условий и набор интегральных характеристик в виде результатов.
Но в моем случае задачи ставились нетипичные. А для анализа промежуточных результатов требовались нетипичные интегральные характеристики.
Так чтобы не особо вдаваться в подробности…
Метод, который я развиваю на новый круг задач — очень чувствителен к дискретизации исследуемых (обтекаемых) поверхностей. Тоесть представте себе, что для обтекания сферы она (сфера) должны быть дискретизирована панелями строго определенным образом (так же как земля — паралели и мередианы). Решение с любой другой дискретизацией дает абсолютно неверный результат.
Далее. Данный метод не предполагает автоматического определения мест отрыва потока от поверхности — они задаются вручную.
Просмотр результатов так же имеет свои особенности. Иногда нужно посмотреть всю картину формирования вихревой пелены за объектом, то нужно получить ее срез, то нужно получить распределение скорости по этому срезу, но нужо получить пограниченые значения давления при подходе к поверхнсти с одной и другой стороны и т.д. Тоесть это речь еще не идет о типичных результатах Cx, Cy, полях скоростей и давлений.
Вы просто представте, что решалась не конкретная задача. А создавалась новая мат-модель, модификация метода. И, аналогично как и в программировании, вы ставите какие-то breakpoints, смотрите на промежуточные значения, отключаете временно определнные расчетные блоки и т.д. И когда на все это можно смотреть только на 3д — поскольку просмотр цифр вам не дает общей картины — приходится создавать интерфейсы. А еще если учесть что экспериментальная задача может считаться ночь, но увидеть неверное поведение решения можно буквально на ранних итерациях — нужна была возможность считать и смотреть уже решенные итерации одновременно. Как тут без GUI?
А там где можно было использовать что-то вншнее — это делалось. Для линейно алгебры использовались BLAS, LAPACK.
ПРИМЕР:
Нужно было получить эффект один на струе. Используя этот ментод его еще никто не получал. Вот сидел так, эксперементировал, наделал кучу всего для отлавливания условий в которых этот эффект проявляется — ничерта. Нет эффекта и все тут. А потом таки получил. При чем данный метод выдает этот физический эффект в гораздо более узких условиях. К примеру, в жизни он наблюдается на струях газа вытекающих в газ той же плотнтости и на струях жидкости вытекающих в газ. А метод его показывает только на струях жидкости. Значит его можно испльзовать на задачах именно жидкость-газ.
И на эту тему эксперементировал я долго — года полтора наверно. Помимо решения других задач.
А какой получается размер какого-нибудь «Hello world» exe-шника с этой библиотекой?
Именно Hello World интересует?
Мой проект, 156 файлов (около 70-ти классов), 900Кб исходников = 1.2Мб exe
Мой проект, 156 файлов (около 70-ти классов), 900Кб исходников = 1.2Мб exe
Спасибо, впечатляет. И больше никакие dll-ки не требуются?
ну если работаете с opengl — то естественно он каким-то образом должен подключаться. Для windows — это opengl.dll, То же самое касается и остальных внешних библиотек.
Но никакие системные библиотеки по-умолчанию не требуются — все реализовано внутри FOX на С++.
Под windows в качестве компилятора использовался VS2003, под linux — sourcenavigator.
FOX компилируется в lib (a) и подключается к проекту.
Для примера, exe более подвязанного на фокс проекта со скриншота — тянул где-то мегайбай на 20
Но никакие системные библиотеки по-умолчанию не требуются — все реализовано внутри FOX на С++.
Под windows в качестве компилятора использовался VS2003, под linux — sourcenavigator.
FOX компилируется в lib (a) и подключается к проекту.
Для примера, exe более подвязанного на фокс проекта со скриншота — тянул где-то мегайбай на 20
А вот так выглядел привычный для меня на протяжении 3-х лет интерфейс:Сочувствую.
еще одна библиотека, которая умрет на фоне распространения QT
хотя я, чесно говоря, думал, что оно уже умерло
хотя я, чесно говоря, думал, что оно уже умерло
UFO just landed and posted this here
Sign up to leave a comment.
FOX-toolkit — быстрый framework для разработки приложений