Разработка библиотеки графического интерфейса

[tae1980]

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

В общем, в настоящий момент идет сбор исходной информации, без учета языка реализации.

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

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

[digitalis]

интересно реализовать своё

- значит, есть свои идеи, своё видение предмета - чем плохи существующие и как их можно улучшить. А "я хочу хоть плохонькое, но своё, но понятия не имею как. Дяденьки, помогите!" - несерьезно это. Да и своё ли оно тогда уже будет ?

[Pavia]

tae1980

Сообщение от tae1980

библиотеки графического интерфейса

Такого понятия не существует. Есть UI, GUI, GL.

[jillitil]

Сообщение от tae1980

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

Вообще не понятно, одно другое исключает.

Начинать с графики будет сложновато, см. текстовый, он же консольный, режим. Если надо азы, придётся копаться в старье, например библиотека ncurses. Либо классика жанра Borland TurboVision, существующий в С и Паскаль вариантах и отличной помощью в одноимённой ИДЭ. Всё доступно с исходными кодами.

Вообще сначала попробуйте порисовать просто окошечки, создать некий апи для вывода на экран символов, перемещения курсора в окне, плюс перемещение окна. След шаг - буферизация окна, добавление нескольких окон. И далее систему сообщений или событий. HandleEvent(Event), GetEvent, PutEvent. Event - содержит нажатые клавиши, позицию мыши и её кнопки, тип сообщения ну и т.д. Это долгое и увлекательное занятие изучения UI обеспечит Вас удовольствием на всю зиму.

[tae1980]

Сообщение от digitalis

- значит, есть свои идеи, своё видение предмета - чем плохи существующие и как их можно улучшить. А "я хочу хоть плохонькое, но своё, но понятия не имею как. Дяденьки, помогите!" - несерьезно это. Да и своё ли оно тогда уже будет ?

Умный, да? Тогда прошли мне готовый GUI для CP/M на z80 (спектрум, Профи) точнее для ОС PQ-Dos. Эту ОС разработал Вадим Чертков в 2016 году.
На сколько знаю я, существует только одна реализации библиотека оконного интерфейса win12. Но она жутко кривая.

Ну почему всегда находятся "знатоки" который считают себя умнее всех? Я же не зря писал PS.

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

Сообщение от Pavia

Такого понятия не существует. Есть UI, GUI, GL.

Существуют. Или существовали в прошлом. Про реализацию "UI, GUI, GL" ни чего дельного найти не смог, только как использовать. А это я и так знаю. Так что написал тау умышленно, что бы казать что мне нужны "корешки, а не вершки".

Сообщение от jillitil

Вообще не понятно, одно другое исключает.
Начинать с графики будет сложновато, см. текстовый, он же консольный, режим. Если надо азы, придётся копаться в старье, например библиотека ncurses. Либо классика жанра Borland TurboVision, существующий в С и Паскаль вариантах и отличной помощью в одноимённой ИДЭ. Всё доступно с исходными кодами.

Писал подобные библиотеки на паскале в году так 2003. Но сейчас хочу более глобальное замутить.
Уже выкачала исходники TurboVision. Изучаю.

Сообщение от jillitil

Вообще сначала попробуйте порисовать просто окошечки, создать некий апи для вывода на экран символов, перемещения курсора в окне, плюс перемещение окна. След шаг - буферизация окна, добавление нескольких окон. И далее систему сообщений или событий. HandleEvent(Event), GetEvent, PutEvent. Event - содержит нажатые клавиши, позицию мыши и её кнопки, тип сообщения ну и т.д. Это долгое и увлекательное занятие изучения UI обеспечит Вас удовольствием на всю зиму.

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

В любом случае спасибо за ответ по существу. Ты первый из последних 50 человек.

[Pavia]

Сообщение от tae1980

В любом случае спасибо за ответ по существу. Ты первый из последних 50 человек.

Просто Вы недоговариваете по этому к вам такое и отношение.

Сообщение от tae1980

Существуют. Или существовали в прошлом. Про реализацию "UI, GUI, GL" ни чего дельного найти не смог, только как использовать.

Если бы вы сказали, что проектируете тогда вам проще было ответить.
А так по факту вы смешали в одном вопросе 3 задачи. Это значит, что вы не знаете ничего.

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

Графическая система как раз и состоит из UI, GUI, GL.

Из литературы советую:
Буч Г., Максимчук Р., и др.(Booch)-Объектно-ориентированный анализ и проектирование с примерами приложений-Вильямс (2008)
(Классика программирования) Вирт Н., Гуткнехт Ю.-Разработка операционной системы и компилятора. Проект Оберон-ДМК Пресс (2012)
(Библиотека программиста) Фаронов В.В.-Искусство создания компонентов Delphi-Питер (2005)

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

[Pavia]

Сообщение от tae1980

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

