[моё] Очередная смена мировоззрения. Компоновка GUI . И Tkinter
Когда я возился с набросками UI для омнилаунчера, я исходил из заблуждения, что современный GUI - это раскид готовых кусков по координатам.
Реально, нарезаем элементы и красим их в конкретный дизайн. Размер фиксирован.
Нарезаем ячейки, в которые потом будем элементы раскидывать.
Смотрим ожидаемый размер экрана, меряем пикселями (либо процентами, переведёнными в пиксели) координаты и размеры, что куда надо будет совать.
А потом долго и нудно мудохаемся с итоговой вёрсткой. Из условно статично закреплённых ячеек, по которым условно статично раскинуты элементы.
А потом выясняется, что вёрстка не учитывает, что некоторые элементы могут иметь динамически изменяющийся размер.
И мудоханье с вёрсткой начинается снова. И снова. После каждого срабатывания flex'а, вызвавшего расползание всего экрана в нечитаемое кашу.
А потом результат запускают на экране меньше экрана версталы (сюжетный поворот: у дизайнера 4k , у пользователя, скажем, 1080p) и весь этот балаган надо начинать сначала.
А потом ещё раз, когда горящие пользователи через год-два мучений всё-таки доводят анально до сведения "стейкхолдеров" мысль, что стандартный размер экрана ноутбука - нифига не 1080p, и что ноутбуков становится всё больше и больше.
А потом ещё раз, когда выясняется, что мобильные телефоны - существуют.
И что было бы славно как-то сделать вёрстку под мобилу...
...от питоновского Tkinter у меня немножко мозг "сломался обратно".
Потому, что он использует метод pack() для раскида элементов GUI.
Метод, работающий по максимально простому принципу а-ля набор текста из символов в типографии.
Минимум абсолютных размеров.
При некоторой сноровке все элементы встанут на места сами, без пустот и перекосов.
Сами друг друга подвинут при необходимости.
В приоритете вложенность и явное указание, что придётся проматывать (если не влезет), а что нельзя проматывать.
Знай себе, группируй элементы в строкообразные фреймы, да разруливай как регулировщик на перекрёстке: "это всегда слева, это всегда справа, это в угол, это в центр верха..."
Плюс, то, чего я как полный ноль в программировании боялся больше всего. Переключение между элементами в ячейке а-ля табы в браузере.
Сделано максимально просто, понятным даже мне образом.
Осталось попрактиковаться с парсингом добытых данных.
Раскидом элементов на основе распаршеного списка.
Работой с БД либо её аналогом.
И...
...можно садиться перерисовывать макет GUI.
Потому, что старый рисовался от безысходности.
После многолетнего отравления миазмами современного веб-фронтэнда.
Может, даже и лучше, что я на пять лет выпал из профессионального IT.
После всех этих "А дАвАйТе СдЕлАеМ тЕмУ дЛя ФрОнТа На РеАкТе! Да, никто не делает для этой CRM тем на Реакте, эта CRM отвратительно работает с Реактом, но мы первыми будем!" и налепленых в Фигме плоских страхолюдин мне позарез нужно было проветрить мозги.
Вернуться к основам.
К истокам.
Когда кнопки были рельефными, а компоновка ёмкой и понятной.
"Проснуться вперёд" от этого грёбаного дурмана по мнению лучших графоманов из LinkedIn, подхваченного и распространяемого вчерашними детьми.
Конечно же, цветовая схема тестовая, прикинуть кое-какие возможности.
Но вот рельефные кнопки - остаются.
Это, конечно, не винтажные "кирпичи" из Internet Explorer девяностых. Но тоже функционально и узнаваемо.
P. S. Не забыть включить в бету 0.0.1 пасхалочку для любителей скруглённых углов у элементов дизайна.
Только сначала полистать учебник по планиметрии за пятый класс, вспомнить, какая формула правильная...
Отношение пожительных и отрицательных голосов: 1/0