Создание графической библиотеки с нуля - страница 2

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

Уверен что с чистого листа и не стоит.

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

Люди потратили время и знания и было бы глупо это не использовать.

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

Нужно учиться на чужих ошибках. Свои мы и так создадим )))

Только ЗА!

 
Конечная цель библиотеки не ясна. 
Какие недостатки других библиотек она должна решить или расширить возможности? Или она должна стать принципиально новым инструментом? Это должно быть что-то  ГУИ - ориентированным или ориентированным на пользовательскую графику? 
Например, моя библиотека iCanvas была логическим продолжением библиотеки CCanvas с целью повысить удобство использования пользовательской графики, более короткий и интуитивно понятный код при кодинге, увеличиние скорости работы за счет ухода от использования асинхронных функций,  привязка к системе координат цена-время, а не только ХУ координаты экрана.
 
Nikolai Semko:
Конечная цель библиотеки не ясна.          
       

А это общая проблема всех графических библиотек, как я ни погляжу.

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

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

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

Тоже самое - библиотека Анатолия. Отличная структура, хорошая продуманность, но... уверен, в даже сам автор использует в этой библиотеке далеко-далеко не все возможности. За пользователей - думаю, можно и не вспоминать.

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


Как мне кажется, большинство этих проектов больше нужны для лелеяния ЧСВ их авторов. В общем-то, вещь нужная. Но, ждать при этом каких-то "конечных целей" не приходится. Это как ждать от моей Лиги ТС (представляющей собой просто набор всевозможных простых экспертов) мониторинга, прибыли, Грааля... хотя она является лишь индикатором работы различных принципов ТС на разных символах.

 
Georgiy Merts:

А это общая проблема всех графических библиотек, как я ни погляжу.

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

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

Вообще это раздел форум программистов ..... Тут не стоит искать финансовый смысл))) Сам предпочитаю решать эти вопросы отдельно от этого форума.

Nikolai Semko:
Конечная цель библиотеки не ясна. 
Какие недостатки других библиотек она должна решить или расширить возможности? Или она должна стать принципиально новым инструментом? Это должно быть что-то  ГУИ - ориентированным или ориентированным на пользовательскую графику? 
Например, моя библиотека iCanvas была логическим продолжением библиотеки CCanvas с целью повысить удобство использования пользовательской графики, более короткий и интуитивно понятный код при кодинге, увеличиние скорости работы за счет ухода от использования асинхронных функций,  привязка к системе координат цена-время, а не только ХУ координаты экрана.

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

 

Что то у меня полный круг получился 

С Иерархией все понятно.

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

А котрол - это не что иное как базовый элемент стилей - которые по идее должны быть после координат.

Логика  - у нас может быть элемент без стилей, но без координат не может

 
Alexandr Andreev:

Вообще это раздел форум программистов ..... Тут не стоит искать финансовый смысл))) Сам предпочитаю решать эти вопросы отдельно от этого форума.

Очень смешно.

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

 
Georgiy Merts:

Очень смешно.

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

Ну я как бы даже на авторство полученной библиотеки не претендую.... Что уж говорить о её фин составляющей

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

При мелкой необходимости можно и на коленке код собрать.

Хотя в идеале охота какую-то мини версию этого правильного соорудить. Чтобы минимум кода и максимум полезности. 

 
Nikolai Semko:
Конечная цель библиотеки не ясна. 
Какие недостатки других библиотек она должна решить или расширить возможности? Или она должна стать принципиально новым инструментом? Это должно быть что-то  ГУИ - ориентированным или ориентированным на пользовательскую графику? 
Например, моя библиотека iCanvas была логическим продолжением библиотеки CCanvas с целью повысить удобство использования пользовательской графики, более короткий и интуитивно понятный код при кодинге, увеличиние скорости работы за счет ухода от использования асинхронных функций,  привязка к системе координат цена-время, а не только ХУ координаты экрана.

Николай, приветствую.

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

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

Ну а в целом не будем загадывать что получится.

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

Николай, приветствую.

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

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

Ну а в целом не будем загадывать что получится.

Кратко, про инженерию :

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

с другой стороны, никто-же не запрещает. Нравится писать код, пиши... Перепишешь "А", но по своему, зато оно будет новое

 
Alexandr Andreev:

Что то у меня полный круг получился 

С Иерархией все понятно.

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

А котрол - это не что иное как базовый элемент стилей - которые по идее должны быть после координат.

Логика  - у нас может быть элемент без стилей, но без координат не может

С этим даже спорить не нужно, так и есть )))

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

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

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

Когда поступают события перемещения мыши мы в обработчике получаем абсолютные координаты точки курсора относительно графика. При проверке попадания курсора на форму или на любой из элементов необходимо производить сравнение абсолютной координаты курсора с текущим расположением элемента с учетом его позиционирования. То есть для формы это будет просто сравнение с ее текущими координатами и размером, а для кнопки это будет вычисление абсолютной позиции кнопки в системе координат. То есть координата Х для сравнения будет вычисляться следующим образом: Х = (Parent==null)?X():(X()+Parent.X()), где X() - функция класса, возвращающая позицию X элемента. Впрочем саму проверку на наличие родителя можно выполнять в самой этой функции. В итоге если у элемента есть родитель, тогда координата будет возвращаться как сложение координаты родителя с собственной координатой в родителе. По сути количество вложений элементов может быть произвольным и каждый из них позиционируется относительно того элемента, на котором располагается, а не относительно графика, поэтому абсолютная координата может быть рассчитана рекурсивно.

Причина обращения: