Пришло время отосрать в псто! Я — быдло, артс — угнич, а угнич — хуй.

Но про все по порядку.

Понадобилось мне нарисовать окошки для http://anon.fm/omsk/chat.swf, ибо места свободного уже нету, а блекджек и шлюх куда-то добавить надо. А так напихал в окошко кучу хуиты, а дальше пусть юзер сам выстраивает, как ему интересно. (да, это очередная попытка сделать ТУЛКИТ, на сей раз исходя только из потребностей реального мира)

Чего мне хотелось от окошек? Окошко — это в первую очередь контейнер, который... Ах да, накидать туда хуйни и забыть про нее, да не только кнопочек/надписей, а еще хотелось бы туда кидать тысячи списочных элементов сразу, да так, дабы все это в итоге не тормозило, а юзер мог елозить по всему этому и быть счастливым. Ведь каждый элемент — это тоже контейнер, со своими данными, своим представлением.

Если скроллить, да еще не тормозить — значит нужна система layout, которая будет читать правила, выстраивать элементы по ним, определять текущую область отрисовки, удолять лишнее... А может быть даже добавлять к элементам какие-то свои данные, например, контейнер с иконками, которые можно перетаскивать по экрану: хранить координаты иконок где-то надо, а если приложение просто добавило элемент — где их взять, кроме как добавить самому? Да и сами плавающие окошки тоже нуждаются в этом — текущее положение на экране, если контейнер находится не внутри списка, а внутри корневого окна и может "плавать" как обычное вендоблядское окошко. Надо же где-то координаты окна хранить? А может и не плавать, тайлинг — штука очень интересная, имеет множество применений, а фактически — просто еще один layout manager, где вместо координат окна — размеры этих самых тайлов и их конфигурация.

Так, а если мы скроллим списочек с 2000 элементов, то все начинает подтормаживать, значит надо придумать пару методов для удоления элементов, которые заехали за границу экрана, да еще фектори, для создания/восстановления объектов, которых мы еще/уже не видели. Можно делать динамическую подгрузку элементов при скроллинге. Вообще, тут можно дохуя чего сделать, к примеру, никто не мешает нарисовать еще один скролл-бар, который будет определять "наезд" элементов друг на друга, позволяя вместить на экран больше этих самых элементов — просто, быстро, молодежно, никакого отжирающего ресурсы скейлинга, но можно и его за компанию добавить.

И конечно же, хотелось бы разную декорацию окошек: ну там заголовочек попсовенький, рамочки с анимированными бликами, да еще сделать так, дабы окошки при движении искривлялись, а блики перекатывались. Или наоборот, простой полупрозрачный белый фон и одинокую кнопку "закрыть" в уголке экрана. Кстате, я начинаю понимать вендоблядей с их сотнями параметров в простых апи-функциях — я тоже наделал кучу параметров вида noresize/noborder/noclose/nomove/ontop/onback.

Раз уж затронул тему реализации, перейдем к ней.

Так как у меня отрисовка декораций окна имеет свою логику, то решил просто: делаю базовый класс окна, часть функций абстрактные, а всю отрисовку выношу в сабклассы. Получилось сложно, но еще решаемо. Так. А куда деть layout? Он тоже свою логику имеет, да еще какую! Ладно, пока побудет членом класса, а то и вообще статической функцией в классе-утилите, долго ли вызвать recalc_layout(this) при добавлении очередного элемента? Хотя стоп, у него же еще свой скроллбар есть, это надо его дергать несколько чаще, а в идеале вообще свалить все на него. Вдруг я хочу выстроить элементы каруселькой, а скроллбар тогда куда? Будет болтаться и место занимать? Ладно, решим глобально — нахуй карусельки, до кучи введем флаги noscrollH/noscrollV, а новые элементы подгру.... Бля, нам ведь еще фектори надо когда-то опрашивать, если не при скроллинге — когда? И вообще, что мы тогда добавляем в окно — уже готовые элементы, или заготовки для фектори, которая в нужный момент скроллинга, основываясь на данных лейаута, отосрет новым элементом? А что со старыми делать?

Ладно, нахуй все, я хочу просто двигающиеся окошки! Вот нажимаю я на рамочку окошка, а оно двигается! БОЛЬШЕ НИЧЕГО НЕ ХОЧУ, ТОЛЬКО РАМОЧКУ ДВИГАТЬ ОКОШКО СЧАСТЬЕ В ДОМ. Рамочка отрисовывается в своем сабклассе, оттуда я хватаю событие мышки, определяю направление движения... А дальше куда? Кому? По идее оконному менеджеру, роль которого выполняет лейаутменеджер корневого окна. Но я ведь могу быть не только в корне, поэтому нужна ссылка на родителя. Ну как в ведроиде, где при создании всего и вся нужно указать контекст, внутри которого ты что-то строишь. Ехал парент через парент, видит контекст через контекст. Ладно, похуй, окошки надо уже делать. Значит беру я выстраданную ссылку на родителя, из него ссылку на лейаут и говорю ему: "ну эта... Передвинь окошко... НУ ВОТ ЭТО... ну куда-то вооон туда...". А как ему представиться? Ну понятно, нужен какой-то ID, причем уникальный для каждого окна, причем он не должен меняться при создании/удалении. Хотя можно просто взять заголовок окна, а по нему генерить хеш через адлер32, можно надеяться, что коллизий будет мало и половина окошек не пропадет. Так, с самоидентификацией разобрались, надо бы еще понять, понимает ли лейаут вообще передвижение окошек. Вдруг это тайлоблядок? Или вообще, выстраивает элементы в зависимости от координат курсора? Хм, что-то слишком много костылей выходит... Может быть перемещение окошек целиком выкинуть в класс конкретного лейаута, а дальше пусть ебет мозг им сам?

Зачем я все это пишу? А дабы все видели, какой же я лузер. Ну еще это помогает сформулировать свои мысли более четко, пока писал — пришла пара идей, правда пока я варил макарончики, они уже улетучились, даже вспомнить не могу.

И да, я не могу нарисовать простые окошки!

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

#ghzfs

5 comments recommend bookmark subscribe