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

Новый комментарий
 
Реter Konow:
Ядро - матрица. В ней умещаются все свойства обьектов. 

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


Петр, а у Вас есть опыт и примеры написания GUI не только в текущем варианте?

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

 

сделайте индикатор, который корректирует углы наклона нарисованных прямых, их точки пересечения и  пропорции эллипсов. При том что опорные точки выставлены в будущем

спустя два выходных  и какой-нить чёртов день-индюшки..

PS/ такое чувство что люди рисующие интерфейсы к торговле не причастны вообще

 
Maxim Kuznetsov:

сделайте индикатор, который корректирует углы наклона нарисованных прямых, их точки пересечения и  пропорции эллипсов. При том что опорные точки выставлены в будущем

спустя два выходных  и какой-нить чёртов день-индюшки..

PS/ такое чувство что люди рисующие интерфейсы к торговле не причастны вообще

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

 

Осмелюсь предположить что Петер кроме как на mql больше ни на чем не программирует. Все современные версии языков требуют знания работы с классами: джава, котлин, шарп, питон, с++ и так далее. Даже в 1С есть подобие классов в виде фиксированных типов объектов. Но это так, отступление.

С моем точки зрения система сборки интерфейса должна выглядеть следующим образом:

CForm Форма = new CForm;
Интерфейс.Добавить(Форма);
CButton КнопкаBUY= new CButton;
КнопкаBUY.Заголовок = "BUY";
КнопкаBUY.ЦветФона = clrBlue;
КнопкаBUY.Позиция(7,20);
Форма.Добавить(КнопкаBUY);

То есть создание интерфейса должно быть декларативным. Я даже не представляю как любой другой программист будет добавлять описание свойств элемента управления обращаясь по индексам.....

Уверен что даже для среднего программиста это будет головоломно, не говоря уже про начинающего.

 
Алексей Барбашин:

Осмелюсь предположить что Петер кроме как на mql больше ни на чем не программирует. Все современные версии языков требуют знания работы с классами: джава, котлин, шарп, питон, с++ и так далее. Даже в 1С есть подобие классов в виде фиксированных типов объектов. Но это так, отступление.

С моем точки зрения система сборки интерфейса должна выглядеть следующим образом:

То есть создание интерфейса должно быть декларативным. Я даже не представляю как любой другой программист будет добавлять описание свойств элемента у правления обращаясь по индексам.....

Уверен что даже для среднего программиста это будет головоломно, не говоря уже про начинающего.

Если элементов много и/или свойства зависят от индекса, то без проблем и наоборот сложно писать портянку, обращаясь к каждому отдельному. 

 
Roman:

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

Верно. Все во вселенной требует время.)
 
Алексей Барбашин:

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

2. Если необходимо добавить еще какое-то свойство тогда увеличивается размерность матриц.

3. Доступы к свойствам выполняются строго по индексам, так как у ячеек нет имен. 

У структуры хотя бы к именам полей можно обращаться.

Петр, ты... гигант...

Я например вижу это так (упрощенно):

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

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

На его основе можно создавать специализированные объекты:

То есть каждый последующий тип элемента управления просто дополняет нужными свойствами базовый тип.

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

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

2. Нет, размерность матрицы постоянна. Только 2 измерения.

3. Свойства обьектов в ядре упорядочены. У каждого свой индекс. Индексы названы через дефайны. При увеличении количества свойств обьектов матрица растет в ширину. Есть способы сдерживать ее рост и уплотнять обьекты внутри.

4. Класс, как описание обьекта, хорош, но механизм (коим и является код) эффективнее работает с ядром. Впрочем, не важно. Кому как удобно.

Из за разбросанности описания и хранения свойств обьектов (основные в базовом классе, остальные в наследниках) усложняется доступ и обработка. Добавьте ограничения видимости, модификаторы доступа и чужой язык, и получите реальное снижение эффективности не только механизма, но и разработки. Впрочем, это имхо.
 
Реter Konow:
1. Ядро - это одна глобальная матрица. Два измерения. Ядро строится спец. функцией, которая читает файл, где на языке разметки написано, какие окна и элементы нужно создать.

2. Нет, размерность матрицы постоянна. Только 2 измерения.

3. Свойства обьектов в ядре упорядочены. У каждого свой индекс. Индексы названы через дефайны. При увеличении количества свойств обьектов матрица растет в ширину. Есть способы сдерживать ее рост и уплотнять обьекты внутри.

