Этот топик читают: Гость
Гость
Ответов: 17029
Рейтинг: 0
|
|||
Редактировалось 5 раз(а), последний 2021-05-21 09:29:17 |
|||
карма: 0 |
|
Ответов: 4628
Рейтинг: 749
|
|||
Не понял, а зачем вместо конфигурации компонента "скриптовый язык"? Банально в среде предусмотреть компиляцию из командной строки и всех делов: подается файл sha, среда (без отображения пользовательского интерфейса) открывает схему, парсит (естественно, нужный пакет в среде должен быть настроен) и вызывает компиляцию.
|
|||
карма: 26 |
|
Ответов: 316
Рейтинг: 21
|
|||
Netspirit писал(а): Не понял, а зачем вместо конфигурации компонента "скриптовый язык"?Просто элементы для среды нужно делить как бы на две части: 1. Это собственно исходники - которые нужны только кодогенератору 2. Это описание структуры элемента, иконка и дополнительные формы к элементу - которые нужны только графической оболочке. (скриптовый язык для возможности гибко менять графическую оболочку) Нужно сделать среду выгодной, если например есть производитель электроники и он не хочет открывать исходники, что ему делать в случае когда мы все смешаем? В таком случае как я говорю, просто удаленной графической оболочке отсылается только то что нужно для графического описания структуры (тоесть создания sha) а исходники остаются и собираются на его сервере. |
|||
карма: 1 |
|
Ответов: 4628
Рейтинг: 749
|
|||
Текущая "структура" элемента предельно простая и её может понимать любая оболочка.
Исходники компонентов и сейчас не нужны на этапе построения схемы. |
|||
карма: 26 |
|
Ответов: 316
Рейтинг: 21
|
|||
Netspirit, Так где будем хранить обратную связь компонентов? Если например есть зависимости, нельзя одновременно вытаскивать два конфликтующих элемента или количество элементов ограничено из за физических ограничений обработчика, или элемент должен внести изменения в графическую среду при определенных условиях (сейчас этого нет). Дополнительные формы не хранятся в проекте
|
|||
карма: 1 |
|
Ответов: 4628
Рейтинг: 749
|
|||
LastLeader писал(а): нельзя одновременно вытаскивать два конфликтующих элементаПро "физические ограничения" - не понял. LastLeader писал(а): элемент должен внести изменения в графическую среду при определенных условияхКак это должно быть в HiOn - без понятия. Клиентская сторона может "генерировать события", посылая запрос на сервер и получая результат. А в "настольной" среде этим всем занимаются обработчики. LastLeader писал(а): Дополнительные формы не хранятся в проекте |
|||
карма: 26 |
|
Ответов: 316
Рейтинг: 21
|
|||
Что есть обработчик? Где он прописываеться?
[ |
|||
карма: 1 |
|
Ответов: 4628
Рейтинг: 749
|
|||
Уточним: я говорю не о том, что есть сейчас, а что могло бы быть по моей идее. Обработчики могут быть:
1) плагинами среды - лежат в своей папке, грузятся средой для всех пакетов 2) обработчиками пакета - лежат в отдельной папке пакета, грузятся при работе со схемами нужного пакета и могут ловить только события от схем данного пакета. 3) обработчиками компонента - лежат там же, где предыдущие, грузятся только для нужного компонента и прописаны в конфигурации компонента. Не вижу необходимости в этом типе обработчиков, так как их может заменять 2-ой тип. |
|||
карма: 26 |
|
Гость
Ответов: 17029
Рейтинг: 0
|
|||
Редактировалось 5 раз(а), последний 2021-05-21 09:29:17 |
|||
карма: 0 |
|
Ответов: 316
Рейтинг: 21
|
|||
[offtop]Забыл войти[/offtop]
Ну и с компиляторами та-же история, они должны быть стандартными и уникальными. Вообще можно сделать так что если два пакета используют один и тот-же обработчик то он автоматом копируется в плагины среды. |
|||
карма: 1 |
|
Ответов: 4628
Рейтинг: 749
|
|||
Я на кроссплатформенность не оглядываюся, хотя так же как и среду компилировать под другую платформу, так же и обработчики компилируются.
193.161.12.8 писал(а): и просто обработчики написать на джаваскрипт?И так далее. LastLeader писал(а): если два пакета используют один и тот-же обработчик то он автоматом копируется в плагины среды |
|||
карма: 26 |
|
Ответов: 1731
Рейтинг: 68
|
|||
Ну что там с проектом?
Картинка |
|||
карма: 1 |
|
Ответов: 1841
Рейтинг: 369
|
|||
Cosinus, идёт полным ходом
Довольно много времени заняло изучение литературы по C++ и Qt, но оно того стоило... Возможности поражают Несмотря на огромное к-во готовых классов, приходится иногда прибегать к своим реализациям различного функционала. Вот мой старый тестовый полигон, на котором время от времени кое-что проверяю: Статическая сборка (win32) Для работы с рабочим полем среды (сцены), в качестве основы, был выбран класс QGraphicsScene, который предоставляет внушительные возможности работы с графическими примитивами. Кроме того, данный класс скорее всего будет применён и в дизайнере, т.к. он позволяет добавлять ещё и контролы (widget), которыми можно также манипулировать как и любыми другими примитивами, а также применять трансформацию (масштабирование, повороты и т.д.). Прямоугольники, связывающие линии, точки - это всё объекты сцены. Каждый такой объект, наследует сотни интересных методов и свойств, включая переопределение различных методов для взаимодействия с целевым объектом или перехватом событий. |
|||
карма: 1 |
|
Гость
Ответов: 17029
Рейтинг: 0
|
|||
Редактировалось 5 раз(а), последний 2021-05-21 09:29:17 |
|||
карма: 0 |
|
Ответов: 1841
Рейтинг: 369
|
|||
Возник вопрос относительно структуры пакетов.
На данный момент, у меня используется иная структура пакетов/элементов относительно базового HiAsm:
Над форматом описания элементов пока не думал, но, он точно будет отличаться от текущего. Идея в том, что будет файл описания элемента (как для пакета), и в нём, кроме описания элемента, можно будет указать файл(ы) скрипта и иконок (состояний). Вот так вот выглядит описание пакета (json), но, его ещё доработать нужно будет:
Всё это парсится при запуске приложения. Собственно вопрос: Стоит использовать новую структуру пакетов/элементов, или оставить прежнюю? Также будут интересны идеи/мысли по этому поводу. ------------ Дoбавленo в 19.06: Директорию с элементом, думаю, можно упростить:
------------ Дoбавленo в 19.14: Конвертировать элементы из старого формата в новый, не составит труда. Описание будет в том же текстовом json. Сохранять что либо в бинарном формате, не вижу пока что смысла. |
|||
карма: 1 |
|