Делаем краудсорсовый проект по Canvas - страница 13

Новый комментарий
 
Igor Volodin:


Как по мне, проще создать команду по разработке продукта, члены которой в оговоренной степени получат профит от продаж продукта (возможно кто-то идеолог проекта, кто-то финансирует за долю, кто-то программит).

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

согласено, но саму либу делать краудсоросом открытой )
 
o_O:
Igor Volodin:


Как по мне, проще создать команду по разработке продукта, члены которой в оговоренной степени получат профит от продаж продукта (возможно кто-то идеолог проекта, кто-то финансирует за долю, кто-то программит).

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

согласено, но саму либу делать краудсоросом открытой )
Почитал я ветку и так и не понял, зачем это нужно - рисовать кнопку на Canvas с нуля. Можете объяснить без эмоций?
 
Alexey Volchanskiy:
Почитал я ветку и так и не понял, зачем это нужно - рисовать кнопку на Canvas с нуля. Можете объяснить без эмоций?
в выборе между ObjectCreate и ResourceCreate я выбираю последнее.
так как разрабы МТ не всесильны и напрягать их мелочными хотелками дорого по времени
 

Зачем это может пригодиться: 

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

2. Интерфейс масштабируемый. Можно усложнять приложение и оно не будет замедляться по причине удаления и создания большого количества граф. объектов. Расходы на перерисовку минимальные, это всего лишь замена картинки, за тысячные доли секунды.

3. Можно создать готовые контролы и обеспечить возможность создать новые т.к. можно предусмотреть собственный пул событий, например:

OnMouseDown - нажали ЛКМ

OnMouseUp - отжали ЛКМ

OnMouseHoverOn - навели курсор мыши на объект

OnMouseHoverOut - отвели курсор мыши с объекта

OnMouseClick - нажали и отжали ЛКМ в границах объекта воздействия

OnMouseDblClick двойной клик ЛКМ в границах объекта воздействия

OnDragStart - событие возникающее 1 раз в начале движения с нажатой ЛКМ

OnDragMove - событие генерящееся в процессе движения С ЛКМ

OnDragEnd - событие генерящееся после движения с ЛКМ

OnPut - объект скинули на другой объект

OnGet - объекту кинули другой объект

OnFocus - объект получил фокус

OnBlur - объект потерял фокус

OnResize - у объекта изменился размер

OnParentResize - у родителя объекта изменился размер

OnKeyPress - произошло нажатие клавиши

OnChange - изменилось значение поля

и т.д. 

 
Igor Volodin:

Зачем это может пригодиться: 

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

2. Интерфейс масштабируемый. Можно усложнять приложение и оно не будет замедляться по причине удаления и создания большого количества граф. объектов. Расходы на перерисовку минимальные, это всего лишь замена картинки, за тысячные доли секунды.

3. Можно создать готовые контролы и обеспечить возможность создать новые т.к. можно предусмотреть собственный пул событий, например:

OnMouseDown - нажали ЛКМ

OnMouseUp - отжали ЛКМ

OnMouseHoverOn - навели курсор мыши на объект

OnMouseHoverOut - отвели курсор мыши с объекта

OnMouseClick - нажали и отжали ЛКМ в границах объекта воздействия

OnMouseDblClick двойной клик ЛКМ в границах объекта воздействия

OnDragStart - событие возникающее 1 раз в начале движения с нажатой ЛКМ

OnDragMove - событие генерящееся в процессе движения С ЛКМ

OnDragEnd - событие генерящееся после движения с ЛКМ

OnPut - объект скинули на другой объект

OnGet - объекту кинули другой объект

OnFocus - объект получил фокус

OnBlur - объект потерял фокус

OnResize - у объекта изменился размер

OnParentResize - у родителя объекта изменился размер

OnKeyPress - произошло нажатие клавиши

OnChange - изменилось значение поля

и т.д.

Исчерпывающе, спасибо!

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

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

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

Выгода простая, озвученная Алексом в первых постах. Сообществом можно повлиять на разработчиков терминала, чтобы они внесли доработки в MQL платформу.

Мои надежды на доработки (напрямую касающиеся программных интерфейсов) такие:

  1. MQL приложение - как отдельный тип программ, не отменяющий другие (у него исключен onTick и нет возможности обратиться к дефолтному символу - это пережиток прошлого, но с возможностью получения торгового окружения любого символа и торговли, ведь все мультивалютно),  приложение не должно запускаться на чарте конкретного символа, а в своем собственном окне. Если перетащили такую программу на чарт - откроется новое окно. Да и перетаскивать не обязательно - 2 раза кликнули в навигаторе - также откроется новое окно. Это похоже на просьбу некоторых предоставить API к терминалу, для разработки на другом языке. Развивая тему - можно допустить, что такую программу, специальным образом скомпилированную, можно будет запустить и без терминала (а для безопасности, допускать такую компиляцию только через Маркет). Звучит может дико, а вдруг?
  2. Поддержка сторонних векторных шрифтов представленных отдельно лежащим файлом и возможность прикомпиляции как ресурса (заявлено в документации, но не реализовано)
  3. Ловля события прокрутки колесика мыши
  4. Блокировка системного меню по правой кнопке. Правая кнопка сейчас обрабатывается, но это бесполезно. 
  5. Работа с системным буфером обмена, для создания собственных контролов редактирования текста (включая многострочный редактор), пробел и enter уже можно блокировать - хорошо.
 

@Igor Volodin, @Комбинатор, @Anatoli Kazharski

ну тогда начну с наболевшего )
Вопрос, который меня больше всего волнует - некая универсальность/абстракция для хранения параметров отрисовки.

----

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

Но как их хранить? ведь контролы не всегда используют все параметры.
 + система усложняется тем, что у элементов есть различные состояния, которые должны по разному использовать цвета шрифта и фона. А именно когда элемент Активный, когда не реагирует на мышь (Disable), когда мышка над объектом (Over), или когда контрол отмечен (Select). и т.д. 
+ есть группы контролов - рельефиные (типа Button) и поля ввода (типа Edit, List), и когда это фон для их отрисовки

----

В текущей рабочей идее у меня есть минимальный элемент атрибута class GAttribBase, в котором находятся 5 основных параметров (шрифт/размер, цвет фона/бордюра, размер бордюра)

Из этих базовых элементов формируется массив для состояний class GAttribut, в котором задаются эти параметры для состояний (Active/Disabvle/Over/Select и т.д.)

И вот уже GAttribut заполняется для разных типов элементов - для рельефных, для редатируемых и т.д.


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

Конечно, если у некоего контрола нужно определить свои параметры отрисовки - то достаточно создать в контроле свой объект GAttribut и уточнить нужные цвета.

----

Данная модель рабочая, единый дизайн достигается в два счёта, все контролы берут цвета из общего массива.

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

-----

Вобщем - какие есть идеи, чтоб с одной стороны кодер был свободен от работы с цветами (чтоб он сразу использовал заложенные цвета и не заморачивался на них в начале)

А с другой стороны - чтоб если он захотел перекрасить какой-то один контрол на экране - то не влазил в дебри функции отрисовки и не выискивал что же из GAttribBase юзается и в каком случае.

 
o_O:

@Igor Volodin, @Комбинатор, @Anatoli Kazharski

Вобщем - какие есть идеи, чтоб с одной стороны кодер был свободен от работы с цветами (чтоб он сразу использовал заложенные цвета и не заморачивался на них в начале)

А с другой стороны - чтоб если он захотел перекрасить какой-то один контрол на экране - то не влазил в дебри функции отрисовки и не выискивал что же из GAttribBase юзается и в каком случае.

Хорошо, темы. 

Например, главный объект нашего приложения, назовем его App, ассоциирован с объектом ConcreteTheme.

Что такое объект темы:
цвета (background, foreground, disable, active и т.д.), базовые размеры, размеры шрифтов для стандартных случаев: titlesize, commonsize и т.д. , спрайты для: панелей, кнопок, чекбоксов и т.д.

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


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

Например SetBgColor(XRGB(255,0,128));

CView - основной класс обеспечивающий базовое взаимодействие на уровне событий
   - СRect - координаты
       - СPanel имеет bgcolor
             - CButton имеет объект состояния, у каждого состояния указывается bg
       - CText имеет цвет текста и свойства шрифта
   - СCircle

И т.д.

Если есть желание использовать xml для описания элементов,

то для каждого класса контрола или примитива нужно создать порождающий класс назовем его "билд-контейнер" в  котором будут маппиться атрибуты (bgcolor="(255,0,128)") на соответствующие методы ( SetBgColor(attrValue) ) класса. Такие билд-контейнеры будут цепляться парсером XML, на выходе получаем проинициализированный нужными значениями объект контрола, либо дефолтными, если ничего не было указано. 

 

тут Theme то же самое что у меня - набор GAttribut под разные типы контролов и их состояния.

но вы уже предлагаете первый шаг на пути к прозрачности для кодера - добавляем функции в конкретный контрол для изменения его свойств отрисовки (SetBgColor и т.д.)

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


такой вопрос тогда - Theme подразумевает избыточность неиспользуемых параметров? 

Допустим что у меня в базовом GAttribBase для некоего контрола (например кнопки) мы используем только цвет фона и размер, а остальные параметры - толщина границы и т.д. не используется в этом контроле.

То есть - у вас имеется базовый элемент для всех контролов? где хранится инфа "на все случаи", или же все контролы имеют только свои параметры без оферхеда универсальности?

 
o_O:

...

Вобщем - какие есть идеи, чтоб с одной стороны кодер был свободен от работы с цветами (чтоб он сразу использовал заложенные цвета и не заморачивался на них в начале)

А с другой стороны - чтоб если он захотел перекрасить какой-то один контрол на экране - то не влазил в дебри функции отрисовки и не выискивал что же из GAttribBase юзается и в каком случае.

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

Вот этого ещё пока нет: 

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

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

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

1...67891011121314151617181920...45
Новый комментарий
Причина обращения: