Галерея UI написанных на MQL - страница 70

[Реter Konow]

Edgar Akhmadeev #:

... Написал код по имеющейся информации, получился красивый интерфейс. Дальше упёрся в пока нереализованное то, что нужно лично мне. ...

Кстати, то что тогда не работало, уже работает, ведь есть программное управление интерфейсом. Помню тогда мы не могли вывести параметры в Ваши таблицы. Теперь это запросто сделать. Ваша таблица может работать и выводить значения. Это уже реализовано в движке. Это так, к слову.

[Edgar Akhmadeev]

Не только знаю, что надо, но и делал макет. Вот исправленный Вами код и макет https://www.mql5.com/ru/forum/467909/page37#comment_53863397

Мне нужно именно (в ваших терминах) динамические и генерируемые таблицы. Т.е. программно добавлять неопределённое количество строк (ну, ограниченное здравым смыслом), заполнять их, удобно прокручивать саму таблицу, а не фрейм с ним. Чтобы заголовки оставались на месте.

Это то, что пока у Вас в работе. Именно поэтому я тихо сижу на попе и жду. Я сам не тороплюсь, и Вас не тороплю. Я собираюсь жить вечно. Пока получается.

[Реter Konow]

Edgar Akhmadeev #:

Не только знаю, что надо, но и делал макет. Вот исправленный Вами код и макет https://www.mql5.com/ru/forum/467909/page37#comment_53863397

Мне нужно именно (в ваших терминах) динамические и генерируемые таблицы. Т.е. программно добавлять неопределённое количество строк (ну, ограниченное здравым смыслом), заполнять их, удобно прокручивать саму таблицу, а не фрейм с ним. Чтобы заголовки оставались на месте.

Это то, что пока у Вас в работе. Именно поэтому я тихо сижу на попе и жду. Я сам не тороплюсь, и Вас не тороплю. Я собираюсь жить вечно. Пока получается.

Ясно. Ну что ж, динамичные и генерируемые таблицы нужны и мне и Вам, значит они будут. До Нового Года постараюсь закончить все поставленные задачи. 

[hini]

Как далеко мы продвинулись?

[Реter Konow]

hini #:
Как далеко мы продвинулись?

На сегодняшний день формируется концепция динамичных и генерируемых таблиц, которые по задумке должны работать в единой связке с научными графиками. Задача не только в разработке технической части - таблиц и графиков, но и нахождении путей "симбиоза" этих инструментов в аналитической работе. 

Приведу пример: 

1. Данные закачаны в файл. Специальные алгоритмы распределяют их по таблицам, рядам и  колонкам.

2. Пользователь обращается к нужной таблице, выделяет ряд и дабл-кликом вызывает построение кривой или диаграммы по цифрам из этого ряда или колонки. 

3. Пользователь выбирает нужную ячейку таблицы и вызывает построение новой таблицы по данным связанным с находящейся в ней параметром.

4. Пользователь переходит от таблиц к графикам, от графиков к таблицам и pie-чартам, "на лету" собирая или генерируя новые таблицы и графики. Простыми кликами и вводом параметров в окно, он может рассматривать данные под разными"углами" и в разных сочетаниях внутри появляющихся графических представлений. 

Все это несомненно способствует продуктивной работе и поиску связей и закономерностей в данных.

Планирую реализовать удобную систему динамичной работы с данными через таблицы, графики и диаграммы. 

Самая главное - правильная концепция. Она формируется дольше всего. Техническая реализация занимает относительно немного времени.

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

P.S.S. К выходу статьи подготовлю версию для кодо-базы, чтобы желающие могли скачать конструктор.

В общем, работы много.)

[Реter Konow]

Поведаю о своих планах.

1. Создать учебник по языку разметки.

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

2. Написать статьи по конструктору интерфейса и языку KIB.

Готовый учебный материал разделить на серию статей, добавив к ним коды, схемы, картинки и гифы.

