Comments 302
Не все окна обязаны быть скучными скруглёнными прямоугольниками с боковой панелью, шестерёнкой настроек и спрятанным под ними веб-стеком. Когда-то приложениям Windows дозволялось быть странными. Проигрыватели мультимедиа выглядели как приборы. По рабочему столу гуляли животные. Вспомогательные панели походили на пульты управления, игрушки, радиоприёмники или маленькие инопланетные интерфейсы. Окно не должно было обязательно иметь прямоугольную форму только потому, что таким было окно операционной системы.
И хорошо, что теперь не так, ИМХО.
Как раз очень плохо, что всё ещё так. Не хватает унификации в вебе. Все эти тошнотные плоские кнопки, менню-неменю и прочий треш, потихоньку лезущий через electron в обычные приложения, угнетает мой больной ум.
Это обычно подается как "минималистический интерфейс", на деле же переводится как "разработчик не умеет в UI-удобство".
И это даже нормально - не все умеют.
Иногда это необходимость: взять тот же стандартный select: с одной стороны его вид слабо влияет на возможность выбора элементов из списка пользователем. Однако и тут приходится городить огород, чтобы поддержка имела представление о том, как этот список выглядит на пользовательском устройстве (т.е. должно быть не более 2-3 видов этого самого списка), т.е. уже не штатный системный. А что вызовет сложности у пользователей? Обязательно найдётся смартфон, на котором какая-нибудь кастомизированная производителем версия Android, на котором какие-нибудь пункты уедут куда-нибудь за границы ViewPort из-за выбора размера системного “шрифта” нестандартного размера (и нигде в другом месте это не проявит себя никак т.к. практически никто не использует штатный функционал). Или не будет способа закрыть этот список без выбора. Если бы он не был настолько часто глючным, то без проблем можно было бы его и использовать. Притом внутри он будет, но костыльно скрытым, чисто для скринридеров и “доступности”. Плюс: каждый раз, когда что-то начинает казаться более-менее завершённым и логичным, найдётся какой-нибудь Apple, который решит просто переосмыслить единицу измерения px т.к. она не учитывает плотность пикселей и понеслось. Вместо того, чтобы просто предложить перейти на em / rem и не трогать px, который в современное время вообще использовать не стоит из-за них. И обилие таких костылей становится нормой в вебе. К тому же, вроде бы, избавились от IE наконец-то уже окончательно, но теперь Edge изрядно досаждает, который теоретически не должен вообще никак отличаться от Chrome. А он отличается местами. И со временем будет огромная избыточность от всяких легаси примочек: скоро снова расчехлим полифилы.
И хорошо, что теперь не так, ИМХО.
Ага, стало ещё хуже. Тонны визуальных красивостей, которые отжирают кучу ресурсов и которые порой хрен отключишь.
Отчаянное стремление каждого разработчика сделать UX "лишь бы не так, как у всех".
"У ребят в мессенджере N просмотр реакций делается по ПКМ по сообщению? А мы сделаем так, что надо на сами реакции тыкать, пусть юзер помучается, гадая, как это сделать!"
А ещё моднявый повсеместный плоский интерфейс с кислотными, не сочетающимися друг с другом цветами — как будто нынешние UI/UX-дизайнеры даже не слышали о теории цвета и прочих темах. Так ещё и в этом плоском интерфейсе порой хрен отличишь, где декоративный элемент, а где контрол.
Во времена Windows XP и популярной классической темы (серенькой) я думал, что вот, наконец-то все поняли, что приглушённые нейтральные цвета интерфейса — это то, что лучше всего подходит для UI. Потому что такие цвета не раздражают глаз и не отвлекают от контента. Но нет же, потом снова появились эти кислотные плоские темы, ставшие почти повсеместными, что для меня выглядит не иначе, как некий откат в развитии.
Хуже нестандартных окон только дурацкие нестандартные контролы, имитирующие органы управления физических устройств со всеми их ограничениями и недостатками.
А самый дурацкий контрол - это замена галки стилизацией тумблера, который при переключении не перекидывает клюв, а едва заметно меняет цвет. То есть уже даже не просто имитация, а имитация имитации. Которая не даёт пользователю ничего, кроме неудобства.
Программирование на Win32 API — утерянное ныне искусство
Ну лично мне такое искусство нафиг не нужно. Пишу на javafx кроссплатформенно под винду, мак и линукс и живу хорошо. Памяти много не ест. Единственный минус - приходится тащить с собой jvm полностью, но 40 мегабайт в нынешнее время это уже приемлемо. Столько весит обычное мобильное приложение.
Хотя вцелом согласен, что electron и прочие web-gui это зло.
На win32 api сейчас писать не вариант просто потому что одну и ту-же программу в нынешнее время приходится выпускать сразу для целой кучи платформ: винда, мак, линукс, андройд, айфон.
На win32 api сейчас писать не вариант просто потому что одну и ту-же программу в нынешнее время приходится выпускать сразу для целой кучи платформ: винда, мак, линукс, андройд, айфон.
Уже давно нет. Если вам надо пускать одну и ту же программу на разных платформах - вы делаете сайт. А сейчас на разных платформах запускаются разные программы, реализующие функционал одной платформы. Вы не можете использовать один и тот же подход к UI на телефоне с лапками и крохотным экранчиком и на ПК с клавиатурой и несколькими огромными экранами. Вы разделяете UX - что-то ваши пользователи получают в телефон, а что-то - на ПК.
Вы не можете использовать один и тот же подход к UI на телефоне с лапками и крохотным экранчиком и на ПК с клавиатурой и несколькими огромными экранами
kirigami хочет с вами поспорить, к сожалению фреймворку безгодунеделя от роду, и примеров софта мало, я знаю пожалуй только neochat и tokodon, и они прекрастны в своей универсальности, и на android и на десктопе использую, удобный ui для обоих вариантов
Два чая этому господину.
Как уже задолбали эти велосипеды с браузером внутри EXE. Некоторые еще создают кучу дочерних процессов. Эти дочерние процессы были придуманы в браузерных движках, их смысл - при открытии вкладки не тратить время на создание процесса для нее, а передавать ее в заранее созданный и ожидающий процесс. Но криворукие лентяи перенося браузерный движок в EXE приложение, не удосужились оключить многопроцессность. И в итоге, приложение, в котором нет никаких вкладок, единственная "вкладка" - его корявый интерфейс - зато имеет несколько висящих без надобности дочерних процессов. Нуачо, железо же позволяет....
Дочерние процессы то вам чем не угодили?
Не знаю конкретно про электрон, но посмотрел на запущенные программы на моем пк. Thunderbird - два подпроцесса, с разными целями. Стим - пяток подпроцессов, из которых только парочка с типом renderer (что можно наверно привязать к "вкладкам"), дискорд - пяток подпроцессов, каждый для своих целей и не создаются новые на "вкладки".
И даже firefox, который действительно создает много подпроцессов не создает их для каждой вкладки, что легко проверяется - можно закрывать в диспетчере случайный подпроцесс и смотреть что отваливается\перезапускается в этом случае. Некоторые подпроцессы критичны и ломают всё целиком, а некоторые просто потребуют перезагрузить вкладку.
Их внедрение даже в браузерных движках было спорным решением, а уж в standalone приложениях, они подавно не нужны.
некоторые просто потребуют перезагрузить вкладку.
Это и есть процессы для вкладок.
Проблема то в чём? В памяти? Так память жрать они все жрут, вне зависимости от количества процессов. Процессы, отмечу, для разных целей, т.е. общего кода там скорее всего не то чтобы много.
В стиме можно уронить интерфейс и подпроцессы его перезапустят. Это удобно с пользовательской точки зрения.
Мне тоже неприятно видеть большое количество процессов, но это чисто вкусовщина в моём случае, т.к. пока оно работает стабильно и не жрёт лишней памяти - проблем я не вижу. Да, это всё потребляет уже не 512мб оперативы как когда-то на винХР, но и цены давно другие, софта разного и с разными функциями стало больше. Всё ещё можно пользоваться софтом с ВинХР, если сильно важна память и много-процессность.
ПС: прекрасно помню времена, когда зависание какой-нибудь вкладки в лисе завешивало весь браузер. Спорное решение исправило эту проблему by design, что на мой взгляд прекрасно. Напомню, что в те времена даже код аддонов выполнялся в едином процессе, что делало всё очень грустно и сложно для пользователей.
Каждый процесс внутри поднимает отдельный рантайм, который нужен для его работы. Который и так поднят в хостовом процессе.
Без множества процессов создаваемых браузером, вообще и нет понятия "упал UI".
В стиме эти цифры на уровне пары мегабайт. Т.е. на ~6 процессов это порядка целых 12мб! Вот это накладные так накладные, как они смеют.
В дискорде 5-10мб минимальное потребление процессов, т.е. на 5 процессов - до 50мб. Это та самая программа, которая не стесняется съедать пару гигабайт на кеши всяких фоточек и прочего, т.е. опять накладные смешные в общем объеме.
У лисы не знаю сколько. Даже если 10мб (грубо и по верхней границе), то на 6-12 процессов выйдет 120мб. Лиса у меня сейчас основной инструмент, в котором открыто по 30-50 вкладок, общее потребление может улетать за 4-6гб. Т.е. накладные конкретно на процессы - не то чтобы заметны.
Да, я понимаю, что это накладные. Но у процессов есть и плюсы, которые почему то игнорируются.
Нет там никаких плюсов, кроме изоляции. Не должно быть нормальным явлением падение рендер-процесса, чтобы записать как преимущество то, что он перезапустится просто.
Сайты нынче очень тяжелые. И когда листаешь бесконечную ленту, внезапно выясняется, что тормозит только конкретный пул вкладок, а остальные себя хорошо чувствуют. Приятно! Раньше если утек какой то сайт, перезапускать приходилось весь браузер (или надеяться что переоткрытие вкладки поможет).
Когда какой-нибудь плагин\сайт роняют вкладку, теперь они делают это локально, не роняя всю лису. Раньше лиса чаще падала. Я понимаю, что можно сказать "говнокодеры, пишите код хорошо и не нужно будет выделять процессы под костыли", но я лично не умею писать программы таких масштабов, как лиса, поэтому я считаю что решение рабочее, а уже потому лучше чем без него.
Не соглашусь, что 12Mb — это мало. Это много. Тем более, 50.
Контекст важен. Если 12мб памяти много, то стим пора закрывать, он в фоне висящий потребляет почти 1гб памяти. Если 50мб много, то дискорд в сумме потребляющий 1гб это совсем плохо.
И вот я сижу, памяти у меня теперь аж 2гб дополнительных, только программы почему то нужные закрыты. Что мне с памятью делать то? Не стесняется никто сейчас кушать память, даже телеграм в фоне 500мб съел и ему хорошо, а это пример программы с хорошей оптимизацией.
Отдельно отмечу, что это примерно та же история, что монолит vs микросервисы. У обоих есть свои плюсы, золотую середину каждый ищет для себя сам.
Спорным решением? Емнип, это было сделано для безопасности и изоляции, чтобы одна вкладка, в случае успешного использования уязвимостей, не получила доступ к содержимому всех остальных вкладок и к основному движку браузера (ФС, сеть, куки, пароли). Хотя может быть вы правы и нужно изобретать какую-то новую схему разграничения памяти, чтобы не плодить кучу процессов - что-то вроде подпроцессов, изолированных друг от друга и от процесса-родителя, но при этом разделяющих часть ресурсов.
Люди часто путают причину и следствие. Chromium порождает процессы не потому, что ему не жалко памяти, а чтобы изолировать GPU-рендеринг, сетевой стек и плагины. Да, в standalone-приложении это выглядит избыточно, но такова цена переиспользования браузерного ядра
зато имеет несколько висящих без надобности дочерних процессов
Так и Win API не гарантирует и не обязывает “запихивать” всю логику в один процесс/поток. Более того, на примере того же Блокнота, идеальным решением будут вообще три потока:
Отвечает за GUI
Отвечает за работу с I/O (условно - работа с файловой системой)
Отвечает за логику самого приложения (управляет всеми потоками, проверяет данные и пр.)
В таком исполнении Блокнот не будет “виснуть” на время файловых операций, а также позволит, например, прерывать операцию открытия больших файлов “на пол пути” и добавить поддержку медленных источников данных (тот же FTP).
на примере того же Блокнота, идеальным решением будут вообще три потока:
Конечно, нет ))
Виснет при работе с большими файлами потому что использует контрол EDIT, предназначенный для маленьких обьемов - такая специализация у блокнота. Для больших обьемов есть контрол RichEdit. Плюс, для больших файлов, желательна другая логика работы - открытие файла в режиме маппинга и перемещение маппингового "окна" по контенту. Такими вещами занимаются специализированные редакторы (EmEditor, Notepad++).
Сейчас во времена асинхронных опреаций и eventloop научились и с одним процессом не виснуть.
++ попытка использовать один и тот же UI на разных платформах провальна изначальна. т.е. не то чтобы она провальна, но это компромисы между универсальностью и удобством. например иногда забывают что телефон и ПК это два устройства с разными физическими параметрами экрана, с разными перефирийными устройствами и с сильно разными сценариями использования.
Вы не можете использовать один и тот же подход к UI на телефоне с лапками и крохотным экранчиком и на ПК с клавиатурой и несколькими огромными экранами
Можете
Один и тот же проект с одним и тем же UI
Сверху мы видим огромный экран, не эффективно занятый разреженным текстом. Снизу мы видим узенький экранчик, в который код никак не вмещается. Не взирая на это, окно с кодом все равно сделано не во всю ширину, а занято серым фоном. Ну да, и правда подходы весьма совпадающие. Просто плохие.
Это проблема дизайна, а не общего UI между десктопом и мобильной платформой. Я делал в точности так, как это показывалось на сайте OpenAI на десктопе и на мобилке (в году, когда только появился ChatGPT)
Если вы видите проблему, то её корни растут именно из Веба.
Это ещё что, меня "впечатлил" дизайн Pomerium. Постоянно возникало желание масштаб меньше сделать :)
Нет, не надо так делать. Никогда.
Эм, что? Здесь код специально без авто переноса. Он прокручивается. Не нравится - изменить это можно одной галочкой. Это не проблема общего UI
Ты просто не можешь показывать код на экране мобильного телефона. Вообще. С переносами, или без переносов - это нечитаемо.
Мне не надо его читать. Мне надо посмотреть на него в плане то/не то и скопировать.
Ну так а при чем тут проблема общего интерфейса?
Сверху огромные пустые пространства, снизу ничего не влезло. Отличный пример, плохо получилось везде.
Это пример сделанный по аналогии, как это сделано было на сайте OpenAI. Всё отступы и поведение.
Эти отступы и поведение в целом сделать можно как угодно.
Вы это не в состоянии понять? Или вы думаете, что я не могу убрать отступы? Я не понимаю эту глупую претензию.
Вы процитировали вот это утверждение:
Вы не можете использовать один и тот же подход к UI на телефоне с лапками и крохотным экранчиком и на ПК с клавиатурой и несколькими огромными экранами
И в качестве контраргумента привели пример. Плохой пример. Чем подтвердили то, что процитировали. Вы не можете использовать один и тот же подход к UI на телефоне с лапками и крохотным экранчиком и на ПК с клавиатурой и несколькими огромными экранами, потому что подучится какаха как у вас на скринах. И на сайте такая же какаха, мотому что там тоже пытаются сделать один интенфейс для нескольких разных устройств. Я не понимаю эту глупую претензию. С чем вы спорите?
Эти отступы и поведение в целом сделать можно как угодно.
Ага, тогда получится использование разных UI для разных устройств.
И зачем тут разное UI? Один и тот же тут UI, который адаптируется под размер окна, в том числе и на десктопе. Ровно так же, как и на мобильных экранах. Главное, думать об этом заранее. Да, достаточно уменьшить отступы относительно размера окна. И это будет одинаково работать и на десктопе и на мобильных экранах. Это не будет мешать использованию на десктопе, потому что маленький размер окна на десктопе тоже важен.
Никто в здравом уме, никогда не будет писать софт под десктоп, считая, что его программа всегда будет развернута на весь экран. Так почему же я не должен адаптировать UI, под минимальное окно на десктопе, ровно так же, как и для использования оного на мобильных экранах?
И зачем тут разное UI?
Затем, что одинаковый неудобен.
И это будет одинаково работать и на десктопе и на мобильных экранах.
Не будет. Потому что на десктопе используется нормальная клавиатура, например. ChatGPT (и не только он) имеет просто отвратительный UI/UX для использования с десктопа. Entrer отправляет сообщение вместо переноса строки и раньше, по крайней мере, это поведение поменять нельзя было. Вобюще, вводить многострочный промпт это боль. Хоткеев тоже нет. А на мобильнике это не надо, в большинстве случаев, там вообще голосовой ввод предпочтительнее.
Но ваш пример как раз показывает, что всем настолько наплевать на пользователя, что даже на отступы забивают.
Вы точно софт разрабатывали? То, о чем вы пишите - проблемы веба, а не адаптивного UI.
Ааа, я понял, это ваша нетленка, поэтому критика воспринимается так негативно, с агрессией в ответ. Надо было сразу в профиль зайти. Вы точно прочитали и поняли то, что я вам написал?
Т.е. это вы тот самый погроммист, который понаделал неудобных интерфейсов. Смешно.
Т.е. вы игнорируете тот факт, что дизайн повторен с веба?
Самое смешное, что фразой “UI взят с веба” вы пытаетесь оправдаться и оспорить утверждение, что нельзя про взять и бездумно вкорячить один и тот же UI на разные устройства. Не надо было повторять, надо было сделать нормально, о том и речь, если повторять, будет какаха, что вы с блеском продемонстрировали.
Спасибо за дискуссию, прикопаю ссылку на тред, буду давать её когда нужно будет показать, как делать не надо. Всего хорошего ))
Подумайте ещё раз. Вы критикуете скрины за отступы, которые являются именно дизайном (взятым из конкретного источника). Они не являются необходимостью, уступками или проблемой. В другом дизайне не будет отступов, и всё "проблема" уйдет или что? Нет не уйдет, потому что этой проблемы вообще не существует. Приложение имеет такой вид, потому что я специально создавал точь в точь вид.
Я не буду с вами спорить, что конкретно этот дизайн не удобный, только это никак не говорит о том, что нельзя создавать общий UI под десктоп и мобильные экраны.
Вы это в состоянии понять?
Никто в здравом уме, никогда не будет писать софт под десктоп, считая, что его программа всегда будет развернута на весь экран.
Это почему? Для каких нибудь CADов, видеоредакторов и прочего профессионального софта место на экране лишним не будет.
Исключения есть всегда
Исключение - это скорее калькуляторы, мессенджеры и прочая мелочь. Главное - тот софт, за которым весь день сидишь на работе.
И, кстати, те же видеоредакторы есть и для телефонов, и для профессиональных студий - но интерфейс несколько отличается.
Если я напишу if (width < 500) then renderSlim() else renderFat(), будет ли это считаться одним UI, или это будут 2 UI, из которых динамически происходит выбор? Лично я склоняюсь ко второму варианту.
Так ведь это будет работать и с обычным окном на винде и с окном на мобилке. Почему вдруг это должно считаться двумя UI?
Но, если у вас renderSlim полностью иначе рисует всё, и приходится отдельно оба метода переписывать при внесении изменений, то да, это два UI. Но у меня такого нет. Если и есть такие условия, то они меняют состояние, а не способ отрисовки.
Вы не можете использовать один и тот же подход к UI на телефоне с лапками и крохотным экранчиком и на ПК с клавиатурой и несколькими огромными экранами. Вы разделяете UX - что-то ваши пользователи получают в телефон, а что-то - на ПК.
Тем не менее, сейчас есть 3 десктопных платформы и 2 мобильных. В любом ли случае нужно 5 приложений? И если да, то на чём тогда писать GUI под линукс?
Нужно 5 приложений. 5. Совершенно. Разных. Приложений.
Так а под Linux на чём его писать? На Qt?
Как удобнее. Я предпочитаю Qt, мне нравятся плюсы. Но биндинги в питон там глюкавые.
Но тогда бизнес скажет: у нас уже есть приложение на Qt, которое можно собрать под Windows и Mac. Зачем нам тратить лишние деньги и время на разработку нативных приложений?
Зачем нам тратить лишние деньги и время на разработку нативных приложений?
Ну, например, чтобы не выглядеть криворукими дебилами?
А бизнесу не всё ли равно, если 0,01% аудитории их таковыми посчитает?
Вопрос был «зачем?», а не «имеет ли смысл?».
А вот эти цифры, про 0.01%, они откуда, если не секрет? Я бы сказал, что к чужеродному интерфейсу в системе чувствительны минимум процентов 40. А первый взгляд на проект - это важный элемент продаж, раз люди тратятся на дизайн. Так что нет, не всё равно.
Ну не только чтобы не выглядить.
Я знаю несколько отличных приложенек для винды на кутях. Другое дело, что это приложеньки для винды, а не пересобранные линуховые.
Такое, чтобы прямо вот пересобраноое и нормально работает знаю только одно - QtCreator :) Ну настолько, наскольно оно вообще нормальное.
или на gtk.
Некоторые даже на wxWidgets пишут...
На Java fx / Java swing, заработает и под линуксом, и под виндой, и под маком. В свинге на выбор либо java стиль, либо системный. Если очень нужно нативности, решается через JNI / JNA.
1.5 десктопных, по факту.
дык современный софт частенько и есть сайт под видом программы, если грубо =)))) С этими б-гомерзкими webivew)))
Но то что современный г-нософт может весить от 100 мб при трех кнопках и никаком функционале - факт. Win32 API - не есть зло. Опять же, если вспомнить эти прикольные странные окна во времена ХР - это была бурная эпоха зарождающегося мультимедиа для всех, когда пришел четвертый пень. По нынешним меркам это все выглядит прям кринжово, но в то время это было круто))
Сейчас с ИИ, по идее, можно рисовать что-то менее кринжовое)
На win32 api сейчас писать не вариант просто потому что одну и ту-же программу в нынешнее время приходится выпускать сразу для целой кучи платформ: винда, мак, линукс, андройд, айфон.
qt насколько я знаю вполне себе позволяет писать софт под все платформы и при этом не тащить за собой тяжеленный рантайм как java
Qt тоже не бесплатен по размеру, т.к. требует библиотек, которые должны быть на целевой платформе или распостраняться вместе с приложением. Другое дело, что можно линковать только те библиотеки, которые реально нужны для работы приложения. Но все равно это могут быть десятки или сотни мегабайт зависимостей.
Другое дело, что можно линковать только те библиотеки, которые реально нужны для работы приложения. Но все равно это могут быть десятки или сотни мегабайт зависимостей.
Ну я в общем-то это и имел ввиду. На десктопе половина либ и так будут стоять в системе, их тащить с сабой не прийдётся. А на мобильной платформе взять только необходимые, ещё и пожать/порезать))
И откуда на обычном десктопе с виндой библиотеки Qt (да ещё и той версии, которая нужна приложению)? Да и под линуксом (если распространяется единый бинарный пакет, который должен бегать на разных дистрибутивах) расчитывать на бинарную совместимость с установленными в системе библиотеками может быть оптимистично. По опыту даже libstdc++ лучше таскать с собой.
Делать единый пакет под разные дистрибутивы уже само по себе ошибка, а вы придумываете проблему там где её нет.
Задача вполне решаемая - скажем, интеловские тулы (компилятор, vtune и т.д.) можно скачать в виде self-extracting архива общего для разных систем. Сборка разных пакетов для зоопарка разных систем требует отдельных ресурсов.
задача решаемая кто бы спорил, но это всё равно будет неправильным подходом, фу таким быть..
сборка под десяток дистрибутивов родного для них пакета с родными для них зависимостями это задача решаемая за несколько минут под кофе с сигареткой, и работать это будет годами без серьёзных изменений.
а если ваш софт достаточно хорош (под этим в том числе подразумевается и открытая лицензия) и станет популярным то эту задачу за вас решат мейнтейнеры дистрибутива сами (хотя никто не запрещает им в этом помочь).
сборка под десяток дистрибутивов родного для них пакета с родными для них зависимостями это задача решаемая за несколько минут под кофе с сигареткой, и работать это будет годами без серьёзных изменений.
Вопрос ещё в разных версиях - скажем, нужно поддерживать разные версии Redhat за последние лет десять. И какого то нужного функционала в версиях библиотек на старых системах может не быть.
под этим в том числе подразумевается и открытая лицензия
Я скорее проприетарщину с грузом легаси имел в виду.
Вопрос ещё в разных версиях - скажем, нужно поддерживать разные версии Redhat за последние лет десять. И какого то нужного функционала в версиях библиотек на старых системах может не быть.
снова несуществующая проблема, умные дяди уже давно всё порешали и на этот счёт в гайдлайнах есть ответ что делать
Я скорее проприетарщину с грузом легаси имел в виду.
мазохизм - дело добровольное, если кому-то больше нравится самому заниматься дистрибьюцией это их выбор, но это не отменяет всего вышесказанного
electron не зло, если знать, как его готовить. Просто большинство не знает и пихает туда свой веб сайт
прим. Fusion360, VSCode (до появления Copilot)
прим. Fusion360, VSCode
плохие примеры, если пользователь готов мириться с рядом недостатков ради некого кол-ва преимуществ это нисколько не отменяет наличия недостатков.
Так расскажите про эти недостатки. Не держите в себе.
больше 20мс реакция на события. Особенно - меню. Меню vsCode - худшее, что я кога-либо видел на десктопе.
Фузией не пользовался, ничего не скажу.
Не знаю почему, но MS игнорирует апи к нативному меню. Хотя раньше было лучше.
Это камень в огород, тык они эмулируют его списками с hover аттрибутом, который всегда имеет задержку
Фузи это Autocad, тяжеленный комплекс, но работает шустро. Все расчеты вынесены на модули Си, а электрон там только для UI и 3D рендера
больше 20мс реакция на события. Особенно - меню. Меню vsCode - худшее, что я кога-либо видел на десктопе.
Я вообще меню крайне редко пользуюсь, но сейчас пошёл потыкал. Субъективно, меню открывается мгновенно, вашей проблемы я не понимаю.
VSCode странное поделие. Реально в нём какое-то удобство только в расширениях Microsoft.
Расширения и есть наверное главная фича. Это по сути песочница, если делать что то подобное на qt, то примерно электрон и получится.
Другой хороший пример когда люди «правильно» используют электрон - это Obsidian
Так я о том, что все расширения не от MS, какие-то убогие и легче не использовать VSCode. Я использую для блокнотов Jupyther и разработке под PostgreSQL - оба от MS. Ну ещё агента ГигаЧата.
Для разработки под Flutter мне проще оказалось поставить и настроить Android Studio, для разработки на python/sql - Eclipse. Возможно, сам погружусь в разработку расширений Eclipse...
Вохможно, в итоге приду к emacs, но IMHO концептуально он сильно отстал.
Вохможно, в итоге приду к emacs
Можете ещё на acme посмотреть для просветления (тут пример использования).
В целом, зачем винить технологию, если используют ее криворукие и жадные.
Опять переносят ответственность с бизнеса на библиотеку. Надо кидаться палками в ms, meta и др
Электрон оправдан когда тебе нужен полный контроль над рендерером (обычно никогда), иначе предпочтительнее таури. Я имел опыт работы с электроном + ffi-napi, и это было отвратительно.
Таури на расте + windows-rs работает в разы надежней
Это же так, что JVM какое-то фиксированное количество памяти съела и всё, сама программа будет больше потреблять раза в три из-за использования сборщика мусора плюс ещё то, что JVM затрудняет написание программ, эффективно использующих память
На самом деле Win32 API приложения благодаря Wine вполне себе работают и на других платформах. Даже где-то был полушуточный пост, что вот дескать Win32 API это единственный стабильный GUI API для Linux :)
Вот на телефонах и планшетах да, я так понимаю Wine не будет работать. Либо, если мы даже и запустим, то пользоваться на сенсорных экранах таким приложением будет неудобно.
Даже где-то был полушуточный пост, что вот дескать Win32 API это единственный стабильный GUI API для Linux :)
При этом и линуксовые сисколлы для каких то специфических задач никто не мешает использовать.
А когда то и конопочные телефоны с Win32 были - понятно, что раскладку контролов по экрану надо было подгонять под размеры, но API был практически тот же.
Проблема в том, что оно плохо работает на винде :)
На самом деле Win32 API приложения благодаря Wine вполне себе работают и на других платформах.
Большинству разработчиков (на ПК) в отличие от требования доустановки фреймворков ставить wine "религия не позволяет"
Я несколько лет назад сформулировал мысль, что Win32-приложение, скомпилированное под Windows XP - самый кроссплатформенный вариант. Даже более кроссплатформенный, чем т.н. web-приложение. По крайней мере, такое приложение не требует определённого браузера определённой версии :-)
Пишу на javafx
А еще веган и прекрасно себя чувствуете?
Окон (обьектов которые обрабатываят сообщения) в одной небольшой программе легко может набраться больше 100. Удачи рулить ими через winapi.
Контролы обычно завёрнуты в свои API и руками их сообщения обрабатывать не надо.
По теме статьи - по мне так проблема скорее в обратном, большая часть приложений использовала стандартные контролы, внешний вид которых можно было настроить под себя в одном месте (стандартная настройка свойств экрана), да и в целом всё выглядело строго и единообразно. Сейчас даже заголовок активного/неактивного окна расцвечивается у всех по своему.
Окна стандартных контролов сами обрабатывают свои сообщения.
9 285 с 32 ГБ ОЗУ, но при запуске Windows 11 память уже была заполнена на 77%.
Вроде как радоваться надо что память на которую немало потрачено занимается чем-то полезным, а не простаивает. Помниться во времена Висты/7ки, Виста с жестким и большим объемом памяти была отзывчивее 7ки - просто за счет агрессивного префетча использовавшего все 8гб, в то время как 7ка помня провал ноутбуков 256Мб+Виста, отдавала на пред загрузку всего пару гигабайт.
А если бы память заполнялась на 100% то уровень радости вырастал бы на дополнительные 23% что вся память используется ?)
А зачем кривляться если вам человек верно сказал что "заполненная" память это на самом деле кеш и суперфетч и это сделано нарочно? Чистится при востребованности другим приложением она моментально, но чаще предзагруженные данные как раз понадобятся и будут использованы, что делает видимую отзывчивость системы в разы выше.
Если бы этот кеш и правда чистился моментально, так ведь нет - мой домашний компьютер долгое время готов был в своп скидывать страницы данных лишь бы файловый кеш в памяти удержать. Приходилось держать rammap -et на горячей клавише. Потом я догадался выключить этот superfetch нафиг, и проблема ушла.
Кривляться ? Отнюдь. Если голая система при загрузке жрет 77% от 32 ГБ тут не радоваться, а плакать надо. Это чего же надо было так с годами наоптимизировать чтобы одна только система столько сжирала. Я не думаю что со времен XP/7/10 винды было добавлено так много революционного кода улучшающего производительность. Сразу в памяти всплывают статьи на habr когда "оптимизированное" меню пуск жрало сотни мегабайт потому что его переписали на электрон или что-то подобное. Сегодня просто запущенный калькулятор и просто открытый 20КБ JPG файл жрут столько сколько хватало всей операционной системе в начале нулевых, хотя в математике за это время ничего не изменилось, да и формат JPG с 1992 года особо не трогали.
P.S. Total Commander вон и сегодня жрет в простое и переходам по папкам в пределах 8 мегабайт. Не знают ребята как кешировать надо.
Система не сжирает целиком всю эту память, а резервирует для пользовательских приложений.
И статья про Пуск тоже мало что имела общего с реальностью. Пуск не был написан на Электрон (а в статье вообще написано про Реакт), Пуск внутри себя имеет WebView окно для показа результатов поиска и всего. Сам Пуск написан на WinUI.
Вот бы скриншот загрузки по процессам, чтобы прикинуть что это могло быть.
Потому что моя вин11 не перезапускаемая месяцами потребляет 10гб (из 32) с учётом запущенных браузера и десятка программ. Да, на систему спокойно может выйти порядка 4-6гб (что по меркам винХР очень много), но эта память доступна и мне не мешает. В случае запуска игр, потребляющих оперативку, система обычно ужимается в расходах и проблем тоже не испытывал.
Так вы продолжаете отвечать не читая на что отвечаете. Зачем?
Думаете, 5 раз повторенная ложь про "система жрёт" сработает лучше чем 1 раз? Система не жрёт, а резервирует. И linux-based системы делают то же самое под данные, об этом знает любой кто как минимум видел htop.
Думаете, 5 раз повторенная ложь про "система жрёт" сработает лучше чем 1 раз? Система не жрёт, а резервирует.
Да можете называть это как угодно, пусть будет резервирует, это ничего не меняет потому что эти 73% остаются недоступны пользователю пока система их не освободит. Их менеджер памяти банально не отдаст другому ПО пока система эту память не освободит.
P.S. Да да, чистится и переадресовывается она моментально, но 20+ гигов в оперативе которые "скорее всего" понадобятся для ОС это такое себе.
Да можете называть это как угодно, пусть будет резервирует, это ничего не меняет потому что эти 73% остаются недоступны пользователю пока система их не освободит. Их менеджер памяти банально не отдаст другому ПО пока система эту память не освободит.
С чего вы взяли, что свободные 27% система отдаст сильно быстрее?
когда "оптимизированное" меню пуск жрало сотни мегабайт
И панель задач сотню мегабайт. И курсор мыши. И часы в трее.
Но есть один нюанс - речь про одну и ту же сотню мегабайт.
Все 77% от 32гб на чистой винде и новом пк это кеш? И почему кеш помечается как занятая память, это нововведение w11? У меня на w10 из 64гб в данный момент занято 24гб, при этом размер кеша 34гб, очевидно что занятая память не включает в себя кеш. И вообще в заметке же речь шла о программах, которые распухают как на дрожжах, а не про кеш.
Это же старая как мир парадигма Wintel: софт требователен к железу -> создаёт рынок для нового железа -> делаем софт ещё более ресурсоёмким -> делаем более лучшее железо -> загружаем его ещё более ресурсоёмким софтом...бесконечный цикл. Не удивлюсь, если когда-нибудь выяснится, что MS, AMD и Intel управляются с одной и той же Нибиру
Не удивлюсь, если когда-нибудь выяснится, что MS, AMD и Intel управляются с одной и той же Нибиру
Это уже сейчас известно, что именно так и есть. /s
Это называется "сговор Уинтел" (Wintel)
Никакой конспирологии, просто выгодный симбиоз: майки делают софт тяжелее, чтобы стимулировать продажи железа интел, а интел спонсирует оптимизации под свои новые инструкции в виндовс
Пользователь может память купил, для того, чтобы запускать опредленные тяжелые приложения, а не для того, чтобы просто ее занять.
Память, содержащая кешированные данные и код, не используемые в данные момент, называется "Зарезервированная", является отдельной метрикой и не учитывается в процентном показателе занятой памяти. В процентном показателе занятой памяти используется только показатель "Используется (Сжатая)".
Скриншот
Да, но не совсем. "Используемая" Windows память тоже по большей части кеши разной степени необходимости - это я узнал, когда месяцами гонял тесты памяти на рабочей системе. Можете попробовать запустить какой-нибудь karhu или аналог с крутилкой ГБ и начать там накручивать выделенную ему память, начните с X - 4ГБ и ужимайте дальше, винда продолжит работать (с адскими лагами) и уступать память примерно по последнего гигабайта-двух.
Вы уверены, что это именно кеш, а не нужные системе данные, которые ей пришлось отправить в своп (файл подкачки)? Был ли включен файл подкачки во время тестов?
Вы уверены, что это именно кеш, а не нужные системе данные, которые ей пришлось отправить в своп
Смотрите, раз работает без них в оперативке - значит не такие уж и нужные. Значит уступают место реально нужным пользователю.
Был ли включен файл подкачки во время тестов?
Был, отключать файл подкачки всегда плохая идея, на любой системе и конфигурации железа.
Я на веб-технологиях могу написать блокнот, который будет весить 2 мегабайта. Может, всё таки, рукожопы? Да не, АПИ плохой...
Кстати, вот есть класс браузера, встроенный в ОС (IWebBrowser). ЕХЕ, использующее его, имеющее интерфейс на HTML/CSS/JS и проброс HTML/JS-обработчиков в нативный код весит ~100kB (вместе с HTML/CSS). Но все равно тащат этот мерзкий электрон с хромиумом.
Да проблема не в рукожопах, а в том что за оптимизацию по сути не платят. Нужно сделать быстро и получать деньги. Сам конечно офигеваю, с теми же ИИ-шками. Пишу нужна таблица для админки, где будет 1 максимум 3 юзера - ИИ-шки: Мы тебя поняли, без BIGINT для id юзера не обойтись. А ведь так почти все пишут, зачем думать просто берём самый большой тип. А как CSS используют вообще мрак, когда видишь элемент и в нём пара десятков классов прописано. И так практически у каждого элемента, какая там каскадность CSS.
В случае с id пользователя ИИ всё правильно делает. В случае 3х пользователей вы, вероятно, не сможете измерить разницу в потрблении ресурсов.
Ну, да использовать в 8 раз больше памяти, чем нужно, это правильно. А потом такие упс, а чего это страничка WP генерируется 2 секунды на пустом сайте, а страничка в браузере занимает несколько сотен мегабайт. Да если бы эти 8 байт были только в одной маленькой таблице куда не шло, но есть куча других таблиц, где этот userid используется и там уже далеко не 3 записи, плюс по ним строятся индексы, а иногда и составные индексы. Так и набегает...
У BIGINT та же самая разрядность, что и у самого обычного указателя на современной платформе. И эти 64 разряда в указателе точно так же избыточны, но указатели используются намного чаще, чем ваш идентификатор пользователя, в том числе и в браузерах. Заботиться о длине идентификатора пользователя, но игнорировать указатели довольно странно, не находите ли?
Кстати, тот же Javascript имеет вообще ровно 1 числовой тип данных (под капотом иногда используется два разных), а потому размер страницы в браузере вообще никак не зависит от разрядности идентификатора пользователя.
Причём тут указатели, если речь шла о базе данных? Да и указатель может указывать на структуру данных, а не на одну переменную.
В том же JS свои приколы, например, я делал свой data grid. ИИ-шки поголовно пытаются для каждой ячейки ставить кучу классов, на каждую ячейку вешать обработчики событий (а не использовать один общий). Начинают для каждой ячейки добавлять свой ID, не пытаются переиспользовать DOM при обновлении и т.п.. Да если их тыкать везде носом, то сделают.
Речь шла о том, что вы экономите ровно 3 байта памяти, рискуя ради этого реальными багами на конвертации типов и ещё такой же крошечной, но потерей производительности. При этом в этом же коде компилятор впустую потратит миллион этих байт.
Ещё раз, вы что всерьез думаете, что кому-то нужна БД в которой просто одна табличка в которой 3 юзера? Про то что могут быть другие таблицы в которых есть столбец с userid, в которых могут быть сотни тысяч или миллионы записей, мы как то упускаем?
Это если не углубляться в детали, и то что есть ещё куча преобразований этих цифр. Они в одном виде хранятся, в другом передаются, в третьем преобразовываются в драйвере БД, в четвертом используются. Для того же JS если он работает с полем BigInt нужно дополнительно следить не выходит ли значение за пределы MAX_SAFE_INTEGER. Зачем думать - бесплатно же.
Для примера, делал логгер на Bun, который в несколько раз быстрее pino. Так там просто замена Math.floor(us) на us | 0 в горячем пути, дала общую прибавку к скорости записи логов на 15%.
а чего это страничка WP генерируется 2 секунды на пустом сайте, а страничка в браузере занимает несколько сотен мегабайт
Совсем не потому, что в таблице с тремя записями используется BIGINT для id. Это экономия на длине древка спички в рамках единственного требуемого коробка.
Ну да я связанные таблицы в которых сотни тысяч записей, и в которых есть столбец userid и по нему есть индекс такой: ну да, ну да, пошел я...
Я не говорю что WP тормозит исключительно из-за BIGINT для userid. Это просто пример проектирования, когда в месте, где тебе точно известны ограничения используется оверсайз. Проблема только в том, что такой оверсайз не ограничивается userid. Потом мы имеет сайты у которых грузится мегабайт CSS, пару мегабайт JS, из которых 99,8% кода не используется.
Не набегает. Набегает за счёт использования неоптимальной архитектуры, неправильных алгоритмов и неудачного выбора структур данных. У решения с BIGINT по-умолчанию есть много достоинств:
у него нулевая когнитивная нагрузка на команду, поддерживающую код
оно не требует решения "проблемы 2000-го года" при неожиданном росте данных
оно почти всегда "бесплатно"
НО, если у сценарий, что использования BIGINT может оказать заметное влияние на производительность, то, уверен, вы это сами знаете, и являетесь достаточно квалифицированным специалистом (иначе вас просто не допустили бы делать такой выбор), чтобы это осознавать и добавить в prompt "используй для хранения user_id INT или что-там-ещё . Я знаю, что делаю"
А потом такие упс, а чего это страничка WP генерируется 2 секунды на пустом сайте, а страничка в браузере занимает несколько сотен мегабайт
Не нужно натягивать сову на глобус. Замена BIGINT на INT никак не уменьшит размер страницы в браузере и никак не повлияет на эти 2 секунды
Замена BIGINT на INT никак не уменьшит размер страницы в браузере и никак не повлияет на эти 2 секунды
Причём тут размер страницы в браузере, если речь шла о БД? Каким боком генерация страницы WP к тому что происходит в браузере? Вы читаете на что отвечаете
оно почти всегда "бесплатно"
Так же говорят те кто делают приложения на Electron с кучей фреймворков. Ну подумаешь, простое приложение занимает 500+ МБ, зато быстро и на любой системе запускается. Ну подумаешь приложение занимает 1 ГБ памяти, это ж почти бесплатно (до подорожания памяти).
Так я же ваш комментарий цитирую в контексте обсуждения BIGINT для user_id: https://habr.com/ru/articles/1025204/comments/#comment_29854816
Ну, да использовать в 8 раз больше памяти, чем нужно, это правильно. А потом такие упс, а чего это страничка WP генерируется 2 секунды на пустом сайте, а страничка в браузере занимает несколько сотен мегабайт
Ну, да использовать в 8 раз больше памяти, чем нужно, это правильно
Ну и в целом, оптимизация выглядит не так. Умозрительная оптимизация хоть и весьма проста, однако часто не имеет существенного эффекта (а в ряде случаев имеет и вовсе отрицательный эффект).
Чтобы говорить о нормальной оптимизации нужно подтверждать подобные численные эффекты оптимизации. Иначе это просто усложнение на пустом месте.
В случае с id пользователя ИИ всё правильно делает. В случае 3х пользователей вы, вероятно, не сможете измерить разницу в потрблении ресурсов.
Смотря сколько будет внешних ключей на эту таблицу.
речь объём используемой памяти.
то что на веб технологиях можно сделать блоктнот весом 2МБ с функциональностью вот этого дата uri аж на 40 байт, это здорово конечно.
data:text/html, <html contenteditable>на винапи можно в несколько кБ .exe упихать, и он при исполнении загрузит в память лишь user32.dll размером те самые 1.8МБ, а браузер(электрон), с единственной такой вкладкой сожрёт пару сотен МБ, не говоря про то сколько сам весит.
С удобствами, но всё ещё не 2 Мб, вайбкод:
data:text/html;charset=utf-8,<body><textarea id="t" style="width:100%;height:100%;border:0;resize:none;font-size:14pt;" placeholder="Напишите что-нибудь тут"></textarea><button id="b" style="position:fixed;right:20px;bottom:20px;padding:10px;font-size:14pt;" onclick="a=document.createElement('a');a.href='data:text/plain;charset=utf-8,'+encodeURIComponent(t.value);a.download='note_'+new Date().toLocaleString('sv').replace(/[: ]/g,'-')+'.txt';a.click()">💾 Сохранить</button><script>document.onkeydown=e=>{if((e.ctrlKey||e.metaKey)&&e.key=='s'){e.preventDefault();b.click()}}</script></body>Так и у меня речь про объём используемой памяти. Вот реальный случай, приложение на вебе, рисует большие часы на весь экран и внизу поле ввода. На двух экранах независимо.
это вот эти веб технологии?
let handle = CreateWindowExW(
ex_style,
PCWSTR::from_raw(class_name.as_ptr()),
PCWSTR::from_raw(title.as_ptr()),
style,
position.0,
position.1,
adjusted_size.0,
adjusted_size.1,
parent,
pl_attribs.menu,
GetModuleHandleW(PCWSTR::null()).map(Into::into).ok(),
Some(Box::into_raw(Box::new(window_flags)) as _),
)?;Таури классный, но все же 3 мегабайта потребляет только мейн процесс, тот самый который src-tauri.
2МБ? Что вы там хотите напихать?
notepad.exe в Windows11 на диске занимает 360кб (триста шестьдесят килобайт).
50 мегабайт, которые показывает винда - это рантайм вместе с замапленными библиотеками.
С веб-технологиями ваш редактор будет занимать мегабайт 300 в памяти.
Может, всё таки, рукожопы? Да не, АПИ плохой...
рукалицо
Это вот так, что-ли?
Это включая браузер? Или только ваш код?
Есть же notepad x64 20кб чистый WinAPI и asm
https://github.com/wesmar/notepad
в памяти полностью размапленый он занимает 2.2Mb (данные по ProcExplorer):
https://prnt.sc/RdFlaypZyIBT
Я по горло сыт стандартно выглядящими приложениями.
Ви так говорите, как будто это что-то плохое.
Блокнот — это, блин, приложение для простых ЗАМЕТОК, а не замена Word, калькулятор — это калькулятор, а не планировщик лунной миссии НАСА
Тем временем планировщик миссии Аполлон 11 весил 72 КБ и требовал 4 КБ памяти.
Было дело, тогда это казалось высокими технологиями. Помню в школе, когда про саму возможность существования таких окон узнал, очень впечатлился и векторный редактор написал под это дело. Ну, чтобы такие окна пихать везде где можно :)
Кстати, порекомендуйте простой редактор инженерной графики под Windows.... не Inkscape и не nanoCAD
QCAD?
solvespace
zcad
Ну, простота относительна. Я бы из бесплатного посоветовал LibreCAD или FreeCAD (последний вроде ожил, в апреле вышла 1.1.1, есть 3D).
Скрытый текст
Кстати, порекомендуйте простой редактор инженерной графики под Windows.... не Inkscape и не nanoCAD
AutoCAD 2000
На десятке запускается без проблем, на одиннадцатой не пробовал.
Dia
В большинстве своём подобные нестандартные окна смотрятся откровенно плохо. Да и создание принципиально непортируемых windows-only приложений, это отвратительная идея
Да и создание принципиально непортируемых windows-only приложений, это отвратительная идея
Вспоминайте идеологию MVC и ее аналоги. Ядро программы будет портироваться, внешний вид будет переписываться под каждую платформу. Даже если Вы делаете что-то кросс-платформенное на каком-нибудь FreePascal'е, эта идеология у Вас в приложении будет присутствовать в той или иной форме.
Согласен, это всё можно сделать, и не является rocket science. Но в дикой природе я пока не сталкивался с хорошими кроссплатформенными приложениями с окнами нестандартной формы. Вероятно всё чуть сложнее или заметно дороже, чем кажется
Вероятно всё чуть сложнее или заметно дороже, чем кажется
Оно чуть сложнее и дороже, поэтому мало кому хочется такими вещами заниматсья. Лучше ядро программы отполировать, сделав стандартный интерфейс под каждую ОС. Да и пользователи бывают разными. Во времена расцвета нестандартных окон под Windows, которые делали через всякие хаки WinAPI, пользователи Mac'ов крайне негативно относились к "неродным" для этой ОС контролам и интерфейсам, и что-то написанное на Java можно было протолкнуть, только это был безальтернативный кровавый энтерпрайз.
Всё относительно. В те времена это было «вау» и работало, потому что «Windows only» в те времена это даже хлеще чем сейчас «Anrdoid only». Применять современные мерки к тем штукам бессмысленно. Примерно как рассуждать о непрактичности карет с лошадьми на фоне автомобилей.
Подойти к реализации этой идеи можно разными способами.
Это вот работает у меня и на Винде и на Лине
Мне кажется, в идеале должно быть кроссплатформенное ядро и набор нативных непортируемых программ для каждой платформы отдельно, использующих по максимуму нативные API системы, написанные на языках нативных для этой платформы, использующие стандарты дизайна для этой платформы и экономящие ресурсы. В таком случае окна будут выглядеть максимально стандартно, но всё же софт будет непортируемый.
Но на практике это дорого и пока этого нет у конкурентов, мало какой бизнес это волнует.
Есть такое: https://www.remobjects.com
я зашел ради зеленой головы
я не разочарован
Мне такие нестандартные окна не нравятся, хотя для вау-эффекта выглядят прикольно. Но все-же идеология разделения клиентского и системного UI должна быть. Вот client area, в ней рисуй что хочешь, но за пределы не вылезай - система должна оставаться системой.
А вот современные окна в современных ОС, несмотря на их "прямоугольность", реально бесят. Отсутствие явного заголовка, четких границ окна, полосы прокрутки вообще практически невидимые, какие-то невзрачные элементы управления (кнопки и прочее) - зачастую непонятно кнопка это или просто надпись. Лучшие окна были в старых классических системах: Win95/98/XP, в семерке еще можно настроить классическую тему, но увы - все современные браузеры даже под линукс пропихивают этот баззаголовочный ужас.
То есть "окна странной формы" и современный UI - это два отклонения в разные стороны, а норма была в старых добрых системах. И ее прелесть в том, что элементы управления были заметные и скевоморфные, но при этом стандартные и структурированные, что избавляет от необходимости привыкать к каждому конкретному интерфейсу.
Мне нравится как сделан интерфейс в Microsoft Office до 2003 версии включительно. Там все элементы на панельках можно как угодно перетащить и настроить под себя. Панельки вытаскиваются в отдельные окна, прилипают к краям экрана, группируются как угодно. А меню сверху и списки со шрифтами являются частным случаем таких перетаскиваемых кнопочек — туда можно впихивать нужное и убирать ненужное, настраивается абсолютно всё.
Фокус в том что эти менюшки‑кнопочки настраивались в GUI через Drag&Drop. То есть интерфейс был редактором самого себя. Ты не настраиваешь список команд в отдельном окне, ты буквально перетаскиваешь кнопки на панельку/менюшку.
Для простого пользователя это оверкилл+переусложнение. А вот для профессионального использования это прекрасно, я считаю. В VisualStudio кажется до 2008 версии так тоже было можно делать, потом порезали. Вообще, в современном тяжелом софте такое сейчас встречается. Например, в 3ds max есть кастомизируемый ленточный интерфейс, где тоже всё можно таскать и настраивать.
+++ вот да, ничего же не видно теперь на меню, где границы где кнопки (или это не кнопка а надпись). И почему отвязали внешний вид программ от системных настроек? ведь для этого и делалась ОС чтобы использовались общие ресурсы и API окон. Неужели теперь программы не берут API элементов стандартных элементов а используют только свои рисунки кнопок?
согласен с автором. в туже степь: недавно в очередной раз обратил внимание на стенд со смартфонами в магазине, точнее на то что все, ВСЕ, абсолютно все смартфоны это прямоугольник с экраном. все экраны были погашены - картина 30 штук чёрных прямоугольников. просто нет таких смартфонов теперь которые своим дизайном производили бы вах эффект и хотелось бы их купить.
электрон тоже не люблю. электрон это то что лучше бы вообще никогда бы не создавали.
Аж олдскулы свело, я делал такие окна на vb и delphi в начале 00-х и мне это казалось фантастикой и хакерством. Добрые были времена. Сейчас выберу что-то стандартное. Но приложения на браузере осуждаю)
У приложения на браузере есть существенное преимущество - его относительно быстро сделать, причём сразу для всех основных платформ. Для бизнеса/стартапа это может быть гораздо более важно, чем размер приложения или потребление памяти.
А вот для конечного пользователя этого бизнеса гораздо более важно потребление ресурсов своего компьютера. Да и для бизнеса это всё не так важно только до тех пор, пока лёгкого, нативного и надёжного софта нет у конкурентов.
Я в курсе преимуществ таких приложений и понимаю почему выбирают этот вариант. Но тут как с дешевым фастфудом. Я не про тот, где котлета в бургере из мраморной говядины, а про тот, который иначе как корм не назвать. Нет ничего плохого, чтобы изредка его употребить, когда нет возможности нормально поесть, но есть это постоянно - не мой выбор. С приложениями на электроне такая же позиция, но увы, приходится есть это на постоянке, т.к. других аналогов не осталось
Как по мне так правильнее когда внешним видом окон и элементов управления занимается оконный менеджер. И только он.
Для этого в том числе и придуманы темы оформления.
А мне приложения со стандартным интерфейсом нравились. Хотя бы понятно было, куда кликать. А сейчас зачастую вообще не поймёшь, что там у них в интерфейсе.
Меня сильно раздражает современная любовь к "воздушным" интерфейсам, когда на весь экран у тебя одна кнопка и поле ввода, и что-бы что-то настроить надо по десятку экранов пройтись по мудреному маршруту с развилками, при этом огромная площадь остается незадействованной, занята просто фоном или дизайнерскими украшательствами.
Особые лучи возмущения тем, кто делает крохотные поля ввода для длинного текста, при огромным свободных пространствах.
Особые лучи возмущения тем, кто делает крохотные поля ввода для длинного текста, при огромным свободных пространствах.
Это дети тех, кто во всяких бюрократических формах под фамилии 8 клеточек выделяет (Щекочихины-Крестовоздвижениские негодуют). Для них в аду есть отдельный, маленький котёл.
Это потому что у большинства потребителей слишком низкий IQ, чтобы вообще осознать набитую информацией страницу. Я делал себе на сайте checkout, там вообще все влезло сразу на один экран. Потом другу ссылку кинул - он сказал, "не интуитивно", я как-то пропустил мимо ушей. Потом друг-тестировщик пришел и уже на пальцах объяснил - если на каждой странице больше одного вопроса, это для большинства посетителей уже проблема.
А что касается полей несуразного размера - так это просто сделанный кое-как адаптивный интерфейс.
если на каждой странице больше одного вопроса, это для большинства посетителей уже проблема.
Вы уже перестали пить коньяк по утрам? Отвечайте, да или нет (ц)
Понапроектируют странных интерфейсов а потом возмущаются что пользователи не те.
Да я причины более менее понимаю. Тут и мода и стремление к упрощению, подстройка даже под самых.. хм.. интеллектуально слабых.. пользователей, и попытки унификации интерфейса с мобильными приложениями с их маленькими экранчиками и управлением пальцами.. Но то что в итоге получается, мне категорически не нравится.
Понятно что попытка запихнуть все сразу на один экран это тоже антипаттерн, когда там намешано много, слабо взаимосвязанных логически элементов управления, так что в глазах пестрит. Но сейчас чаще встречается именно описанное выше. Причем такой "простой" интерфейс в работе часто оказывается как раз сложнее.
Вот даже тот проект над которым я работаю на беке. На фронтовой части там черт ногу сломит, я уже с ним лет пять работаю, и до сих пор с трудом могу найти многие настройки, потому что они все прячутся в лабиринтах "легких, воздушных" интерфейсов, не перегруженных элементами управления. Возможно это у меня уже старческое бурчание, но как по мне реально раньше было проще в похожих настройках. Да там может быть и пестрило слегка, зато открыл пару-другую окон и настроил все что нужно, вместо увлекательного квеста на пару часов в духе "найди флажок на десятке экранов, часть из которых появляется только при определенном наборе установок". Реально часто оказывается проще найти нужную настройку на беке и через БД ее изменить. И так бывало не на одном современном проекте, нынешний не исключение.
Культура десктопного UI перестала считать крутыми безумные скины, она хочет, чтобы окна надёжно работали и не мешали процессу. Странные окна стали ассоциироваться с уловками, рекламным ПО, панелями инструментов и раздутыми утилитами, нежели с серьёзным ПО. И это печально.
Эта ассоциация не на пустом месте появилась, часто именно так оно и было, все эти выпендрежные окна очень любили разные создатели мусорного ПО, которого в те годы тоже хватало. Да и все эти нестандартные украшательства довольно сильно раздражали. Бывало непросто догадаться как такое окно свернуть, перетащить, хоть как-то с ним взаимодействовать. Как по мне хорошая ОС должна стимулировать писать под нее максимально стандартным способом, со стандартным интерфейсом. Пользователь не должен ловить ступор, видя окно с которым непонятно вообще как работать.
Справедливости ради, даже на win32 большинство приложений всё равно были обычными прямоугольниками
Странно. У меня как раз win11 и при старте запускает нужные мне приложения и сервисы, а прямо сейчас пишу в Хроме, который сожрал 2.6 Гига и при этом из 32 Гб оперативной памяти занято - 11 Гб, или 36%. и это хорошо, память должна работать. В принципе для ОС типичное поведение - забирать как можно больше памяти и утилизировать ее. Так и должно быть.
Откуда у автор 77%?
¯_(ツ)_/¯
Все пользуются электроном и прочим вебом только потому, что он работает на всех платформах одинаково. На каждой операционке свой апи или фреймворк, в котором такие вещи реализованы по разному или вообще никак. Что уж говорить про фигурные окна, когда открытие диалога выбора файла вызывается по-разному, не смотря на то, что внешне виндовый и qtшный на линуксе выглядят одинакого
В Винампе ещё можно было диджеить, если наловчиться. А сколько всякого откровенного всратого, но лампового софта можно было почерпнуть на сборниках. А чего стоили только диски Игромании...
Позволю себе процитировать себя же:
С "искусством использования WinAPI" случились разные операционные системы. Причем в эти разные операционные системы почему-то за 40 лет существования десктопного софта, так и не завезли стандартной кроссплатформенной библиотеки, для десктопных приложений. Браузеры же относительно давно осилили общий знаменатель разработки веб-приложений.
Во всех современных браузерах ваше приложение будет выглядеть одинаково, в нём будут одинаково работать сетевые вызовы. А заодно и элементы приложения будут в одном и том же месте, и дома на "винде" и на работе на "маке", потому что это будет одно приложение, а не два разных приложения с разными дизайнерами и командами разработчиков.
Отдельные приложения под каждую десктопную операционную систему, за редким исключением в лице системных утилит, пользователям не нужны. Они не были им нужны никогда. Они были нужны разработчикам операционных систем для продвижения своих продуктов, которые использовали их для придания "индивидуальности" своим продуктам. Индивидуальность там, правда, на уровне трёх подружек светских львиц, которые стараются одеваться по-разному, но в итоге все три одеты просто безвкусно.
Отдельные приложения для мобильных приложений, кстати пользователям нужны. Но отдельные от десктопных, а не отдельные для Айфона и Андроида. Что характерно, для мобильных устройств, хоть стандартного стандартного кроссплатформенного гуя и не завезли, но хотя бы выбор нестандартных (Flutter, React Native) больше, чем для десктопа (где сейчас из относительно комерчески популярных только Qt остался, и то очень относительно). При этом и времени и попыток (Avalonia из нового, GTK из менее нового, аж три десктопных библиотеки от Java) у десктопа было то побольше. Но всем этим технологиям по уровню распространённости и доступности разработчкиков до современного фронтенда очень далеко. Даже вместе взятыми.
Даже в 2026 агентное программирование не решает проблему, для менее распространённых платформ меньше примеров для Клода, он пишет на них хуже, тесты нужно запускать разные, ревьюить более редкие платформы нужны более редкие разработчики.
Позволю себе сказать что за использование курсива и жирного текста в манипулятивных целях надо от разработки ui отлучать. Не говоря уже о спорных тезисах на грани инфоцыганства.
А почему никто не придумал WinAPI для веба? Пишешь на WinAPI со всеми его парадигмами, а он потом транслируется в WASM/JS.
Совмещать приятное с полезным, так сказать.
Wine под WASM собрали:
https://www.boxedwine.org/app/abiword/
но при запуске Windows 11 память уже была заполнена на 77%
А это точно плохо? Возможно я заблуждаюсь, но выглядит выгодным кешировать в доступной памяти как можно больше всего системного, потому что запуск почти любого действия наиболее вероятно задействует быстрый кеш вместо чтения с диска, что увеличит отзывчивость системы. Естественно, "тяжелый" софт с высокими требованиями к доступной памяти, выдушит кеш и займет память сам, но в этой ситуации не случается нехватки памяти, она просто перераспределяется в пользу требовательного софта. Или это все так не работает?
О, я помню, где я впервые увидел "окно странной формы" - в легендарном продукте ребят из Культа Мертвой Коровы.
Скрытый текст
Помню приложение было. Там баба рандомная раз в час на панель задачь выходила и начинала или стриптиз танцевать или раздеваться ))))
Были же времена. А ещё помню компьютер с 24 мб озу и там windows 98 работал и даже office 98 запускался. Были же времена, когда 24 мегабайта на офисные нужды хватало.
Я Думаю первый из тех, кто наутит ИИ превращать приложения в nativе минуя запуск через виртуальную машину, тот бабла хорошо срубит.
как вообще можно ставить в один ряд tauri и electron, когда речь заходит об "bloatware"?? tauri требует в десятки раз меньше памяти чем electron (который по любому случаю таскает с собой браузер в бандле), и по размеру близок к нативному приложению.
Да, скины в Winamp были прикольными, но писать и поддерживать кастомные WM_NCPAINT и WM_NCHITTEST для каждого окна - ад. Индустрия выбрала стандартные прямоугольники не от скуки, а ради унификации и снижения когнитивной нагрузки на юзера
Эх, открыл очень старый проект на Дельфи - всё ровно так:
procedure TPasswordFormAbon.FormCreate(Sender: TObject); var CapY: Integer; begin ClientWidth:=BackImage.Width; ClientHeight:=BackImage.Height; CapY := GetSystemMetrics(SM_CYCAPTION); rgn:=CreateEllipticRgn(4,CapY+4,291,CapY+200); SetWindowRgn(Handle, rgn, True); with UserNameEdit do begin Height:=18; Width :=126; Left :=38; Top :=70; end; with PasswordEdit do begin Height:=18; Width :=126; Left :=38; Top :=120; end; with BackImage do begin Left:=0; Top:=0; end; LeftDown:=False; RightDown:=False; OldWindowProc:=WindowProc; WindowProc:=NewWindowProc; end;
Блин, я не знаю что тут с форматированием!
На выходе как-то так:
Программирование на Win32 API — утерянное ныне искусство; я с ностальгией вспоминаю, как когда-то программировали приложения для Windows.
Почему утерянное? Полно людей, особенно среди 40+ летних, чо хошь напишут - только попроси и денег заплати. Но кому оно надо на сегодняшнем рынке.
Я по горло сыт стандартно выглядящими приложениями.
А я вот по горло сыт всякиими недоприложениями, а так же сменой интерфейсов самой Меломягкой! Компьютер (приложения и ОС в частности) это инструмент, от которого требуестся стабильность работы и понятность и унификация интерфейсов. Очень раздражает когда кроме выполнения целевой задачи приходится искать какую то кнопочку которую разработчик засунул в нестандартное место. Спрашивается
.
Я не понимаю - автор хочет вернуть все вырвиглазные свистоперделки и предлагает разбираться заново с интерфейсом каждого приложения вместо того, чтобы спокойно пользоваться стандартным интерфейсом? Как мне кажется, это не практично.
Иногда поражает прожорливость, а точнее запущенная избыточность движков графики обычных браузеров, например на выводе текста, когда ОЗУ много-то особенно и не требуется, достаточно обычных WinAPI USER32 и GDI функций типа TextOut и т.п. А они что то там рендерят и хз что еще делают, в итоге вместо 100Кб вылезают сотни Мб (минимум).
Ой, эта оконная система та ещё хохма была. Две главных проблемы - энергоэффективность и безопасность. Из за этого дурацкого цикла обработки сообщений толком нельзя заставить гуишное приложение спать. На любой чих создавалась окно, даже если оно не нужно. Оно просто висит на десктопе невидимое и без размера. Это не мешает их перечислить, сделать видимыми и посмотреть чего там разработчик попрятал.
Программирование на Win32 API — утерянное ныне искусство
Нафиг это ваше искусство. Пришлось приобщиться некоторое время назад.
Каждый метод API возвращает код ошибки. Кто-то int, кто-то uint, кто-то long, кто-то ulong. Каждый раз надо разбираться, что же, бл..., вернётся.
При ошибке надо выполнять магические действия. А если другая ошибка успела случится - будет "искусство".
Чтобы вывести просто текст - надо создавать Editor и мучительно долго прятать всякие линейки прокрутки.
А потом выясняется, что ХХХ нет в win32api и надо как-то обратиться к новому .net API.
Win32api было рождено без архитектора, без единой структуры и правил, а то, что всё же стало правилами - просто ошибка проектирования. А потом его просто забросили (потому что это невозможно поддерживать)...
Я понимаю, почему win16api выросло таким, но при создании win32api можно было бы сделать уже нормально и единообразно. Но нет, Микрософт это контора бардака и рандомных решений.
А потом выясняется, что ХХХ нет в win32api и надо как-то обратиться к новому .net API.
WinRT API основано на технологии COM, к .NET оно прямого отношения не имеет
Толи дело линуксы - старый софт просто не запустится на новых версиях т.к. нет совместимости. Толи дело маки - поменяли уже дважды (по моему?) формат файлов, старый софт не запустить.
Действительно, винапи херня полная.
маки - поменяли уже дважды (по моему?) формат файлов
У них уже четвёртая архитектура по счёту (m68k->powerpc->x86_64->arm64) и радикальный переход с классики на Mac OS X.
Но и нынешняя винда бинарники от 3.x или раньше не переварит, да и c игрушками конца 90х (уже под Win32) бывают танцы с бубном.
нынешняя винда бинарники от 3.х или раньше не переварит...
Современные отказываются запускать программы времён XP и Vista, причём избирательно: иногда не работает сама программа, а иногда - только её установщик (но если перенести папку из Program Files, то всё заводится).
Не пойму за что минусы, никто не попадал в такую ситуацию? Когда программа или её инсталлятор не запускаются в "Режиме совместимости"? Причём на XP/Vista/7 всё нормально, программа 64-битная, никаких препятствий для запуска нет, WinAPI обратно совместим, да? Причём установка в виртуалку и перенос папки с установленным ПО в хостовую систему прогу магически оживляет (но не всегда).
Тоже правда.
Я больше хотел сказать, что по разному люди работают с апи в операционках, и часто решения по апи оказываются следствием многих разных проблем.
У разных платформ - разные проблемы.
Я под макось писал один раз (ровно тогда же, когда под win32api) - и хотя там API не без придури, но насколько ж всё просто и понятно.
Под linux не писал, не знаю.
старый софт не запустить
Для запуска приложений x86_64 на ARM есть Rosetta 2. Ранее для запуска приложений PowerPC на x86 у них была Rosetta.
Почти не пользовался макосями и их софтом - насколько розетты действительно хороши? Это что-то типа Wine или лучше?
Но насколько понял они этот слой совместимости выкидывают через несколько версий после смены архитектуры.
А что было при переходе m68k -> PowerPC ?
они этот слой совместимости выкидывают через несколько версий после смены архитектуры
Rosetta 2 они представили для Big Sur в 2020 году и удалят в macOS 28 в 2027 году. Видимо, когда полностью прекратят поддержку старого x86-железа.
Rosetta 1 была представлена для OS X Tiger в 2006 году, а удалена в OS X Lion в 2011 году.
А что было при переходе m68k -> PowerPC ?
Тогда они выкатили аналогичное решение Mac 68k Emulator. Что интересно, первая версия системы с поддержкой PowerPC — System 7.1.2 — фактически только на 10-15% была с нативными инструкциями PowerPC, а остальное работало через эмуляцию. Разработчики приложений так же могли собрать "fat binaries", которые под обе платформы работают.
Так что у Apple подобная миграция вполне обкатана за 30 лет.
А что было при переходе m68k -> PowerPC ?
Fat Applications. Это такой хитрный бинарник, в котором было два исполнимых модуля, каждый под свою архитектуру. Причем вроде как старые ОСи могли его запускать без лишних телодвижений. Обязанность сделать такой бинарник возлагалась на авторов программы.
На каком-то этапе Microsoft сбилась с курса
Что значит сбились? А до этого их ОС не тормозили, не глючили и синих экранов не было с кучей вирусов всяких и уязвимостей?
На C# в Forms окно произвольной формы делается элементарно, в несколько строк буквально (если не заморачиваться отрисовками "правильных" границ, если заморачиваться - всё равно проще, поскольку работают все механизмы отлова оконных событий), причём это настоящее окно, не игры с прозрачностью... В своё время строил их и с помощью Win32 на С++, но там много писанины было.
Оконную процедуру можно не перехватывать - это рудимент от экспериментов. Просто на OnResize строится Region, который присваивается соответствующему свойству формы. Ну и в Main проделывается та же операция, только снаружи формы - чтобы задать Region при старте...
Это точно такой же подход с установкой региона, что и в статье. Только у вас кода больше
Весь код - это создание региона... Просто он тут состоит из трёх эллипсов, объединенных в фигуру "кольцо+внутренний эллипс", а на OnResize он пересчитывается под размеры... Ну и в C# проще, потому что там все потроха завернуты в фреймворке...
Ну так о том и речь. В статье именно об этом (о регионе) и пишут. Только на шарпе кода больше у вас (речь не о рисовании эллипсов), а о написанном отдельно цикле обработки сообщений.
Я позже написал (позже, так как время редактирования закончилось к тому моменту), что override оконной функции - рудимент, оставшийся от экспериментов... Так что кода там меньше, пожалуй, чем в простом получении региона... Собственно, мой комментарий о том, что у меня нет особой ностальгии по Win32, поскольку существующий инструментарий вполне позволяет решать подобные задачи...
А количество кода в Win32, необходимое собственно для построения окна было довольно большим - (сначала же надо сам оконный handle получить, чтобы ему потом уже регион присвоить). - заполнить структуру для оконного класса, написать минимальную оконную функцию (ЕМНИП), зарегистрировать класс, потом уже получить handle, вызовом CreateWindow... Морока, в общем...
Меньше чем где? Это winapi и есть. Это не возможности C#. HRGN и SetWindowRgn. Больше ничего не нужно.
Ну а так, нет, С# кода нужно больше для нормального решения, т.е. не через регион, а через слоистые окна.
Например, для такого:
Здесь ни одной строчки кода нет, кроме обработки движения мыши (там 3 строчки). И да, это кроссплатформенное решение.
Win32 API и ностальгия по окнам странной формы