Вверх ↑
Этот топик читают: Гость
Гость
Ответов: 17029
Рейтинг: 0
#166: 2014-05-14 23:59:13 правка | ЛС | профиль | цитата


Редактировалось 5 раз(а), последний 2021-05-21 09:29:17
карма: 0

0
Ответов: 4628
Рейтинг: 749
#167: 2014-05-15 11:02:12 ЛС | профиль | цитата
Не понял, а зачем вместо конфигурации компонента "скриптовый язык"? Банально в среде предусмотреть компиляцию из командной строки и всех делов: подается файл sha, среда (без отображения пользовательского интерфейса) открывает схему, парсит (естественно, нужный пакет в среде должен быть настроен) и вызывает компиляцию.
карма: 26

0
Ответов: 316
Рейтинг: 21
#168: 2014-05-15 18:35:14 ЛС | профиль | цитата
Netspirit писал(а):
Не понял, а зачем вместо конфигурации компонента "скриптовый язык"?

Просто элементы для среды нужно делить как бы на две части:
1. Это собственно исходники - которые нужны только кодогенератору
2. Это описание структуры элемента, иконка и дополнительные формы к элементу - которые нужны только графической оболочке. (скриптовый язык для возможности гибко менять графическую оболочку)

Нужно сделать среду выгодной, если например есть производитель электроники и он не хочет открывать исходники, что ему делать в случае когда мы все смешаем? В таком случае как я говорю, просто удаленной графической оболочке отсылается только то что нужно для графического описания структуры (тоесть создания sha) а исходники остаются и собираются на его сервере.
карма: 1

0
Ответов: 4628
Рейтинг: 749
#169: 2014-05-15 18:38:08 ЛС | профиль | цитата
Текущая "структура" элемента предельно простая и её может понимать любая оболочка.
Исходники компонентов и сейчас не нужны на этапе построения схемы.
карма: 26

0
Ответов: 316
Рейтинг: 21
#170: 2014-05-15 18:59:47 ЛС | профиль | цитата
Netspirit, Так где будем хранить обратную связь компонентов? Если например есть зависимости, нельзя одновременно вытаскивать два конфликтующих элемента или количество элементов ограничено из за физических ограничений обработчика, или элемент должен внести изменения в графическую среду при определенных условиях (сейчас этого нет). Дополнительные формы не хранятся в проекте
карма: 1

0
Ответов: 4628
Рейтинг: 749
#171: 2014-05-16 11:20:21 ЛС | профиль | цитата
LastLeader писал(а):
нельзя одновременно вытаскивать два конфликтующих элемента
Обработчик события "Перед вставкой элемента на рабочее поле" выполняет проверку и возвращает результат, проверив который среда может добавить или отменить вставку элемента.
Про "физические ограничения" - не понял.
LastLeader писал(а):
элемент должен внести изменения в графическую среду при определенных условиях
Ну, не элемент, а обработчик нужных событий. Поскольку количество обработчиков не ограничивается, можно написать обработчик специально для этого элемента; он подпишется на нужные события и будет контролировать только этот элемент (или всё, что угодно, при надобности).

Как это должно быть в HiOn - без понятия. Клиентская сторона может "генерировать события", посылая запрос на сервер и получая результат. А в "настольной" среде этим всем занимаются обработчики.
LastLeader писал(а):
Дополнительные формы не хранятся в проекте
Это одна из задач, которую можно выполнить указанным в моей диаграмме "сохранением внутри схемы произвольных данных обработчиками". Например, в пакете Android можно делать различный дизайн окна для разных дисплеев, ориентации и т.п. Редактор GUI мог бы хранить внутри схемы альтернативные макеты, а кодогенератор вытаскивал бы и сохранял их в папку проекта.
карма: 26

0
Ответов: 316
Рейтинг: 21
#172: 2014-05-16 16:25:18 ЛС | профиль | цитата
Что есть обработчик? Где он прописываеться?
[
карма: 1

0
Ответов: 4628
Рейтинг: 749
#173: 2014-05-16 16:43:41 ЛС | профиль | цитата
Уточним: я говорю не о том, что есть сейчас, а что могло бы быть по моей идее. Обработчики могут быть:
1) плагинами среды - лежат в своей папке, грузятся средой для всех пакетов
2) обработчиками пакета - лежат в отдельной папке пакета, грузятся при работе со схемами нужного пакета и могут ловить только события от схем данного пакета.
3) обработчиками компонента - лежат там же, где предыдущие, грузятся только для нужного компонента и прописаны в конфигурации компонента. Не вижу необходимости в этом типе обработчиков, так как их может заменять 2-ой тип.
карма: 26

0
Гость
Ответов: 17029
Рейтинг: 0
#174: 2014-05-16 18:01:10 правка | ЛС | профиль | цитата


Редактировалось 5 раз(а), последний 2021-05-21 09:29:17
карма: 0

0
Ответов: 316
Рейтинг: 21
#175: 2014-05-16 18:05:03 ЛС | профиль | цитата
[offtop]Забыл войти[/offtop]
Ну и с компиляторами та-же история, они должны быть стандартными и уникальными. Вообще можно сделать так что если два пакета используют один и тот-же обработчик то он автоматом копируется в плагины среды.
карма: 1

0
Ответов: 4628
Рейтинг: 749
#176: 2014-05-16 18:38:23 ЛС | профиль | цитата
Я на кроссплатформенность не оглядываюся, хотя так же как и среду компилировать под другую платформу, так же и обработчики компилируются.
193.161.12.8 писал(а):
и просто обработчики написать на джаваскрипт?
Основной смысл здесь - сделать обработчиками то, что не реализовано в среде. А возможности любого скриптового языка будут ограничены тем, что реализовано в интерпретаторе этого языка. Если этот скрипт будет интерпретировать и выполнять среда, то в среде нужно будет обеспечить практически всё API системы. Например, работа с файлами: обработчик (например, кодогенератор) может вытащить из схемы данные, на основе них сгенерировать какой-то файл, который будет затем скомпилирован при компиляции. Или редактор свойства типа "Картинка PNG" может загружать изображения любого типа и преобразовывать в PNG - придется написать в интерпретаторе функции конвертации изображений, чтобы их можно было вызывать из скрипта. Или редактору GUI нужен доступ как к внутренностям схемы (это обеспечит среда), так и к API-функциям для работы с оконными элементами, GDI и прочим.
И так далее.

LastLeader писал(а):
если два пакета используют один и тот-же обработчик то он автоматом копируется в плагины среды
Ну, если надо...
карма: 26

0
Ответов: 1731
Рейтинг: 68
#177: 2014-08-11 21:58:52 ЛС | профиль | цитата
Ну что там с проектом?
Картинка


карма: 1

0
Ответов: 1841
Рейтинг: 369
#178: 2014-08-12 20:18:06 ЛС | профиль | цитата
Cosinus, идёт полным ходом


Довольно много времени заняло изучение литературы по C++ и Qt, но оно того стоило...
Возможности поражают
Несмотря на огромное к-во готовых классов, приходится иногда прибегать к своим реализациям различного функционала.
Вот мой старый тестовый полигон, на котором время от времени кое-что проверяю:
Статическая сборка (win32)

Для работы с рабочим полем среды (сцены), в качестве основы, был выбран класс QGraphicsScene, который предоставляет внушительные возможности работы с графическими примитивами.
Кроме того, данный класс скорее всего будет применён и в дизайнере, т.к. он позволяет добавлять ещё и контролы (widget), которыми можно также манипулировать как и любыми другими примитивами, а также применять трансформацию (масштабирование, повороты и т.д.).

Прямоугольники, связывающие линии, точки - это всё объекты сцены.
Каждый такой объект, наследует сотни интересных методов и свойств, включая переопределение различных методов для взаимодействия с целевым объектом или перехватом событий.
карма: 1
0
Гость
Ответов: 17029
Рейтинг: 0
#179: 2014-11-24 17:57:47 правка | ЛС | профиль | цитата


Редактировалось 5 раз(а), последний 2021-05-21 09:29:17
карма: 0

0
Ответов: 1841
Рейтинг: 369
#180: 2014-11-24 18:14:22 ЛС | профиль | цитата
Возник вопрос относительно структуры пакетов.
На данный момент, у меня используется иная структура пакетов/элементов относительно базового HiAsm:
<BaseBinary>(file)// Бинарный файл
Packages(dir) //Каталог, в котором будут расположены пакеты
--------base(dir) //Один из пакетов (базовый)
------------package(file) //Файл информации о пакете
------------elements(file) //Файл информации об элементах
------------elements(dir) //Директория, в которой будут расположены элементы
--------------------AccessFTP(dir) //Директория элемента, в которой хранятся все необходимые файлы
-----------------------------AccessFTP(file) //Файл описания элемента
-----------------------------AccessFTP.code(file) //Скрипт
-----------------------------AccessFTP.png(file) //Состояние
-----------------------------AccessFTP_new.ico(file) //Состояние
-----------------------------AccessFTP_end.ico(file) //Состояние

Над форматом описания элементов пока не думал, но, он точно будет отличаться от текущего.
Идея в том, что будет файл описания элемента (как для пакета), и в нём, кроме описания элемента, можно будет указать файл(ы) скрипта и иконок (состояний).

Вот так вот выглядит описание пакета (json), но, его ещё доработать нужно будет:
{
"name": "base",
"shortDescription": "Базовый пакет",
"description": "Пакет с набором базовых элементов",
"visible": true,
"base": true,

"projects": [
{
"name": "testProject",
"shortDescription": "Тестовый проект",
"description": "Проект для тестирования базового пакета",
"entryElement": "entryElement"
}
]
}

Всё это парсится при запуске приложения.
Собственно вопрос: Стоит использовать новую структуру пакетов/элементов, или оставить прежнюю?
Также будут интересны идеи/мысли по этому поводу.


------------ Дoбавленo в 19.06:
Директорию с элементом, думаю, можно упростить:
AccessFTP(dir) //Директория элемента, в которой хранятся все необходимые файлы
---------element(file) //Файл описания элемента
---------script(file) //Скрипт
---------main.png(file) //Состояние
---------new.ico(file) //Состояние
---------end.ico(file) //Состояние
Название самих состояний (иконок) неважно, они всё равно будут описаны в файле описания.
------------ Дoбавленo в 19.14:
Конвертировать элементы из старого формата в новый, не составит труда.
Описание будет в том же текстовом json.
Сохранять что либо в бинарном формате, не вижу пока что смысла.
карма: 1
0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)