3. Перед публикацией первой статьи открыть специализированную ветку с единственным предназначением - публикации шаблонов KIB-кода. Желающие смогут легко построить графический интерфейс, заимствуя готовые части. Они также смогут добавлять KIB-коды при желании.

4. Перед выходом первой статьи, выложить последнюю версию конструктора в кодо-базу. 

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

5. В начале статьи дать ссылку на конструктор и на инструкцию установки, а в конце статьи оставить ссылку на ветку с шаблонами. Таким образом, сразу после прочтения статьи, читатели смогут попробовать создать графический интерфейс, заимствовав готовые окна или группы элементов. Далее по ходу изучения будут эксперементировать и совершенствовать свои интерфейсы. 

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

7. Перед публикацией конструктора в кодо-базе мне необходимо проделать предварительную работу:

а) Перевести названия катологов на английский язык. 

б) Полностью убрать все предупреждения возникающие при компиляции конструктора (не KIB-кода).

в) Исправить некоторые замеченные ранее баги в работе элементов управления.

г) Поставить "заглушку" для дебаггинга пользовательского кода, подключенного к движку.

По задумке, движок будет отключатся во время дебаггинга простым комментированием его строки, а подключенными останутся только графическое ядро и функции обертки из служебного файла "UIDATA.mqh". На все остальные штатные функции конструктора, в специальном файле, будут поставлены "функции-пустышки" служащие "заглушками". Строка этого файла будет разкомментирована пользователем перед дебаггингом. 

Такова концепция, но на практике еще не проверял.

8. Первая статья будет для меня самой сложной, т.к. потребует вкратце описать весь конструктор и язык разметки целиком, предоставив читателям полное представление об их предназначении, воможностях и устройстве. Также, списком изложу содержание будущих статей и добавлю понятную схему будущего распределения учебного материала.

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

P.S. Изначально я решил опираться на пример известных статей по графическому интерфейсу Анатолия Кожарского - библиотеку Easy and Fast. Для меня это наиболее полный результат раскрывающий данную тематику. При этом я с уважением признаю вклад других талантливых авторов, совершивших достойные попытки создания UI-библиотек, до и после статей Анатолия. Специально хочу отметить Дмитрия Федосеева и Артема Тришкина. 

И так, приняв статьи Анатолия как стандарт качества и показатель профессионализма, я "примерил" их формат к своему материалу и был вынужден признать несовместимость. Различия в подходах и реализациях слишком велики. Поэтому, мне придется найти и шлифовать свой стиль, не забывая соответствовать высокому авторскому стандарту, заданному моими предшественниками.

[Реter Konow]

Процесс работы в визуальном редакторе графического интерфейса на МТ5.

4 года назад:

(Нажмите на картинку).

P.S. Контекст демонстрации изложен в посте ниже.

[Реter Konow]

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

В продлжении размышления возвращаюсь к тем же выводам: базовые функции визуального редактора в моей реализации УЖЕ имеются, а отсутствуют только комплексные инструменты. Однако сложные вещи можно создавать через язык разметки, что на практике гораздо быстрее и удобнее, чем в визуальном режиме. 

В пример приведу таблицы и древовидные списки - компоновать их вручную долго и муторно, а написать kib-кодом - легко и быстро,... особенно, при использовании шаблонов. Тогда зачем тратить силы на изобретение громоздких инструментов визуального редактирования для таблиц и списков, если их можно строить простым copy-paste? Смысла нет, это совершенно ясно. Но тогда в чем проблема? 

Все просто. Задача совместить работу языка разметки и имеющиеся на текущий момент возможности визуального редактора. При этом, ни к первому, ни ко второму, ничего нового добавлять не нужно, - их требуется только обьединить так, чтобы они дополняли друг друга.