Судя по этому тексту вы не владеяте ООП, так что его стоит изучить.
Достаточно одного объекта типа IWidget с методом Draw. В нём и реализуется рисование. Для окна вам потребуется обычный рект с 4 параметрами.

Каждое окно хранит свой компоненты в виде объекта. Достаточно легко реализуется при помощи шаблонов. Просто создаёте список List:TList<IWidget>. И далее в методе Draw формы вызываете по очерёдно вызываете для них вывод List[i].Draw.
И ещё у IWidget завести общий объект style который хранит настройки стиля для отрисовки компонента: шрифт, тип линии, лип заливки, тип канта тип скругления.

Ещё удобно использовать слои для организации виджетов по горизнтали и вертикали в ряды и стоки и матрицы - такое сделано в QT поэтому советую посмотреть.

[tae1980]

Сообщение от Pavia

Просто Вы недоговариваете по этому к вам такое и отношение.
Если бы вы сказали, что проектируете тогда вам проще было ответить.
А так по факту вы смешали в одном вопросе 3 задачи. Это значит, что вы не знаете ничего.

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

Сообщение от Pavia

Из литературы советую:
Буч Г., Максимчук Р., и др.(Booch)-Объектно-ориентированный анализ и проектирование с примерами приложений-Вильямс (2008)
(Классика программирования) Вирт Н., Гуткнехт Ю.-Разработка операционной системы и компилятора. Проект Оберон-ДМК Пресс (2012)
(Библиотека программиста) Фаронов В.В.-Искусство создания компонентов Delphi-Питер (2005)

Спасибо. Буду курить.

Сообщение от Pavia

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

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

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

Сообщение от Pavia

И далее в методе Draw формы вызываете по очерёдно вызываете для них вывод List[i].Draw.

Можно, но очень долго. Тут придется выводить все окна целиком, независимо от их видимости на экране.
Так же это не показывает как решить проблему перекрывания окон, выхода окна за границу экрана, а так же что делать если содержимое окна больше его физического размера. Куда будет рисовать метод .Draw сразу в экран или каждое окно отрисовывается свой в свой буфер, а потом они выводятся на экран?
Метод описаны мною, позволяет разрешить большинство противоречий, при этом не хранить больших буферов, только логические. А то что буфера бьются на более мелкие (экран->окно->контейнер->форма) позволяет не прорисовывать лишнюю информацию при выводе.
Минусом является сложность структуры, и то что на одно место на экране может быть неограниченное количество буферов (например при перекрытии нескольких окон, место перекрытия будет храниться в буфере каждого окна), но так как они логические, это уменьшит расход памяти. То же самое графическими буферами у форм. Но тут спасением может быть решение, хранить такие буфера только у форм у которых на экране есть хотя бы один пиксель. Это же позволит ускорить вывод в формы которых нет на экране, так как вывод будет только логическим. Но это решение не позволит быстро пролистывать окна, так как нужно будет строит графические буфера для тех форм которые будут появляться на экране.

Вот я и ищу оптимальное решение.

[Pavia]

tae1980

Сообщение от tae1980

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

Это не вопрос GUI, это вопрос графической библиотеке. И там это решается отсечением.

Сообщение от tae1980

Так же это не показывает как решить проблему перекрывания окон

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

Что касается оптимизации добавьте флаг не прозрачности и блендинга и флаг поверхности. Если окно не прозрачное то оно попадает в тарфорет для отсечения.

Сообщение от tae1980

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

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

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

А по поводу сложности структуру. Я уже говорил начните снизу вверх. Сделайте как можно проще потом дорабатывайте и развивайте. А чтобы всё по 10 раз не переписывать заложите в основу абстрактные, вернее обобщённые классы. И интерфейсы проектируете так что-бы они были изолированны. Мне в этом плане понравилась архитектура QT. Хотя конечно там полно недочётов.

Есть формы которым нужен скролинг и есть которым не нужен. Значит абстрактый клсас должен содержать методы обоих форм. А вот при реализации вы если захотите сделаете 2 и более классов. Один который не оптимален и просто вызывает метод Draw, второй если окно непрозрачное вызывает копирование с экрана на экран. А затем оставшуюся часть как логический буфер передаёт в графическую библиотеку. В цикле проходит по дочерним компонентам и отсекает их. InresectRectInRect. И далее для оставшихся вызывает метод Draw они отисовываются. Отрисовываются они не целиком, а только то что "видно", обрезается по логическому буферу (ROI). Напоминаю что это уже делает графическая библиотека.

[Aliens_wolfs]

Умный, да? Тогда прошли мне готовый GUI для CP/M на z80 (спектрум, Профи) точнее для ОС PQ-Dos

Вот тема человека который до сих пор неплохо разрабатывает оболочку для MS DOS, может эта тема будет вам интересна. http://www.programmersforum.ru/showthread.php?t=310336