4. Класс, как описание обьекта, хорош, но механизм (коим и является код) эффективнее работает с ядром. Впрочем, не важно. Кому как удобно.

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

Нисколько не усложняется, в этом и есть прелесть и мощь классов. Каждый следующий наращивает свою функциональность, базируясь на функциональности исходного объекта. В итоге всю основную функциональность (фокус, клики, выход за пределы элемента, перетаскивание, прорисовка) - все это реализуется на основе именно базовых объектов. Дальнейшая разработка и модификация, разработка новых элементов управления - все это уже никак не затронет базовую функциональность так как она создана на уровне, говоря Вашим языком: "ядра" библиотеки. При этом у объектов будут именно те типы данных, которые необходимы для конкретного свойства.

"Ядро строится спец. функцией, которая читает файл, где на языке разметки написано, какие окна и элементы нужно создать." - это просто жесть. То есть у Вас есть матрица, которая хранит все свойства, и еще есть файл с разметкой, которая указывает как именно нужно читать матрицу со свойствами... "Индексы названы через дефайны" - каждый индекс жестко привязан к дефайну. Случайная вставка дополнительного поля приведет к сдвигу свойств с последствиями. "При увеличении количества свойств обьектов матрица растет в ширину" - это я и имел ввиду, говоря про размерность (виноват, не верно применил термин). Создавая свой объект данных в виде класса вы избегаете всех этих сложностей. А это реальные сложности, которые на деле не нужны. Умеем же мы создавать себе сложности чтобы потом их успешно преодолевать. 

Да и классы не обязательно создавать иерархическими, да и вообще их не обязательно использовать. Но вот использовать структуры для того чтобы избавиться от лишних потоков данных - это целесообразно. ИМХО

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

 
Алексей Барбашин:

Нисколько не усложняется, в этом и есть прелесть и мощь классов. Каждый следующий наращивает свою функциональность, базируясь на функциональности исходного объекта. В итоге всю основную функциональность (фокус, клики, выход за пределы элемента, перетаскивание, прорисовка) - все это реализуется на основе именно базовых объектов. Дальнейшая разработка и модификация, разработка новых элементов управления - все это уже никак не затронет базовую функциональность так как она создана на уровне, говоря Вашим языком: "ядра" библиотеки. При этом у объектов будут именно те типы данных, которые необходимы для конкретного свойства.

"Ядро строится спец. функцией, которая читает файл, где на языке разметки написано, какие окна и элементы нужно создать." - это просто жесть. То есть у Вас есть матрица, которая хранит все свойства, и еще есть файл с разметкой, которая указывает как именно нужно читать матрицу со свойствами... Создавая свой объект данных в виде класса вы избегаете всех этих сложностей. А это реальные сложности, которые на деле не нужны. Умеем же мы создавать себе сложности чтобы потом их успешно преодолевать. 

Да и классы не обязательно создавать иерархическими, да и вообще их не обязательно использовать. Но вот использовать структуры для того чтобы избавиться от лишних потоков данных - это целесообразно. ИМХО

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

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

Я вообще склонен, менять или упрощать правила, отклонятся от общего курса, утверждать свое поверх чужого. Меня не изменить. 

За предложение спасибо. Вы можете пойти своим путем в разработке gui. Я свой путь уже проделал и повторять его в другом стиле смысла не вижу. Есть язык разметки, пара шагов до виз.редактора и примерно неделя до публикации. Осталось переделать панель задачь и мелкие баги выловить. Потом, вы дадите оценку моему труду. Надеюсь он будет всем полезным.

ЗЫ. После публикации, я смогу более подробно рассказывать о решениях, и это может помочь вам в создании аналога в классах.
 
Реter Konow:
Знаете, я здесь столько спорил о реализации своих и чужих решений, что устал. )) Просто, реально утомило. Мое мышление больше приспособлено под матрицу, мышление других под классы... не стоит на этом ломать копья.

Я вообще склонен, менять или упрощать правила, отклонятся от общего курса, утверждать свое поверх чужого. Меня не изменить. 

За предложение спасибо. Вы можете пойти своим путем в разработке gui. Я свой путь уже проделал и повторять его в другом стиле смысла не вижу. Есть язык разметки, пара шагов до виз.редактора и примерно неделя до публикации. Осталось переделать панель задачь и мелкие баги выловить. Потом, вы дадите оценку моему труду. Надеюсь он будет всем полезным.

В Вашем случае это не упрощение, а реальное усложнение. ИМХО

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