У меня самописное от начала и до конца. В начале страшно было. Попробовал нечто, скачанное с тырнета, и увидел, что это унылое тормознутое гамно. Сделал своё - оказалось совсем не страшно. К тому же у меня нет вот этих ваших пересекающихся окошек и прочих головняков. А сейчас в моде минимализм а-ля ведроид и вынь10 - там совсем всё просто.
А про грабли вы совсем не подумав ляпнули. Нет там никаких граблей. Всё просто и понятно. Просто нужно взять и сделать.

Ляпаете здесь Вы, я говорю исходя из опыта большого числа людей. Вы пробовали "нечто", а специалисты используют наработки, которые уже прошли Ваши стадии прыщей=) Если Вы готовы тратить свое время на написание готового, вместо того, чтобы направить его на другие вещи - дело Ваше, как в прочем, и каждого другого специалиста. Искренне желаю Вам удачи! ПС. да, свой компилятор и своя библиотека С тоже лучше чем скаченное "нечто" с тырнета.

Я не демократ, мне число людей по барабану. Мне качество нужно.

В таком случае библиотеку С и компилятор ARM Вы обязаны переписать с нуля. Без обид, но писать это самостоятельно - пустая трата времени


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

Демократ в Вашем понимании как-то отличается от его классического определения?

Сообщение отредактировал lleeloo - Apr 1 2016, 20:21

Это обобщение останется на Вашей совести.


Нельзя. Его нет.


Я в словарь не смотрел. Понимайте как хотите.

Благодарю за ответ. Вы полностью удовлетворили мои интересы


Да, лучше БУДУ писать то, что никому не надо=) Я имел ввиду, что взять готовый функционал и на нем реализовать свою идею проще, чем тратить время на написание гуя с нуля, а потом поверх его реализовывать свои идеи функционала. А то получается, что хотел написать терминал оплаты с графикой, а увяз на реализации ГУИ, вместо решения задач функционирвания и безопасности и удобства работы... как то так. Да и ГУЙ написал по причине лени писать GUI, ни в коем случае ни по какой другой причине

Сообщение отредактировал lleeloo - Apr 1 2016, 20:56

Например? Где "хороший и разный" гуй взять? Чтоб его можно было портировать в свой проект за адекватные сроки и усилия??
ЗЫ. Тоже писал свой интерфейс с нуля. Требовалась работа с несколькими окнами сразу, полноцветная графика с прозрачностью в формах и вне их, а так же подгружаемые ресурсные файлы форм, подгружаемые несколько типов шрифтов, до 64 виджетов на форму и т.п.
Работа не простая, скажу честно, много выявлено было глюков и недочетов, особенно в механизмах перемещения, частичного восстановления "затертых" фрагментов форм, особенно с учетом 2хслойной графики и многое другое. Потратил где-то около 3х месяцев на это дело, но получил именно то, что хотел.

Где все это можно взять готовое, с уже огороженными граблями?

лучше бы веб-браузер под stm кто написал

ИМХО, EmWin полностью отвечает тому, что написали. Свои виджеты добавляются без проблем, с окнами и скролами тоже нормально.
Но если хочется расширить функционал, дописываешь свои обработчики сверху встроенных, переопределив callback ф-ции или полностью свои виджеты рисуешь и подтягиваешь их как стандартные. Глюки на виджетах тоже правятся, через свои callback ф-ции, практически все виджеты поправляю. Менеджер памяти тоже есть, может не самый лучший, но он работает, единственое, что он вроде без сборщика мусора или дефрагментации. Альфа тоже есть. Всё, что нужно это нормальный драйвер LCD, и в данном случае подкрутить DMA2D по максимуму это большой плюс. Пока что ни чего лучше EmWin для мк не встречал то, что видел самописное, не выполняло и половины того, что нужно.
Ни кого ни к чему не призываю, каждый решает сам, чем ему заниматься.



Поддерживаю, это было бы очень полезным решением.

Порой "никому не надо" и "надо лично тебе" - оказывается синонимом. Всё зависит от поставленоой (или стоящей перед тобой) задачи.
Что есть "хороший ГУИ"? Универсальный? Для продажи да, согласен. Но мне для реального прибора нет!!! Трижды нет. Мне не надо чтобы размер выводимой кнопки задавалось в пикселях. То есть мне масштабируемая кнопка не нужна. И в этом случае построение этой кнопки на базе примитивов, которые используют пиксельную графику (ни разу ни с ускорителем), можно заменить несколькими выводами графической области. С преобразованием. Что увеличивает производительность в десятки раз!

Я писал несколько ГУИ. Опыт моей работы показывает, что драйвера, работа с железом, интерфейс пользователя и прочие мелочи составляют в лучшем случае 10% работы. Пишутся и вылизываются на начальном этапе, и как правило к ним не возвращаешься... Иногда расширяешь функционал, да и всё.
Применял и некоторые готовые. Из готовых мне больше понравилась идеология Микрочиповского. Недостатки те-же что и у uCOS-овского. Универсальность от железа, При попытке увязать конкретное железо, видишь что надо всю идеологию менять.

