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

[kvitaliy]

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

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

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

[_Bers]

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

Достаточно одного объекта типа IWidget с методом Draw. В нём и реализуется рисование.

прохладная история, Бро.

[Pavia]

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

прохладная история, Бро.

Я просто ждал LV1974, когда он придёт, возмутится и напишет что надо 27-127 классов. Не помню сколько у него.
А так то тема большая, во если бы ТС схему деления приложил, тогда бы можно было предметно рассуждать. А то так не понятно, то ли графическая библиотека заимствованная: к примеру AGG либо же вновь разрабатываемая. Да и с геометрическими расчётами аналогично.
Сколько и каких классов оставить или убрать?
Я же простые решения предлагаю. А если кто хочет сложные, то он может открыть в брауезе страницу с флагами. Там много всяких настроек для графической системы: таких как рендеринг в параллельном потоке и опережающий рендеринг.

[jillitil]

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

Уже выкачала исходники
__________________
С уважением, Алексей.

Achtung, minen!!!

По делу: начинаете с реализации функции рисования всех примитивов в буфер. Да да, свои собственные, с самого нуля, хорошо оптимизированные иначе будет безбожно тормозить, потянете? Если нет тогда добро пожаловать в текстовый режим. Макс размер буфера 80х25х2=4КБ памяти на весь экран. Достаточно реализовать DrawChar(x,y,char,attribute) и DrawBuffer(x,y,&buf). Это самые низкоуровневые функции рисования, ничто больше не должно рисовать "физически". Далее 2 основных элемента - компонент и его наследник контейнер. Компонент имеет функции IsExposed:boolean {если элемент виден на экране - true else false};
Draw() отрисовывает компонент и содержит реальные вызовы DrawChar.
Дополнительно DrawComponent - обычно его надо вызывать для прорисовки, содержит if IsExposed then Draw. Идея ясна - отрисовываем только когда компонент виден на экране.

Теперь к DrawChar: Контейнер имеет буфер рисования. Вызываются все Draw'ы элементов на этом контейнере. Каждый компонент "думает" 1)если "я" компонент, то вызываю owner'овский DrawChar; 2) если "я" контейнер, то вызываю свой DrawChar на свой же buffer, затем по окончании делаю Owner.DrawBuffer.

Таким хитрым способом отрисовываются все компоненты, например на активном окне, не перерисовывая окн[о/а] рядом или позади. Причем идёт это по иерархии наверх к рабочему столу или элементу screen, который является наследником контейнера, но в инициализации не выделял буфер, а сделал указатель на b800:0000;

Из чего состоит окно:
Window наследуется из контейнера;
имеет Header или Border: элемент рисует границы (обрамление, заголовок, кнопки)
ClientArea: то самое место где будут находится все элементы.
Полосы прокрутки: соединены с ClientArea, если захочется нарисовать элемент за пределами окна, ClientArea расширяется и полосы прокрутки становятся активными.

где хранить данные: Как в ООП: Всё хранится в собственном объекте, включая список или указатель на объекты внутри "меня".

[New man]

tae1980, предлагаю такое решение:

hierarchy<int, UIElement*> — Хранилище всего UI.

У каждого UIElement есть id, которое соответствует ключу, по которому он хранится в иерархии, плюс id родителя. Опционально — id дочерних элементов.
У наследников UIElement есть всё остальное: отрисовка, события

Сделайте генерацию иерархии классов по разметке, например,html, xml или json (последнего нет, вот Вам хороший вариант).

[tae1980]

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

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

Да это оно! Спасибо!
Попробую договориться с автором.

[_Bers]

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

Я просто ждал LV1974, когда он придёт, возмутится и напишет что надо 27-127 классов. Не помню сколько у него.
А так то тема большая, во если бы ТС схему деления приложил, тогда бы можно было предметно рассуждать. А то так не понятно, то ли графическая библиотека заимствованная: к примеру AGG либо же вновь разрабатываемая. Да и с геометрическими расчётами аналогично.
Сколько и каких классов оставить или убрать?
Я же простые решения предлагаю. А если кто хочет сложные, то он может открыть в брауезе страницу с флагами. Там много всяких настроек для графической системы: таких как рендеринг в параллельном потоке и опережающий рендеринг.

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

в том, что касается ТС - он сам не понимает, что ему нужно.
и пытается рассуждать о сабже в отрыве от конкретных технологий
(например - в отрыве от ЯП). это - путь в никуда, я думаю.


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

я поясню этот момент поподробнее.

GUI - такая предметная область,
которая естественным образом эксплуатирует ОО-парадигму.
не важно, если будет реализована на языке,
который ООП из коробки не поддерживает.
(например, GTK написана на pure c,
однако ж архитектура все равно получилась оопнутой)

один из фундаментальных принципов ООП: "разделяй и властвуй".
считается, что первым человеком в истории человечества,
кто официально провозгласил этот принцип - Гай Юлий Цезарь.
поэтому, именно он считается первым в истории оо-программистом.

теперь ближе к делу.

существует оконная система.
отвечает за работу с окном операционной системы.

существует графическая система.
отвечает за вывод графики в окошке.
поэтому, зависит от оконной системы.

существует GUI система.
отвечает за управление виджетами.
которые отрисовывает руками графической системы.

итого: уже 3 интерфейса.

GUI-system ничего не знает ни об окнах, ни о графике.
но она знает об интерфейсах этих систем.
а значит может рисовать свои виджеты их руками.

нам не важно, как рисуется графика:
там под капотом будет openGL, или DirectX,
или ещё какая нибудь высокоуровневая графическая система.

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


