CGUI

Пост был написан где-то в начале июня, но всё пошло по знакомому сценарию: забить и может быть вернуться потом. :)

Фух. Грёбаные окошки! Гореть бы им пиксельным пламенем, так ведь нееет, моя упёртость снова нашла приключений на моё же сидалище.. Хлебом её не корми - дай довести дело до конца. >_<

Вы, вероятно, думаете, что же это за набор буковок такой в заголовке, и каким местом он соприкасается с моей руганью?) Что ж, всё по порядку))

В последний ~месяц я тратил некоторую долю свободного времени на очередную никому не нужную хрень - консольный графический интерфейс - по сути оконная система, рисующая себя в виндовой консоли. Нарёк я её, недолго думая, CGUI - Console Graphical User Interface. Прошу любить и не жаловаться, Скриншот:

Скрин демки, в которую я постарался впихнуть всё, что создали мои очумелые.

Здесь можно лицезреть непонятную голубую загогулину™, окошко с полями для ввода чисел и немного содержательного текста. Загогулина - ни что иное, как Kochanek–Bartels Spline, код которого однажды был любезно предоста упёрт из вальвовской матлибы, портирован на Lua для.. впрочем, это уже другая история, а недавно обрёл свой цпп-шный облик снова)) Параметризуется сплайн теми самыми циферками в окошке, на котором я и заострю внимание.

Окна, или фреймы в терминологии CGUI (равно как и VGUI, послужившего прототипом), не так просты как другие панели.. Ох, вот незадача, я же вас ещё не ознакомил с базовой терминологией! :D Так вот, панель - что в cgui, что во vgui - атомарная единица интерфейса - прямоугольник, обладающий целой кучей свойств. Прямоугольники закрепляются один на другом, образуя классическую древовидную иерархию. Панели, естественно, образуют и, так сказать, эволюционную иерархию - существуют высокоуровневые классы панелей, которые наследуют свойства у классов уровнем пониже и добавляют к ним собственные, тем самым абстрагируя программера от низкоуровневых заморочек и => повышая потенциальную навороченность и-фейса. Большинство классов панелей, наряду с визуальной составляющей, обладают и некоторой материальностью) В том смысле, что их можно общупать мышью. К примеру: клацнуть батон, навести фокус на фрейм, сделать активным поле ввода, выделить текст, и т.п.. Собственно, всё это вам и без моих рассказов знакомо - графические интерфейсы, они все такие. :)

Так вот, вернусь-ка я к фреймам. Это хитрые зверюги! Вернее, таковыми они должны быть в идеале...

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

Во-вторых, при нажатии Tab/Shift+Tab на фрейме, фокус должен был проходить по кругу все дочерние панельки, для которых включён ввод с клавы. Раньше это делалось перебором списка "детишек", но у этого метода был жирнющий недостаток: для обеспечения рендеринга панелей в правильном порядке, их порядок в этом списке меняется при смене фокуса, из-за чего перебор табом каждый раз шёл непредсказуемым образом, а шифт-таб вообще переключал только между двумя панелями.. И снова пришлось перелопачивать код базового класса для добавления отдельного списка детей, в котором их порядок всегда оставался бы неизменным.

Ну и последняя загвоздка, которую я вчера решал вопреки инстинкту самосохранения (нервные клеточки не восстанавливаются, так-то!))) - это рисование бордюрчика фрейма правильным цветом. :) Он ведь должен меняться, в зависимости от текущего фокуса, верно? А учитывая, что на самом деле в фокусе может находиться не сам фрейм, а его дитё, дело обернулось дополнительным гемором. Благо, не таким уж огромным)

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