Вот в частности, у меня прибор коммерческого учёта энергоносителей. Месяцами и годами не выключается. В текущем меню более 500 пунктов. Текст составляет более 50000 строк. В пятницу звонили с ГродноАзота (некоторые вопросы были) там труба - 170 тыс м3 газа в месяц. Стоит FreeRTOS. У неё свой менеджер кучи. И тут Вы пишете "Менеджер памяти тоже есть, может не самый лучший, но он работает, единственое, что он вроде без сборщика мусора или дефрагментации.". Кучу у меня использует, в том числе Ethernet. У меня как HTTP сервер, так и TCP Modbus. Мне что потом искать почему это всё падает раз в месяц? Причём часть в закрытых библиотеках?
PS: в моём посте 25 приведен конкретный описанный мной хомут в примере от st при привязке ускорителя к ГУИ. При чём на самом деле там 2 хомута. Это я при тестировании на реальном железе увидел. Хомуты не критичные, не спорю. Видно что дралось из другого места и не вычистилось до конца. Почему никто не показал свою реализацию подключения? Видно там и общий подход... Применить DMA и остановить процессор на время выполнения операции. Это сильно конечно .... Нечего сказать. Даже гуёвина от Микрочипа при отсутствии ос позволяла отрабатывать в неблокирующем режиме ...

при удалении окна память высвобождается, но вот каким образом я не знаю, т.к. когда закрываю все окна, память возвращается к значению которое было (иногда +/- 10 байт). Утечки памяти там я не обнаруживал, если только сам её не высвободил. Лучший аллокатор или нет, возможности оценить нет, так он закрыт. Под него выделяется своя куча, так, что вашему менеджеру он не помеха. Как и писал раньше каждый решает сам, чем ему заниматься.
Про работу DMA я ни чего не писал, так что не пойму к чему это.
Запускал LCD со встроенными мк, на 429 пока перепрыгнуть не успел, хотя в ближайших планах. Интересно какие там грабли, т.к. скорость вывода сильно зависит от возможностей драйвера, а не только как GUI пиксели закрашивает.

Так я писал. Графический ускоритель - это DMA2D. В исполнении ST, по сути, обычный DMA канал умеющий копировать квадратную, а не линейную область памяти, с попутным преобразованием содержимого.
Для чего я его у себя приспособил, на сегодняшний момент:
1) Вывод прямой (вертикальной и горизонтальной).
2) Заливка области цветом.
3) Вывод текста. (Представляет собой вывод символа из сжатого состояния А4). При повороте используется программная часть (пока).
4) Вывод картинки из сжатого состояния L8.

Рассмотрим что есть отображения виджета, в общем случае. Вывод фона виджета с распаковкой L8 за 1 или N раз в зависимости от типа виджета. Вывод ндписи и/или иконки с распаковкой L8.
То есть всё делается ускорителем.

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

И есть описание самого объекта... ну например

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

Про ускоритель понятно, но это драйвер и на какой гуи его завязать без разницы, это однозначный плюс. Как дойдут руки, тоже буду подключать.
Разница в том, что emWin изменять размер, открывать/закрывать окна, наложение окон и т.п. Это всё я использую, поэтому не вижу смысла хранить в статике параметры окна которое может удалиться в любой момент. Написать это всё с нуля нет времени, а некоторое не имеет смысла. Подходы там я некоторые бы переделал, но нет последних исходников.

И как там сделать загружаемые файлы ресурсов, шрифтов?? К тому же использование динамической памяти - это зло в квадрате, неважно, какой там менеджер памяти...
Ну а это "Глюки на виджетах тоже правятся, через свои callback ф-ции, практически все виджеты поправляю." - в моем понимании вообще что-то с чем-то...
ЗЫ. раз уж EmWin считается лучшим, думаю пора свой продавать



Вот реально можете объяснить - зачем?? И что он делать будет способен. Я к тому, что на 2х ядерных ПК с частотами по 2ГГц с 2гигами оперы и то тормозит все это...



Закрытые либы - это зло. А на счет памяти, делаю каждую функцию(HTTP сервер, графика и т.п.) в своем пуле, если происходит переполнение провожу переинициализацию пула.

С точностью до наоборот. Начнёте подключать - поймёте.

Какое отношение работа с окнами имеет к динамике? У вас при создании окна выделяется память и инициализируются объекты. При закрытии окна - освобождается память. У меня просто при создании окна, программе которая отрисовывает, передаётся указатель на готовое окно с объектами. готовое окно размещено во флэши. А окна создаются на этапе компиляции.
Динамические объекты нужны только если вы на этапе компиляции не знаете как будет выглядеть ваш экран. Например, если вы делаете дисплей для ПЛК, и поставляете программу редактирования, то целесообразнее делать динамическую гуи. Статическая будет больше ресурсов забирать.
Для наглядности: если положение кнопки известно на этапе компиляции, то для статического объекта у вас во флэши находятся координаты x и y. Если неизвестно, то во флэши находится указатель на координаты, которые уже находятся в оперативной памяти. Для динамического объекта все поля объекта будут находится в оперативной памяти.