в данной теме уже присутствовали такие предложения, как: "нарисуй прямоугольник для начала".

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

примеры грамотной архитектуры можно подсмотреть в таких движках,
как например CEGUI.

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

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

[tae1980]

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

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

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

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

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

Прозрачность да же не планируется Это выше возможностей машины.

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

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

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

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

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

Чувствую, тут нужно пояснит железные возможности машины.
ОЗУ 1Мб, прямая адресация нижних 64кб, при этом есть ОДНО! окно проецирования страниц по 16кб. Дополнительно, в нижние 64кб можно вывести страницы экрана.
Экран 512х240, один цвет (бумага, чернила) на линию в 8 точек из 16 цветов. Текстового экрана нет. Ни каких видео карт, экран это 2 страницы памяти (32 кб) выше 64 кб.
Процессор Z80, частота 3.5Мгц, турбо 14Мгц.
Из языков доступны: Турбо паскаль 3.0, Си (разные версии), ассемблер. Конечная версия будет писаться на асме, проверка теории на Паскале (как более близко мне языке, чем Си).
Из выше сказанного, есть один очень противный вывод, привязка к размеру страницы в 16кб и большой геммор с передачей информации между страницами.

QT и OpenGL дело хорошее, но я даже Turbo Vision'ом не могу воспользоваться на прямую, так как ему нежно 670Мб, что здесь не позволительная роскошь. По этому я и испрашивал про теорию, а не примеры.

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

Всё нужное для графического интерфейса пишем с нуля.
От сюда деление задачи на две части: 1) Организации хранения и обработки информации об окнах и т.п. 2) вывод всего это добра на экран (то что ты назвал графической библиотекой).

Обычно начинают с простого: создания и очистки окна, закрытие окна и восстановления фона по ним.
Уже здесь должны быть проработаны основные принципы работы по обеим задачам.

Вы пишите всё правильно, но для того случая, когда у вас есть хоть что-то.

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

[tae1980]

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

примеры грамотной архитектуры можно подсмотреть в таких движках, как например CEGUI.

Спасибо, за наводку.

[tae1980]

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

По делу: начинаете с реализации функции рисования всех примитивов в буфер. Да да, свои собственные, с самого нуля, хорошо оптимизированные иначе будет безбожно тормозить, потянете? Если нет тогда добро пожаловать в текстовый режим. Макс размер буфера 80х25х2=4КБ памяти на весь экран.

Текстового экрана нет, но его можно с эмалировать.

Тут прошу пояснить.

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

Достаточно реализовать DrawChar(x,y,char,attribute)

Куда рисует символ в буфер ли на экран.

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

и DrawBuffer(x,y,&buf).

Это вывод знакоместа из буфера на экран?

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

Это самые низкоуровневые функции рисования, ничто больше не должно рисовать "физически". Далее 2 основных элемента - компонент и его наследник контейнер. Компонент имеет функции IsExposed:boolean {если элемент виден на экране - true else false};
Draw() отрисовывает компонент и содержит реальные вызовы DrawChar.
Дополнительно DrawComponent - обычно его надо вызывать для прорисовки, содержит if IsExposed then Draw. Идея ясна - отрисовываем только когда компонент виден на экране.

Прорисовка куда: на экран или в буфер?
Давайте определимся с термином: Что такое буфер? Это буфер экран, окна, контейнера, элемента?
Что значит "компонент виден на экране"? Он должен быть полностью на экране или частично?

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

Теперь к DrawChar: Контейнер имеет буфер рисования. Вызываются все Draw'ы элементов на этом контейнере. Каждый компонент "думает" 1)если "я" компонент, то вызываю owner'овский DrawChar; 2) если "я" контейнер, то вызываю свой DrawChar на свой же buffer, затем по окончании делаю Owner.DrawBuffer.

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

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

Таким хитрым способом отрисовываются все компоненты, например на активном окне, не перерисовывая окн[о/а] рядом или позади. Причем идёт это по иерархии наверх к рабочему столу или элементу screen, который является наследником контейнера, но в инициализации не выделял буфер, а сделал указатель на b800:0000;

Что делать с частичным перекрытием окон/элементов?

Нечто подобное предлагал выше, из особенностей:
* Графика храниться только на уровне элементов.
* Если объект хотя бы частично на экране, то он прорисовывается полностью: для элементов графически в свой буфер, логически в свой буфер и границы в буфер контейнера; для контейнеров - только логика в свой буфер, границы в буфер внешнего контейнера. Тут дополнительный расход памяти и времени проца, так как если элемент на экране только частично, в своем буфере он всё равно прорисывается полностью. Но иногда без этого нельзя будет определить физические размеры и внешний вид элемента. Иного выхода пока не вижу.
* При выводе строиться логический и графические образы экрана из элементов попавших на него. Логический используется так же для отработки действий мышки. Графический кидается на экран или сразу строиться на нем.

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

Из чего состоит окно:
Window наследуется из контейнера;
имеет Header или Border: элемент рисует границы (обрамление, заголовок, кнопки)

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

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

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

Что представляет собой ClientArea? Если это буфер, его размеры проблематично изменить, так он имеет ранее заданную ширину и высоту (по сути двухмерный массив). Проще удалить текущий и создать новый, особенно если это графический буфер.
Именно по этому планируется только логическая буферизация контейнеров, с полной перестройкой при изменении размеров любого внутреннего элемента.

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

где хранить данные: Как в ООП: Всё хранится в собственном объекте, включая список или указатель на объекты внутри "меня".

Так коечная реализация будет на асме, это проблематично. Но можно следовать "духу".