Я не стал превращать комментарий в статью и раскрыл мысль неполно. Джаз - это не современная музыка, хоть он и никуда не делся. Как и Бетховен. Когда я говорю об упрощении музыки, я не говорю, что сложная музыка исчезла. Я говорю, что среди создаваемой в наши дни музыки гораздо больше более простой по мелодике и ритмическому рисунку, чем советская эстрада. Я не говорю, что сов. эстрада божественна, а нынешние попса и рэп - кал. Я лишь говорю, что то было сложнее, чем это, а значит, требовало банально больше мастерства при изготовлении. Хотя сегодня суперинструментов - чем хочешь жуй. Но нет ни спроса, ни, видимо, желания.
И можете назвать трех поэтов, которые пишут в наши дни, кроме Полозковой? И которых читают?
У вас очень странные представления о таланте и фантазии, если вы называете нейросети талантливыми и обладающими фантазией...
А главное - зачем? Генерировать тонны мусора для КДПВ? Этого бомжа, например, можно было фоткнуть на любой современный мобильник, просто выйдя из дома и прогулявшись минут 5 по улице (полагаю, каждый в своем городе знает правильные места для этого). Еще Татьяныч писал, что когда тебе нужен лист дерева, не надо рисовать его в фотошопе/иллюстраторе час, не надо рыться в стоках два часа, надо выйти на улицу, подобрать подходящий под ногами, вернуться и положить его в сканер, пару минут на все, и лист настоящий. И это касается 3/5 иллюстраций, которые от ИИ нифига не выигрывают.
А такие тети в платье и болоте и нужны, чтобы показать, как фотограф умеет свет ставить. То есть, теперь они не нужны вовсе. Разве что для мемчиков. Раньше абстрактное фото - это был эксперимент, проверка, что можно из фотографии как таковой выжать еще, проверка на что способен фотограф. А теперь ценность этой фигни не больше, чем детсадовский рисунок карандашом - тоже фигня какая-то непонятная, тоже никто еще так не делал, только фотореалистично, но зачем?
Что касается произведений искусства, то лично для меня художественное качество фото/картины (соответственно, талант автора) определяется тем, захочется ли мне регулярно смотреть на это, если оно будет, скажем, висеть на соседней стене, или оно будет столь же привлекательно для глаза, как обои, на которых висит. Так вот среди ИИ-поделий не видел ни одного изображения, которое хотелось бы повесить на стенку. Среди "живых" таких немало.
С появлением фотомобильников найти приличное любительское фото стало практически нереально, тонет в мусоре. Теперь мусора станет не в разы, а на порядки больше. Но мне грустно не от того, что "раньше деревья были зеленее", а от того, что катастрофическое падение среднего уровня приведет к тому, что он и станет нормой, перестанет быть мусором. Уже перестает. Вместе с упрощением музыки, стихосложения, обесцвечиванием кино... Казалось бы - у людей в руках появились мощные инструменты, можно улучшить качество - ан нет, растет пока только количество, а стандарты качества подгоняются под то, что есть.
Забавно. Статья подписана Maxilect. То есть, все эти "я", "у меня" и "баланс работы и личной жизни" - это все про компанию. И да, я придираюсь
А по теме - электронная книга (e-ink) без подсветки прекрасно заменяет бумажную. И музыку не надо рассматривать под соусом гаджета, это просто патефон в современном карманном виде, вопрос ведь не в реализации, а в принципе: детокс идет в первую очередь от бесконтрольного потребления пустого контента и от бесконтрольного пустого бессмысленного общения, даже синева экрана, ухудшающая сон, здесь вторична. Так и велосипед с велокомпьютером можно гаджетом обозвать и призвать бегать без фитнес-браслета просто потому что.
И ни слова про настолки, а тоже отличная замена (как леденцы курильщику :-) позволяют неплохо провести время в теплом общении с хорошей компанией. Только надо подобрать подходящие, отдельно для семьи (чтобы зашло и детям), отдельно для друзей (чтобы сюжет был более-менее и по времени адекватно, кому-то надо неделями с продолжениями, кому-то, наоборот, лучше несколько партий по 15 минут). Заодно повод собрать друзей.
Из активностей хороши в упомянутом смысле командные (волейбол, пейнтбол и тому подобное): хочешь-не хочешь, а регулярно придешь, чтобы команду не подвести. Но хорошую команду найти непросто, а самому собрать еще труднее...
Менеджерам размещения -- по барабану. Они отвечают за переопределение координат по заданным правилам. А вот "кто в кого вставлен" делается из взаимоотношения родитель/дочерний среди отображаемых (лэйауты не отображаются).
А цитаты лучше подписывать, а то выглядит как "ибо сказано в писании: ..."
Абсолютного хорошего дизайна не существует. Жаль, но факт. Это же относится к цене, надежности и возможно другим характеристикам товаров и услуг. Продавец и покупатель по разные стороны баррикад. То, что хорошо для одного - плохо для другого.
Если добрый дядя-бизнесмен начнет делать удобный, дешевый, надежный и функциональный товар, он быстро заполнит рынок и надолго останется без прибыли. И сдохнет как бизнесмен. Каждый, кому нужен реально молоток, купит по одному молотку - дешевому и вечному, и передаст его по наследству. А те, кому нужно нечто молоткообразное, но стильное, модное, молодежное, такое, чтобы похвастаться было не стыдно, ну и лишние фичи не помешают, экранчик там..., купят одноразовое фуфло яркое, как цыганская шаль, сверкающее, раскрученное (чтобы всем вокруг было понятно, что владелец такой штуки точно крут) и ломающееся ровно тогда, когда пора купить новую модель и принести еще бабла продавцу.
Плюс не забываем, что дядя-бизнесмен - это в подавляющем случае не дядя, а организация, в которой много дядь и теть. И личные цели их часто расходятся с целью организации. Бизнес хочет получить прибыль. Менеджер тоже хочет получить прибыль, но чаще всего его личная прибыль зависит не от прибыли организации, а от выполнения неких KPI. И если такой менеджер влияет на подачу товара пользователю, он впихает в товар то, что увеличит его, менеджера, KPI (а значит доход) в моменте. Абстрактная прибыль организации в долгосроке ему не интересна.
Итого мы видим три противоборствующие показателя качества ну пусть дизайна (но и других характеристик, например, надежности): по одну сторону баррикады пользовательское удобство, по другую - еще одна мелкая баррикадишка с бизнесом как таковым с одной стороны и конкретным реализатором с другой, которые оба против пользователя, хотя должны изо всех сил делать вид, что за, и еще немного друг против друга.
Поэтому увы, идеального дизайна в большинстве случаев не будет. Только спецзаказ или узконишевые конски дорогие штуки типа скафандров... Конечно, есть вещи, которые очень трудно испортить, например, ложка, "но это уже совсем другая история"
Допустим (на этих строках я даже посмотрел, нет ли плашки "Перевод"). Честно говоря, я и предполагал, что автор имеет в виду возможно самое известное международное событие 43 года:
28 ноября - 1 декабря Тегеранская конференция Сталина, Рузвельта и Черчилля. Приняты Декларации о совместных действиях в войне против Германии и о послевоенном сотрудничестве трех держав, решение об открытии не позднее 1 мая 1944 второго фронта в Европе.
Откуда как бы ненавязчиво следует, что автор считает помощь Союзу в разгроме войск, которые на тот момент считались немецко-фашстскими, а сегодня я боюсь и предполагать, как это могут развернуть, была переходом на темную сторону силы... Истинные джедаи, похоже, по мнению автора должны были добивать Союз. Возможно, вместе с Германией...
Но я пока надеюсь, что ошибаюсь. И все еще хотел бы получить пояснения автора по этому поводу.
Император Палпатин вообще непонятно каким образом поднялся на вершину политической лестницы настолько быстро, когда вокруг существуют столько офигенных джедаев.
Что тут может быть непонятного? Старый, как мир, способ, который работает и поныне на всех уровнях, начиная с младшего бригадира:
1) Создать проблему или усилить существующую, причем, чтобы проблему заметили все (всем тыкать в нее носом), а истинного виновника (себя) тщательно скрывать
2) Убедительно доказать, что именно ты сможешь эту проблему решить, но тебе не хватает полномочий, желательно, исключительных, но временно и для всеобщего блага
3) Пользуясь полученными полномочиями, ликвидировать угрозу для своих полномочий и подняться еще выше, если есть куда
4) ...
5) Profit!
Надо сказать, даже если бы он был обычным дядькой, не ситхом (ситом? сифом? сисом? как sith нормально транскрибировать, th - ваще не тх) - для Республики и Империи ничего бы не изменилось. Даже с точки зрения подготовки шумно дышащего преемника - он был уже вполне готов.
А джедаи, на секундочку, не только не лезли на вершину политической лестницы, но и не подходили даже к ее подножию. Они приняли на себя совсем другие функции. Все равно, что обвинять охранника школы в том, что ее директор - козел.
как зеркало общества, которое само почти (или не почти, зависит от точки зрения) поддалось тёмной стороне в 1943 году.
Поясните, пожалуйста, этот момент для совсем недалеких и прогуливавших историю. Или хотя бы укажите точную дату, чтобы было что гуглить
В Союзе вернули погоны? Ирак объявил войну Германии, Италии и Японии? Боливия объявила войну Румынии и Венгрии? Официально распущен Коминтерн? Американский компьютер «Марк I» успешно прошёл первые испытания (как начало заката человечества и эры скайнета)?
Шариковые направляющие для полки под клавиатуру есть во многих магазинах фурнитуры и мастерских по изготовлению мебели. С их помощью делается выдвижная полка для любого деревянного/ДСП стола. Ширину полки можно сделать любую, насколько ширина стола позволяет, прочность достаточная: у меня лет через 7 (не меньше) шарики посыпались, пришлось менять направляющие. Одно но - расстояние от стола до полки фиксированное, вертикальная мышь на большинство из них не влезет.
Да все это я понял. Вы в свою очередь отказываетесь понять, что если задачу можно решить через дизайнер, то ее необязательно нужно решать через дизайнер. Ну вот есть такие, как я (и нас немало), кому дизайнер только мешает. Потому что и без него понятно, что выйдет в результате. Даже в дельфи я в конце концов ушел от использования дизайнера, хотя там он хорош, потому что он стал не ускорять, а замедлять меня.
Плюс работу с текстом я всегда предпочту работе с мышью, за что невзлюбил labview, вынужден был состряпать на нем пару относительно больших проектов, выбора не было. Но таки да, и у него есть свои поклонники.
Кстати, и в проектироавнии плис практически все серьёзные вещи пишутся на языке, а не рисуются в графике. В сети в графике только учебное баловство. И причины те же - полный контроль над деталями и отсутствие необходимости в визуальном наблюдении против не всегда корректной кодогенерации и пиксельхантинга
И я не совсем понял, что значит "управляется с бэкенда". Это нормально, вообще-то... но как дизайнер поможет собрать интерфейс из 5 элементов-контейнеров, если они элементарнейше укладываются и без него, и как он поможет наполнить базу корректными полями свойств контролов?
Но ведь на одном Delphi свет клином не сошелся, я говорю о WISIWIG-редакторах в целом. Это во-первых.
Во-вторых, представьте экран современного цифрового осциллографа, или монитора пациента, или панель бортовой системы управления малого самолета. Там море кнопочек, менюшечек, панелечек с табами, вкладками, которые находятся на фиксированных позициях разные в зависимости от активной страницы и предыдущих действий пользователя. Уровень вложенности страниц до восьми. Вы что, предлагаете это все "декомпозировать" и прорисовывать в редакторе? Да там вариантов сочетаний - как ходов в шахматах. Добавляется ListView или GridView, где и будут кнопки/табы. Их надо в большинстве случаев штук 5 на страницу - 4 стороны и центр. А модель для отображения берется в БД. Правила замены моделей при смене страницы (довольно простые) пишутся кодом, визуальный редактор тут не помощник. База наполняется отдельно, текстом и тоже довольно просто, по каждой потенциальной кнопке - ее вид, позиция (страница, например), зависимость от других кнопок, условия активности, связанный параметр и все такое. В результате умопомрачительные на первый взгляд по сложности и взаимозависимости интерфейсы делаются удивительно несложно, и смотреть в процессе разработки там не на что.
С дельфями я провел много замечательных лет, но даже их отличный редактор постепенно переставал использовать, чем сложнее был интерфейс и чем больше взаимодействий между состояниями интерфейса, тем проще это было выразить кодом. А декларативные описания интерфейса, типа QML/WPF (похожие, кстати, на результат работы редактора dfm) и вовсе настолько упрощают работу, что переключаться в визуальный вид просто нет реальной необходимости
Я хотел сказать, что WISIWIG - отдельная концепция, которая имеет свои достоинства и недостатки. Главное достоинство - ускорение "разработки" (в кавычках - потому что это касается не только кода, но и, скажем, оформления текстов) и сиюминутная наглядность. Недостаток - подкапотная работа, порой кривая и небезопасная, иногда вообще неконтролируемая (в тот же DOC-формат лезть бесполезно).
WISIWIG безусловно крайне удобен тем, у кого нет ни времени, ни желания разбираться с используемой технологией, особенно если это одноразовая работа. Например, набор текста на пару страниц с кучей формул, скажем, лабораторной работы. Большинство ради одной-двух небольших работ возьмет условный ворд с его условным мат-редактором (как вспомнишь - так вздрогнешь). Но большинство тех, кому дорого время, качество и психическое здоровье, освоят что-то типа LaTeX.
Сегодня я и сам не выберу LaTeX (нет таких задач), но когда оформлял НИР, а еще несколько толстых брошюр с расчетом на типографию, этот замечательный инструмент показал мне всю мощь не-WISIWIG-редактора. Однако да, требуется определенный опыт или справочник постоянно под рукой. То же и с SVG, о котором я уже упоминал. Простые вещи делаются компактнее и логичнее, чем в основных редакторах, inkscape делает порой странную и избыточную структуру вложенных элементов, а первую треть тэгов можно безболезненно выкидывать. Сложные картинки - не знаю, вручную не делал. Если бы надо было делать регулярно - непременно попробовал бы.
У меня нерепрезентативная выборка среди своих знакомых, но по общению в интернетах сложилось ощущение, что WISIWIG реже используется там, где человек глубже погружается в технологию и стремится к более полному контролю. Когда ты и без WISIWIG представляешь себе то, что тебе нужно, он больше ограничивает, чем помогает. Возможно это дело вкуса. Но я и большинство моих коллег и хороших знакомых видят это так, и отсутствие мощных редакторов интерфейса для конструирования GUI и массового их использования это косвенно подтверждает. Возможно, я ошибаюсь. Не хочу никого переубеждать, просто мнение, по мере сил аргументированное.
Спасибо за ликбез, я знаю, как в Delphi. Но я привел пример интерфейса, который собирается на лету при запуске приложения из настроек, в БД или JSON, где каждый элемент определяется этими настройками. Здесь WISIWIG-редакторы бесполезны совершенно, ибо проектируется концепция интерфейса, а не его вид. Потом, кастомные контролы - это далеко не только кнопки со скругленными углами и нестандартными цветами, это может быть низкоуровневый код, определяющий логику работы компонента и его прорисовку в onDraw(). Можно научить редактор с этим справляться, но стоит ли овчинка выделки? Но самое главное - WISIWIG слишком много на себя берет, это кодогенерация, которая в определенных случаях вообще запрещена к применению из-за возможных неочевидных последствий (сертифицированных для уровня B WISIWIG-редакторов я не знаю, а это куча медтехники и авиаприборов). Банальный пример: простой SVG-файл, который я сделал вручную, примерно раз в 5 больше сгенерированного inkscape, хотя рисует то же самое. Или сложные таблицы во всяких вордах и либре гораздо менее предсказуемы, чем сделанные в LaTeX. Невизуальные редакторы дают полный контроль над результатом, а работу WISIWIG еще проверять надо, и чем больше эти результаты, тем больше работы по оптимизации.
Тащишь мышью кнопку на экран, примерно в левый верхний угол. Что должна кнопка делать при изменении размера окна или при повороте экрана - растягиваться, переползать, держаться каким своим углом за какой угол окна? Да, все это можно настроить в свойствах кнопки в панельке сбоку. Но если все равно это надо делать, это можно сделать и в коде, разница будет только в том, что я не мышью тащу в редакторе, а пишу Button { ... }. И мне не нужно наглядно вот прям щаз видеть глазами результат, я его отлично представляю себе, и первый же прогон приложения его подтвердит...
Если бы я действительно сильно заблуждался, WISIWIG-редакторы интерфейсов процветали бы, а в коде интерфейс стряпали бы единицы вроде меня. Но на практике я вижу, что их применяют в основном для окошек или фреймов уровня сложности не выше калькулятора.
Пардон моа, но я не вижу в этом противоречия тому, что WISIWIG-редакторы GUI в большинстве случаев бесполезны, а большинству опытных кодеров и неудобны...
Во-первых, делают. В Qt тоже есть визуальный редактор интерфейса.
Во-вторых, это редко используется потому, что подходит только для примитивных окошек уровня калькулятора.
Хотя бы для интерфейсов адаптивных, где раскладка контролов зависит от разрешения, размера, ориентации (причем часть параметров может меняться рантайм на лету), польза этих редакторов сомнительна, зато надо заранее продумать раскладку (а не собирать мышью как лего), а тогда и редактор не особо нужен.
И не знаю, как ныне, но надысь редакторы так себе справлялись с самописными элементами. Если нужны не только стандартные кнопки/чекбоксы, то ой...
А для монстров, в которых интерфейс собирается на разного рода view (ListView, GridView и иже с ними) на основе настраиваемых моделей из БД, где может быть меню, определяющее состояние текущей страницы, на которой может быть десяток вкладок, на каждой из которых полсотни контролов либо динамически подгружаемые подстраницы, такие редакторы бесполезны абсолютно. А это, например, целая куча приборов, вроде современных цифровых осциллографов или мед. оборудования.
Если тем более в проекте работает дизайнер, который продумал и нарисовал хороший интерфейс в какой-нибудь фигме, берешь оттуда все координаты и цвета и переносишь в QML, опять же редактор GUI не нужен...
Правила это обычно какая-то функция или вы не правильно выразились и речь идет не о правилах, а о параметрах для рисования.
Насколько я знаю, нет фиксированного общепринятого или определенного в документации понятия "правило", где это функция, поэтому я не считаю, что я неправильно выразился. Я имею в виду совокупность условий, определяющих то, как параметр будет отрисовываться. Это может быть параметр, например, цвет. Это может быть функция, например, вычисление координаты правого угла из координаты левого угла и ширины. Это может быть набор функций, определяющих, где брать параметры и функции, например, сперва выяснить, кто у нас родитель и надо ли использовать координаты, прописанные в дочернем элементе или взять координаты родителя целиком, если в дочернем сказано "заполнить родителя". Поэтому я использовал расплывчатое слово "правила", если бы можно было сказать "параметр" или "функция", я бы так и сказал. Но я хотел обрисовать ситуацию очень грубо, поверхностно, не вдаваясь в детали. Логика компоновки зависит от класса отображаемых объектов, от свойств, заданных в них, от некоторых функций (методов), объявленных в них, от позиции их в иерархии родительствования.
Это же разные функции, можно предположить что они формируют разные независимые связи между объектами
Нас в первую очередь интересует, что они делают добавляемый объект дочерним для добавляющего. А так как лэйауты и виджеты имеют разных вторых корневых предков, функции тоже разные, иначе пришлось бы при вызове универсального гипотетического setChild проверять класс чайлда и выполнять соответствующие действия, определяющие детали реализации. А в действующем случае этот if или case возложен на программиста. Более того, таким образом можно сделать проверяемый на этапе компиляции запрет класть, скажем, кнопку прямо на форму мимо лэйаута.
И кстати, а что, это -
pvbxLayout->addLayout(phbxLayout);
компилируется? Когда я давненько уже работал с виджетами, так было нельзя...
Обход дерева кстати очень прост, <...> То есть просто идем по дереву сверху вниз.
Так и я же о чем. Если есть достаточно четкое представление об этом, то мне странно, что могло быть непонимание по поводу параллельных иерархий.
Вернусь сюда еще. Лэйаут себя не рисует, и никого на себе лежащего не рисует. В коде объявляются разного рода визуальные элементы. В коде этих элементов нет команд для рисования, для вывода в видеопамять через прастиосспади прерывание INT 10h. На основании иерархии, выстроенной на отношениях parent/child, рисуется граф сцены, который будет отрисовываться рантайм-частью библиотеки Qt, без которой ваше творение не запустится
Попробую обрисовать очень грубо, общий принцип.
Объявили мы в коде две кнопки. Через что-то типа setWidget() добавили на форму. Тем самым (внутри этой setWidget) сделали форму их родителем, при этом кнопки добавились в список childs этой формы. (ну, допустим, не непосредственно на форму, а через посредничество лэйаута, но это неважно). Добавили еще один лэйаут, он стал чайлд для формы. Добавили на новый лэйаут две кнопки, они стали чайлд для него. Такая иерархия, основанная только на свойствах parent/child из QObject
Запустили код. Сцена будет отрисовывать этот граф: берем форму, рисуем заданным размером в заданном месте экрана, помним координаты. Берем список чайлдс этой формы (хорошо, корневого лэйаута в нашем случае), там три элемента. Поехали по порядку. Сперва кнопка, ищем правила ее отрисовки. В зависимости от лэйаута это могут быть координаты, берем их из свойств кнопки и рисуем относительно запомненных координат текущего родителя. Либо раскладкой управляет лэйаут, тогда свойства-координаты дочернего элемента игнорируем, а используем правила вычисления координат для дочерних элементов, взятые от текущего родителя (типа прижать влево, поэтому для первого дочернего х=0). Нарисовали саму кнопку - смотрим ее список дочерних элементов. Пусто - хорошо. Не пусто - смотрим, есть ли визуальные. Нарисовали одну кнопку, берем следующую. Координаты перекрываются почему-то? Если z-ордер одинаковый, тупо рисуем поверх. Берем следующий элемент из списка - это еще один лэйаут. Для начала расчитываем его координаты исходя из его родителя (лэйаута и его правил) и заданных уточнений в самом лэйауте, как для предыдущих кнопок. По типу элемента понимаем, что рисовать его мы не будем, но имеем новый комплект координат для привязки и новый список дочерних элементов. Рекурсивно проходим по нему, рисуя все, что по типу должно быть отрисовано и имеет признак visible==true.
Ну и примерно таким образом обрабатываются движения мыши, фокус элементов и все такое. Обход дерева родителей/детей и выяснение, что делать с текущим элементом в зависимости от его типа и установленных свойств. То, что какой-то элемент не QWidget, а QLayout, не добавляет параллельных иерархий, а уточняет в конкретный момент обхода дерева, что делать с элементом.
ну, не совсем. Результат работы Qt компилируемый. Но с точки зрения создания кода это неважно.
А что касается документации, пардон, лучшей документации, чем встроенная в QtCreator, я еще не встречал. Исчерпывающая, с прекрасными перекрестными ссылками, с релевантными ссылками на подобные сущности, с отдельными статьями по правильности использования тех же раскладок, с примерами применения, с подборкой мини-проектов...
Не надо ничего прикручивать, все уже украдено до нас. Пишем, например,
Button { }
И внутри скобок описываем, что хотим от кнопки - где, какая, признаки. Например, color: "red". Чтобы добавить императивщины, пишем onClicked: { } а в скобках js-код, который выполнится без лишних усилий с вашей стороны, причем, там можно использовать упомянутый color в качестве переменной, а также разные самостоятельно объявленные property.
Но идеологически вернее вместо кривых скобок сослаться на функцию, объявленную в плюсовом коде. Хотя можно столько логики впихнуть в qml-файл, что чертям тошно станет. И свои функции объявить в том числе.
Кстати, в qml можно объявлять сигналы и привязывать их к слотам в плюсах, а можно qml-функции привязать к плюсовым сигналам. В общем, есть где разгуляться.
И кстати, qml-элементы из коробки поддерживали тачскрин, включая мультитач. Не знаю, способны ли на это сегодня виджеты, но в свое время это была вообще киллер-фича для эмбеда
Я не стал превращать комментарий в статью и раскрыл мысль неполно. Джаз - это не современная музыка, хоть он и никуда не делся. Как и Бетховен. Когда я говорю об упрощении музыки, я не говорю, что сложная музыка исчезла. Я говорю, что среди создаваемой в наши дни музыки гораздо больше более простой по мелодике и ритмическому рисунку, чем советская эстрада. Я не говорю, что сов. эстрада божественна, а нынешние попса и рэп - кал. Я лишь говорю, что то было сложнее, чем это, а значит, требовало банально больше мастерства при изготовлении. Хотя сегодня суперинструментов - чем хочешь жуй. Но нет ни спроса, ни, видимо, желания.
И можете назвать трех поэтов, которые пишут в наши дни, кроме Полозковой? И которых читают?
У вас очень странные представления о таланте и фантазии, если вы называете нейросети талантливыми и обладающими фантазией...
А главное - зачем? Генерировать тонны мусора для КДПВ? Этого бомжа, например, можно было фоткнуть на любой современный мобильник, просто выйдя из дома и прогулявшись минут 5 по улице (полагаю, каждый в своем городе знает правильные места для этого). Еще Татьяныч писал, что когда тебе нужен лист дерева, не надо рисовать его в фотошопе/иллюстраторе час, не надо рыться в стоках два часа, надо выйти на улицу, подобрать подходящий под ногами, вернуться и положить его в сканер, пару минут на все, и лист настоящий. И это касается 3/5 иллюстраций, которые от ИИ нифига не выигрывают.
А такие тети в платье и болоте и нужны, чтобы показать, как фотограф умеет свет ставить. То есть, теперь они не нужны вовсе. Разве что для мемчиков. Раньше абстрактное фото - это был эксперимент, проверка, что можно из фотографии как таковой выжать еще, проверка на что способен фотограф. А теперь ценность этой фигни не больше, чем детсадовский рисунок карандашом - тоже фигня какая-то непонятная, тоже никто еще так не делал, только фотореалистично, но зачем?
Что касается произведений искусства, то лично для меня художественное качество фото/картины (соответственно, талант автора) определяется тем, захочется ли мне регулярно смотреть на это, если оно будет, скажем, висеть на соседней стене, или оно будет столь же привлекательно для глаза, как обои, на которых висит. Так вот среди ИИ-поделий не видел ни одного изображения, которое хотелось бы повесить на стенку. Среди "живых" таких немало.
С появлением фотомобильников найти приличное любительское фото стало практически нереально, тонет в мусоре. Теперь мусора станет не в разы, а на порядки больше. Но мне грустно не от того, что "раньше деревья были зеленее", а от того, что катастрофическое падение среднего уровня приведет к тому, что он и станет нормой, перестанет быть мусором. Уже перестает. Вместе с упрощением музыки, стихосложения, обесцвечиванием кино... Казалось бы - у людей в руках появились мощные инструменты, можно улучшить качество - ан нет, растет пока только количество, а стандарты качества подгоняются под то, что есть.
pivot
сущ. штырь, болт, недлинный стержень (кончик оси вращения чего-л.)
гл. сажать на болт, вращать, раскручивать
Стало быть, насадить продукт на болт и вертеть на нем, простите уж...
Забавно. Статья подписана Maxilect. То есть, все эти "я", "у меня" и "баланс работы и личной жизни" - это все про компанию. И да, я придираюсь
А по теме - электронная книга (e-ink) без подсветки прекрасно заменяет бумажную. И музыку не надо рассматривать под соусом гаджета, это просто патефон в современном карманном виде, вопрос ведь не в реализации, а в принципе: детокс идет в первую очередь от бесконтрольного потребления пустого контента и от бесконтрольного пустого бессмысленного общения, даже синева экрана, ухудшающая сон, здесь вторична. Так и велосипед с велокомпьютером можно гаджетом обозвать и призвать бегать без фитнес-браслета просто потому что.
И ни слова про настолки, а тоже отличная замена (как леденцы курильщику :-) позволяют неплохо провести время в теплом общении с хорошей компанией. Только надо подобрать подходящие, отдельно для семьи (чтобы зашло и детям), отдельно для друзей (чтобы сюжет был более-менее и по времени адекватно, кому-то надо неделями с продолжениями, кому-то, наоборот, лучше несколько партий по 15 минут). Заодно повод собрать друзей.
Из активностей хороши в упомянутом смысле командные (волейбол, пейнтбол и тому подобное): хочешь-не хочешь, а регулярно придешь, чтобы команду не подвести. Но хорошую команду найти непросто, а самому собрать еще труднее...
Менеджерам размещения -- по барабану. Они отвечают за переопределение координат по заданным правилам. А вот "кто в кого вставлен" делается из взаимоотношения родитель/дочерний среди отображаемых (лэйауты не отображаются).
А цитаты лучше подписывать, а то выглядит как "ибо сказано в писании: ..."
Абсолютного хорошего дизайна не существует. Жаль, но факт. Это же относится к цене, надежности и возможно другим характеристикам товаров и услуг. Продавец и покупатель по разные стороны баррикад. То, что хорошо для одного - плохо для другого.
Если добрый дядя-бизнесмен начнет делать удобный, дешевый, надежный и функциональный товар, он быстро заполнит рынок и надолго останется без прибыли. И сдохнет как бизнесмен. Каждый, кому нужен реально молоток, купит по одному молотку - дешевому и вечному, и передаст его по наследству. А те, кому нужно нечто молоткообразное, но стильное, модное, молодежное, такое, чтобы похвастаться было не стыдно, ну и лишние фичи не помешают, экранчик там..., купят одноразовое фуфло яркое, как цыганская шаль, сверкающее, раскрученное (чтобы всем вокруг было понятно, что владелец такой штуки точно крут) и ломающееся ровно тогда, когда пора купить новую модель и принести еще бабла продавцу.
Плюс не забываем, что дядя-бизнесмен - это в подавляющем случае не дядя, а организация, в которой много дядь и теть. И личные цели их часто расходятся с целью организации. Бизнес хочет получить прибыль. Менеджер тоже хочет получить прибыль, но чаще всего его личная прибыль зависит не от прибыли организации, а от выполнения неких KPI. И если такой менеджер влияет на подачу товара пользователю, он впихает в товар то, что увеличит его, менеджера, KPI (а значит доход) в моменте. Абстрактная прибыль организации в долгосроке ему не интересна.
Итого мы видим три противоборствующие показателя качества ну пусть дизайна (но и других характеристик, например, надежности): по одну сторону баррикады пользовательское удобство, по другую - еще одна мелкая баррикадишка с бизнесом как таковым с одной стороны и конкретным реализатором с другой, которые оба против пользователя, хотя должны изо всех сил делать вид, что за, и еще немного друг против друга.
Поэтому увы, идеального дизайна в большинстве случаев не будет. Только спецзаказ или узконишевые конски дорогие штуки типа скафандров... Конечно, есть вещи, которые очень трудно испортить, например, ложка, "но это уже совсем другая история"
Допустим (на этих строках я даже посмотрел, нет ли плашки "Перевод"). Честно говоря, я и предполагал, что автор имеет в виду возможно самое известное международное событие 43 года:
Откуда как бы ненавязчиво следует, что автор считает помощь Союзу в разгроме войск, которые на тот момент считались немецко-фашстскими, а сегодня я боюсь и предполагать, как это могут развернуть, была переходом на темную сторону силы... Истинные джедаи, похоже, по мнению автора должны были добивать Союз. Возможно, вместе с Германией...
Но я пока надеюсь, что ошибаюсь. И все еще хотел бы получить пояснения автора по этому поводу.
Что тут может быть непонятного? Старый, как мир, способ, который работает и поныне на всех уровнях, начиная с младшего бригадира:
1) Создать проблему или усилить существующую, причем, чтобы проблему заметили все (всем тыкать в нее носом), а истинного виновника (себя) тщательно скрывать
2) Убедительно доказать, что именно ты сможешь эту проблему решить, но тебе не хватает полномочий, желательно, исключительных, но временно и для всеобщего блага
3) Пользуясь полученными полномочиями, ликвидировать угрозу для своих полномочий и подняться еще выше, если есть куда
4) ...
5) Profit!
Надо сказать, даже если бы он был обычным дядькой, не ситхом (ситом? сифом? сисом? как sith нормально транскрибировать, th - ваще не тх) - для Республики и Империи ничего бы не изменилось. Даже с точки зрения подготовки шумно дышащего преемника - он был уже вполне готов.
А джедаи, на секундочку, не только не лезли на вершину политической лестницы, но и не подходили даже к ее подножию. Они приняли на себя совсем другие функции. Все равно, что обвинять охранника школы в том, что ее директор - козел.
Поясните, пожалуйста, этот момент для совсем недалеких и прогуливавших историю. Или хотя бы укажите точную дату, чтобы было что гуглить
В Союзе вернули погоны? Ирак объявил войну Германии, Италии и Японии? Боливия объявила войну Румынии и Венгрии? Официально распущен Коминтерн? Американский компьютер «Марк I» успешно прошёл первые испытания (как начало заката человечества и эры скайнета)?
Шариковые направляющие для полки под клавиатуру есть во многих магазинах фурнитуры и мастерских по изготовлению мебели. С их помощью делается выдвижная полка для любого деревянного/ДСП стола. Ширину полки можно сделать любую, насколько ширина стола позволяет, прочность достаточная: у меня лет через 7 (не меньше) шарики посыпались, пришлось менять направляющие. Одно но - расстояние от стола до полки фиксированное, вертикальная мышь на большинство из них не влезет.
Да все это я понял. Вы в свою очередь отказываетесь понять, что если задачу можно решить через дизайнер, то ее необязательно нужно решать через дизайнер. Ну вот есть такие, как я (и нас немало), кому дизайнер только мешает. Потому что и без него понятно, что выйдет в результате. Даже в дельфи я в конце концов ушел от использования дизайнера, хотя там он хорош, потому что он стал не ускорять, а замедлять меня.
Плюс работу с текстом я всегда предпочту работе с мышью, за что невзлюбил labview, вынужден был состряпать на нем пару относительно больших проектов, выбора не было. Но таки да, и у него есть свои поклонники.
Кстати, и в проектироавнии плис практически все серьёзные вещи пишутся на языке, а не рисуются в графике. В сети в графике только учебное баловство. И причины те же - полный контроль над деталями и отсутствие необходимости в визуальном наблюдении против не всегда корректной кодогенерации и пиксельхантинга
И я не совсем понял, что значит "управляется с бэкенда". Это нормально, вообще-то... но как дизайнер поможет собрать интерфейс из 5 элементов-контейнеров, если они элементарнейше укладываются и без него, и как он поможет наполнить базу корректными полями свойств контролов?
Но ведь на одном Delphi свет клином не сошелся, я говорю о WISIWIG-редакторах в целом. Это во-первых.
Во-вторых, представьте экран современного цифрового осциллографа, или монитора пациента, или панель бортовой системы управления малого самолета. Там море кнопочек, менюшечек, панелечек с табами, вкладками, которые находятся на фиксированных позициях разные в зависимости от активной страницы и предыдущих действий пользователя. Уровень вложенности страниц до восьми. Вы что, предлагаете это все "декомпозировать" и прорисовывать в редакторе? Да там вариантов сочетаний - как ходов в шахматах. Добавляется ListView или GridView, где и будут кнопки/табы. Их надо в большинстве случаев штук 5 на страницу - 4 стороны и центр. А модель для отображения берется в БД. Правила замены моделей при смене страницы (довольно простые) пишутся кодом, визуальный редактор тут не помощник. База наполняется отдельно, текстом и тоже довольно просто, по каждой потенциальной кнопке - ее вид, позиция (страница, например), зависимость от других кнопок, условия активности, связанный параметр и все такое. В результате умопомрачительные на первый взгляд по сложности и взаимозависимости интерфейсы делаются удивительно несложно, и смотреть в процессе разработки там не на что.
С дельфями я провел много замечательных лет, но даже их отличный редактор постепенно переставал использовать, чем сложнее был интерфейс и чем больше взаимодействий между состояниями интерфейса, тем проще это было выразить кодом. А декларативные описания интерфейса, типа QML/WPF (похожие, кстати, на результат работы редактора dfm) и вовсе настолько упрощают работу, что переключаться в визуальный вид просто нет реальной необходимости
Да бог с ним, с минусом, это неважно.
Я хотел сказать, что WISIWIG - отдельная концепция, которая имеет свои достоинства и недостатки. Главное достоинство - ускорение "разработки" (в кавычках - потому что это касается не только кода, но и, скажем, оформления текстов) и сиюминутная наглядность. Недостаток - подкапотная работа, порой кривая и небезопасная, иногда вообще неконтролируемая (в тот же DOC-формат лезть бесполезно).
WISIWIG безусловно крайне удобен тем, у кого нет ни времени, ни желания разбираться с используемой технологией, особенно если это одноразовая работа. Например, набор текста на пару страниц с кучей формул, скажем, лабораторной работы. Большинство ради одной-двух небольших работ возьмет условный ворд с его условным мат-редактором (как вспомнишь - так вздрогнешь). Но большинство тех, кому дорого время, качество и психическое здоровье, освоят что-то типа LaTeX.
Сегодня я и сам не выберу LaTeX (нет таких задач), но когда оформлял НИР, а еще несколько толстых брошюр с расчетом на типографию, этот замечательный инструмент показал мне всю мощь не-WISIWIG-редактора. Однако да, требуется определенный опыт или справочник постоянно под рукой. То же и с SVG, о котором я уже упоминал. Простые вещи делаются компактнее и логичнее, чем в основных редакторах, inkscape делает порой странную и избыточную структуру вложенных элементов, а первую треть тэгов можно безболезненно выкидывать. Сложные картинки - не знаю, вручную не делал. Если бы надо было делать регулярно - непременно попробовал бы.
У меня нерепрезентативная выборка среди своих знакомых, но по общению в интернетах сложилось ощущение, что WISIWIG реже используется там, где человек глубже погружается в технологию и стремится к более полному контролю. Когда ты и без WISIWIG представляешь себе то, что тебе нужно, он больше ограничивает, чем помогает. Возможно это дело вкуса. Но я и большинство моих коллег и хороших знакомых видят это так, и отсутствие мощных редакторов интерфейса для конструирования GUI и массового их использования это косвенно подтверждает. Возможно, я ошибаюсь. Не хочу никого переубеждать, просто мнение, по мере сил аргументированное.
Спасибо за ликбез, я знаю, как в Delphi. Но я привел пример интерфейса, который собирается на лету при запуске приложения из настроек, в БД или JSON, где каждый элемент определяется этими настройками. Здесь WISIWIG-редакторы бесполезны совершенно, ибо проектируется концепция интерфейса, а не его вид. Потом, кастомные контролы - это далеко не только кнопки со скругленными углами и нестандартными цветами, это может быть низкоуровневый код, определяющий логику работы компонента и его прорисовку в onDraw(). Можно научить редактор с этим справляться, но стоит ли овчинка выделки? Но самое главное - WISIWIG слишком много на себя берет, это кодогенерация, которая в определенных случаях вообще запрещена к применению из-за возможных неочевидных последствий (сертифицированных для уровня B WISIWIG-редакторов я не знаю, а это куча медтехники и авиаприборов). Банальный пример: простой SVG-файл, который я сделал вручную, примерно раз в 5 больше сгенерированного inkscape, хотя рисует то же самое. Или сложные таблицы во всяких вордах и либре гораздо менее предсказуемы, чем сделанные в LaTeX. Невизуальные редакторы дают полный контроль над результатом, а работу WISIWIG еще проверять надо, и чем больше эти результаты, тем больше работы по оптимизации.
Тащишь мышью кнопку на экран, примерно в левый верхний угол. Что должна кнопка делать при изменении размера окна или при повороте экрана - растягиваться, переползать, держаться каким своим углом за какой угол окна? Да, все это можно настроить в свойствах кнопки в панельке сбоку. Но если все равно это надо делать, это можно сделать и в коде, разница будет только в том, что я не мышью тащу в редакторе, а пишу Button { ... }. И мне не нужно наглядно вот прям щаз видеть глазами результат, я его отлично представляю себе, и первый же прогон приложения его подтвердит...
Если бы я действительно сильно заблуждался, WISIWIG-редакторы интерфейсов процветали бы, а в коде интерфейс стряпали бы единицы вроде меня. Но на практике я вижу, что их применяют в основном для окошек или фреймов уровня сложности не выше калькулятора.
Пардон моа, но я не вижу в этом противоречия тому, что WISIWIG-редакторы GUI в большинстве случаев бесполезны, а большинству опытных кодеров и неудобны...
Во-первых, делают. В Qt тоже есть визуальный редактор интерфейса.
Во-вторых, это редко используется потому, что подходит только для примитивных окошек уровня калькулятора.
Хотя бы для интерфейсов адаптивных, где раскладка контролов зависит от разрешения, размера, ориентации (причем часть параметров может меняться рантайм на лету), польза этих редакторов сомнительна, зато надо заранее продумать раскладку (а не собирать мышью как лего), а тогда и редактор не особо нужен.
И не знаю, как ныне, но надысь редакторы так себе справлялись с самописными элементами. Если нужны не только стандартные кнопки/чекбоксы, то ой...
А для монстров, в которых интерфейс собирается на разного рода view (ListView, GridView и иже с ними) на основе настраиваемых моделей из БД, где может быть меню, определяющее состояние текущей страницы, на которой может быть десяток вкладок, на каждой из которых полсотни контролов либо динамически подгружаемые подстраницы, такие редакторы бесполезны абсолютно. А это, например, целая куча приборов, вроде современных цифровых осциллографов или мед. оборудования.
Если тем более в проекте работает дизайнер, который продумал и нарисовал хороший интерфейс в какой-нибудь фигме, берешь оттуда все координаты и цвета и переносишь в QML, опять же редактор GUI не нужен...
Насколько я знаю, нет фиксированного общепринятого или определенного в документации понятия "правило", где это функция, поэтому я не считаю, что я неправильно выразился. Я имею в виду совокупность условий, определяющих то, как параметр будет отрисовываться. Это может быть параметр, например, цвет. Это может быть функция, например, вычисление координаты правого угла из координаты левого угла и ширины. Это может быть набор функций, определяющих, где брать параметры и функции, например, сперва выяснить, кто у нас родитель и надо ли использовать координаты, прописанные в дочернем элементе или взять координаты родителя целиком, если в дочернем сказано "заполнить родителя". Поэтому я использовал расплывчатое слово "правила", если бы можно было сказать "параметр" или "функция", я бы так и сказал. Но я хотел обрисовать ситуацию очень грубо, поверхностно, не вдаваясь в детали. Логика компоновки зависит от класса отображаемых объектов, от свойств, заданных в них, от некоторых функций (методов), объявленных в них, от позиции их в иерархии родительствования.
Нас в первую очередь интересует, что они делают добавляемый объект дочерним для добавляющего. А так как лэйауты и виджеты имеют разных вторых корневых предков, функции тоже разные, иначе пришлось бы при вызове универсального гипотетического setChild проверять класс чайлда и выполнять соответствующие действия, определяющие детали реализации. А в действующем случае этот if или case возложен на программиста. Более того, таким образом можно сделать проверяемый на этапе компиляции запрет класть, скажем, кнопку прямо на форму мимо лэйаута.
И кстати, а что, это -
компилируется? Когда я давненько уже работал с виджетами, так было нельзя...
Так и я же о чем. Если есть достаточно четкое представление об этом, то мне странно, что могло быть непонимание по поводу параллельных иерархий.
Вернусь сюда еще. Лэйаут себя не рисует, и никого на себе лежащего не рисует. В коде объявляются разного рода визуальные элементы. В коде этих элементов нет команд для рисования, для вывода в видеопамять через прастиосспади прерывание INT 10h. На основании иерархии, выстроенной на отношениях parent/child, рисуется граф сцены, который будет отрисовываться рантайм-частью библиотеки Qt, без которой ваше творение не запустится
Попробую обрисовать очень грубо, общий принцип.
Объявили мы в коде две кнопки. Через что-то типа setWidget() добавили на форму. Тем самым (внутри этой setWidget) сделали форму их родителем, при этом кнопки добавились в список childs этой формы. (ну, допустим, не непосредственно на форму, а через посредничество лэйаута, но это неважно). Добавили еще один лэйаут, он стал чайлд для формы. Добавили на новый лэйаут две кнопки, они стали чайлд для него. Такая иерархия, основанная только на свойствах parent/child из QObject
Запустили код. Сцена будет отрисовывать этот граф: берем форму, рисуем заданным размером в заданном месте экрана, помним координаты. Берем список чайлдс этой формы (хорошо, корневого лэйаута в нашем случае), там три элемента. Поехали по порядку. Сперва кнопка, ищем правила ее отрисовки. В зависимости от лэйаута это могут быть координаты, берем их из свойств кнопки и рисуем относительно запомненных координат текущего родителя. Либо раскладкой управляет лэйаут, тогда свойства-координаты дочернего элемента игнорируем, а используем правила вычисления координат для дочерних элементов, взятые от текущего родителя (типа прижать влево, поэтому для первого дочернего х=0). Нарисовали саму кнопку - смотрим ее список дочерних элементов. Пусто - хорошо. Не пусто - смотрим, есть ли визуальные. Нарисовали одну кнопку, берем следующую. Координаты перекрываются почему-то? Если z-ордер одинаковый, тупо рисуем поверх. Берем следующий элемент из списка - это еще один лэйаут. Для начала расчитываем его координаты исходя из его родителя (лэйаута и его правил) и заданных уточнений в самом лэйауте, как для предыдущих кнопок. По типу элемента понимаем, что рисовать его мы не будем, но имеем новый комплект координат для привязки и новый список дочерних элементов. Рекурсивно проходим по нему, рисуя все, что по типу должно быть отрисовано и имеет признак visible==true.
Ну и примерно таким образом обрабатываются движения мыши, фокус элементов и все такое. Обход дерева родителей/детей и выяснение, что делать с текущим элементом в зависимости от его типа и установленных свойств. То, что какой-то элемент не QWidget, а QLayout, не добавляет параллельных иерархий, а уточняет в конкретный момент обхода дерева, что делать с элементом.
ну, не совсем. Результат работы Qt компилируемый. Но с точки зрения создания кода это неважно.
А что касается документации, пардон, лучшей документации, чем встроенная в QtCreator, я еще не встречал. Исчерпывающая, с прекрасными перекрестными ссылками, с релевантными ссылками на подобные сущности, с отдельными статьями по правильности использования тех же раскладок, с примерами применения, с подборкой мини-проектов...
Не надо ничего прикручивать, все уже украдено до нас. Пишем, например,
И внутри скобок описываем, что хотим от кнопки - где, какая, признаки. Например, color: "red". Чтобы добавить императивщины, пишем onClicked: { } а в скобках js-код, который выполнится без лишних усилий с вашей стороны, причем, там можно использовать упомянутый color в качестве переменной, а также разные самостоятельно объявленные property.
Но идеологически вернее вместо кривых скобок сослаться на функцию, объявленную в плюсовом коде. Хотя можно столько логики впихнуть в qml-файл, что чертям тошно станет. И свои функции объявить в том числе.
Кстати, в qml можно объявлять сигналы и привязывать их к слотам в плюсах, а можно qml-функции привязать к плюсовым сигналам. В общем, есть где разгуляться.
И кстати, qml-элементы из коробки поддерживали тачскрин, включая мультитач. Не знаю, способны ли на это сегодня виджеты, но в свое время это была вообще киллер-фича для эмбеда