Пробовал, конечно же. Проект успешно компилируется в apk, запускается на устройстве, но… в релиз нельзя пускать такое ПО, даже если оно работает. Из того, что бросилось в глаза — интерфейс не нативный. Всякие мелочи вроде диалога выбора файлов — точная копия того, что вызывается на десктопе. Еще момент — как регулировать расположение виджетов на экране? В Qt поддерживаются только пиксели и лейауты. А если нужно задать величину в DP? Все тормозит ужасно (но это все из-за того, что в программе осуществляется парсинг тяжелых файлов), отрисовка не самая быстрая. Одним словом, Necessitas еще очень сырой, хотя разработчики проделали громадную работу (большая часть стандартных виджетов корректно портирована на платформу и простые проекты вполне неплохо переносятся).
Хм, неужели все так просто, я думал придется городить тонну кода для реализации подобных возможность. Это хорошо. Возьму на заметку такой метод, спасибо!
Первое что смущает — полное незнание *nix. Плюс, в сети сейчас AD, а значит, что придется возится с самбой. Первый блин комом и видится мне, прежде чем что-то заработает, мне придется пережить не одну бессонную ночь.
Вторая проблема попроще — не очень хороший интернет канал.
Основная проблема в том, что набор аниматоров заранее не определен. Тов. TheHorse выдвигает мысль о том, что стандартизировать все аниматоры не получится, и в любом случае список их будет фиксирован.
Попробовал использовать SVG в качестве языка для описания внешнего вида элемента. Ну что сказать, если грузить параметры (кисть, карандаш, координаты линий и.т.д.) из SVG в память — еще ничего, но тогда получается аналог моего велосипеда. А если же при перерисовке элемента выполнять рендеринг заново — начинаются жуткие тормоза.
Сейчас модуль — это бинарный файл, в который по определенному формату записаны параметры цвета для всех состояний элемента.
Вариант с DLL был отвергнут из-за проблем с разными компиляторами, модули предполагается писать на BCC, основное приложение — GCC.
Иерархия модуля на данный момент следующая:
Модуль = вектор фигур, вектор записей;
Фигура = вектор точек;
Запись = состояние элемента (число), вектор идентификаторов фигур, двумерный вектор параметров цвета для фигур (кисть, карандаш).
При отображении модулей на экране мы перебираем все записи в этом модуле, сравниваем текущий полученный параметр с тем, который зашит в записи. Если параметры совпадают — рисуем фигуры с заданным цветом. Т.е. в записи для одного элемента может быть определено несколько фигур (как в примере — контур, заливка).
При такой архитектуре модуля, каждая новая анимация или просто нестандартный элемент создает проблемы, и приходится исправлять процедуру прорисовки элемента.
Подсистема отображения (программа ?) реализовывает все возможные типы отображения (набор графических приметивов, их анимации и модификаторы отображения).
Да, все почти так, как вы описали. За тем исключением, что для каждого нового типа анимации сейчас приходится менять процедуру прорисовки элемента. Сейчас у меня есть только вращение элемента, а не далее пятницы мне сообщили, что будет еще элемент вроде progress bar'a. И видится мне, что заказчику потребуется еще очень много различных анимаций, эффектов и прочих красивостей.
Получается, как вы и сказали, мне нужен неограниченный набор возможностей при отображении модулей. Но вот я не представляю, как описывать все это на скриптовом языке. Вот например, в одном модуле приходит одно число, в соответстии с этим числом рисуем примитивы (самый простой вариант). Второй вариант: приходит 2 числа, одно из которых — внешний вид фигуры, другое — значение. Значение может быть конкретной температурой и отображаться цифрой, а может и с помощью стрелки, как на аналоговых приборах. Или вообще, с помощью прогресс-бара. Как это все можно описать с помощью скриптового языка?
Другими словами, вы предлагаете описывать внешний вид объектов с помощью XML для графики, т.е. SVG? У меня были мысли насчет этого формата, но я так и не придумал, как с помощью него делать анимацию.
Получается, человек, который будет писать модуль к программе, должен описать не только все состояния датчика, но и сделать анимацию, в случае, если она требуется в каком-то из состояний?
PS: Пишу на Qt, ПО заточено по Win, но возможность работы под Linux не исключается.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