Серьезно подумав над этим вопросом пришел к выводу, что даже если бы сейчас возникла возможность полностью перейти на визуальное построение GUI, отказался бы. Причина - нет желания терять возможность пользоваться шаблонами kib-кода и простой копипастой элементов или свойств в среде языка разметки. Это слишком ценное преимущество. Пожалуй, не только для меня, но для всех  будущих пользователей которые смогут делиться своими наработками или просто копировать части своих прежних разработок. Это незаменимая вещь. 

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

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

 Концептуально, язык разметки и визуальный редактор ДЕЙСТВИТЕЛЬНО конфликтуют. 

Есть несколько причин делающих эту задачу непростой:

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

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

2) При создании новых элементов и окон в втзуальном режиме, язык разметки их "не видит". То есть, при визуальном построении графического интерфейса язык разметки не обновляется. Ничего не "дописывается" к исходному kib-коду. Этот факт опять ведет к концептуальному разрыву визуального редактора и языка разметки. Это конфликт.

И так, как быть и что делать в этой ситуации? В чем состоит компромисс ведущий к симбиозу двух мощных инструментов построения GUI?

Попробую разобрать решение:

Главное: ограничить роль визуального редактора в моделировании интерфейса, оставив возможности языка неизменными. Практически это означает:

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

2. Оставить возможность редактирования позиций и установки свойств элементов и окон пользовательского GUI через окна настроек визуального редактора, поверх значений по умолчанию и кастомных значений пользователя в kib-коде. При этом, редактор будет писать и сохранять специальный файл с переопеделениями значений, из которого будет их загружать в ядро присваивая элементам. Фактически это означает новый тип шаблонов элементов "обработанных" в редакторе. Конфликтовать с шаблонами kib-кода они не будут, только переопределять установленные в них значения свойств.

В этом, по моему мнению, состоит эффективный симбиоз редактор и языка разметки.

P.S. Ирония в том, что технически воплотить задумку слияния возможностей редактора и языка можно за несколько дней, и это вполне реально, а вот продумать все детали их интеграции и взаимодействия в работе пользователя,... на это нужно больше времени. :) 

P.S. Но главный вывод, они МОГУТ и должны работать вместе, дополняя друг друга.

[hini]

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

[Реter Konow]

hini #:
То, что вы хотите сделать, займет очень много времени, и ваш исходный код... почти никто не сможет внести свой вклад в разработку, придется полагаться только на себя.

С первым утверждением категорически не согласен. Концепция визуального редактора не только была продумана 4 года назад, но и технически реализована в достаточной степени, чтобы позволить пользователю легко собрать простое окно настроек из базовых элементов управления. В конструкторе, например, есть информативная разметка с размерами и сеткой, есть панель настройки свойств и функции сохранения проекта и распечатки файла API, те же вспомагательные окна с рамками, картинками и шрифтами. Все как в языке разметки. 

Однако: для завершения визуального редактора обязательно необходим файловый навигатор. Он предоставит возможность выбора папок для загрузки или сохранения проектов, и хорошая новость в том, что файловый навигатор уже есть - я показывал его ранее на страницах ветки - и пусть он требует доработки, но базовый функционал работает.

Кроме файлового навигатора нужно разработать концепцию шаблонов по аналогии с kib-кодом. Сначала я считал это невозможным, но решение оказалось крайне простым: при наличии файлового навигатора, визуальный редактор сможет сохранять построенный интерфейс не как проект, а как шаблон. Ведь по сути, это одно и тоже. Причем,  сохранять в качестве шаблона будет не только целый проект, но и отдельные окна этого проекта. Это легко сделать, ведь сохраняется только часть построенного ядра и она же, потом, может загружаться в другой проект и пользователь сможет извлечь (копированием показанном в гифе выше) нужные элементы, а затем стереть из своего проекта этот шаблон. Фунция стирания окон и элементов у меня есть. Всё.

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

При наличии большого энтузиазма все можно сделать за месяц, полтора. Но сейчас я занят подготовкой материала для статей, поэтому эта работа откладывается.

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