Добавлен , опубликован
Чем больше я наполняю cssGUI, чем дальше я лезу в дебри GUI Unity, тем больше я осознаю, насколько он тупо устроен.
И вдруг внезапным просветлением понимаю, что html и css - дают людям райский дизайн
Абсолютная неконтролируемость поведения в GUI не дает возможности его стандартизировать в полной мере.
Он конечно крут, имеет сто тысяч фишек. Но.
Эти фишки - бред. Как и сама парадигма GUI.
Вы только вникните в это - когда Unity рисует интерфейс через Layout он минимум дважды пробегает по одной и той же функции. Он выполняет ее, но функция то - линейна. А что это значит? Это значит что если нам понадобилось например определить фокус элемента "не там", или на втором прогоне количество элементов не совпадает - ошибки. Вот такая бредятина.
А часть команд и вовсе не работают как описано в документации. Например выставление минимального размера снимает с элемента растягивание в некоторых случаях. Тупо? Да.
А растягивание тоже самое - очень странно себя ведет. Самое плохое, что в некоторых случаях оно просто не работает.
Перехватывать нажатия - кошмар. Реализовать нормальный MouseMove - кошмар. Сделать процентный размер? Кошмар.
Кстати, перехват нажатия. Какой элемент "схавает его первым"? Правильно, который появился раньше. А какой элемент визуально ожидают? Который перед вами. А это не одно и тоже, ведь верхние элементы рисуются последними. А команды перехватывают те, что рисуются первыми.
И да - слои - не работают. Такие дела.
И чувствуется мне - решение в переписывании разметки, целиком под стать реальному хтмл и ксс. Но есть ряд ситуаций, на которые я увы повлиять не могу.
Просто мысли вслух за то, в какой жопе находится все это дело.
`
ОЖИДАНИЕ РЕКЛАМЫ...

Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
29
И вдруг внезапным просветлением понимаю, что html и css - дают людям райский дизайн
Оч смешно, ты видимо ни разу не использовал их на чем-то побольше бутстрапной визитки.
29
Doc, на самом деле html + css реально штука очень мощная и удобная
27
Doc, завали
RSQR, гуй то будет, никуда не денется. Но подход в юнити когда придумывали гуй выбрали откровенно дерьмовый и не продуманный. О чем и речь.
Да и подход хтмл/ксс я имею ввиду даже не саму эту парадигму аля "теги", а именно содержимое. А в ксс очень хорошо продуманы свойства. Не так как в юнити, где одних команд для ширины штук 5-10, и все могут дать похожий эффект. Команд для изменения цвета не меньше 20.
29
Вы ребята видимо никогда не слышали про реально удобные вещи вроде MigLayout/GridBagLayout, кушаете кокашки и улыбаетесь.
29
Doc, ты видимо просто не умеешь оным пользоваться :3
24
Doc, на фоне существование в этом мире node.js, а также людей, доказывавших мне, что лучше чем JS интегрируемого скриптового языка нет и быть не может, привязанность к html и css выглядит вполне безобидно и чуть ли не вызывает понимание.
P.S. интегрируемого не абы куда, а в сфере геймдева.
27
Doc, вообще то гуи юнити устроен как раз на Layout слышу звон не знаю где он
Речь шла об отсутствии конкретики в гуи, четко выверенных команд, отображения объекта независимо от его позиции линейно и обработке действий. Я уверен, что ты понятия не имеешь о "прогонах" в юнити, которые как раз происходят из-за Layout, чем это плохо, но тем не менее сидишь и выпендриваешься за то какой Layout офигительный подход.

Вот простейший пример кода с лайаутом, который не будет работать:
var isFocusContext = rect.Contains(Event.current.mousePosition);
if (isFocusContext)
{
    if (gui.button(new GUIContent(ICONS.popup), "control-button"))
    {
                         
    }
}
Что мы сделали? Просто узнали входит ли мышь в ректангл и по условию отобразили элемент. Почему так? Потому что Layout делает дополнительный прогон, в котором условие выполняется как false, а затем происходит еще один прогон Repaint'ом, на котором условие выполняется как true. Несовпадение количества отображаемых элементов приводит к ошибке. В силу того что код прогонов выполняет одни и те же функции я не могу создать переменную фокуса после очередного перерасчета ректангла, чтобы такой ошибки не было, ибо переменная нужна мне раньше.
2 комментария удалено
24
Extravert, похожие имена у Layout в юнити и MigLayout, GridBagLayout в джаве вовсе не значат, что они устроены одинаковым образом или хоть как-то между собой связаны кроме факта, что все они отвечают за размещение и обработку элементов интерфейса (отсюда и слово layout в названиях). То, что родной класс Layout в юнити говно, это неоспоримо. Doc имел в виду, что есть куда более удобные подходы к формированию интерфейса, чем html+css и привел пару примеров из своей сферы деятельности, а ты зацепился за Layout из юнити, будто он является эталоном и стандартом, согласно которому пишутся все остальные layout-менеджеры, если только в их названии есть слово layout.
P.S. меня всегда умиляло именование классов в юнити - они бы его еще TheLayout назвали, чтобы в принципе не возникало вопросов можно ли реализовать интерфейс другим способом.
29
prog, проблема в том, что док тут начинает опять все поливать сам знаешь чем, при этом не понимает, что другого выбора в юнити нету
Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.