Comments: |
From: | phantom |
Date: | September 8th, 2021 - 04:11 pm |
---|
| | | (Link) |
|
Гыгыгы, боты с щенячьими глазками.
From: | phantom |
Date: | September 8th, 2021 - 04:23 pm |
---|
| | | (Link) |
|
Вообще, я думал, чтобы сертификаты проверять в либах, это надо ещё постараться. Вот, к примеру, что в либе рэкета пишут:
Beware: By default, "https" scheme handling does not verify a server’s certificate (i.e., it’s equivalent of clicking through a browser’s warnings), so communication is safe, but the identity of the server is not verified. To validate the server’s certificate, set current-https-protocol to 'secure or a context created with ssl-secure-client-context.
То есть, дебилы-ботоводы какие-то фреймворки уже пользуют, которые по дефолту браузерное поведение эмулируют. Дефолтных "правильных" браузеров, как один парень тут в фифе выразился, не будем показывать пальцем, бггг.
| From: | ketmar |
Date: | September 8th, 2021 - 04:29 pm |
---|
| | | (Link) |
|
ну дык нодожысы и прочую такую же говнину.
From: | phantom |
Date: | September 8th, 2021 - 04:38 pm |
---|
| | | (Link) |
|
Ага, представляю я эту картину... хипстер-дисраптер, сидя в хакерспейс, через эппловский лаптоп (бггг)... поднимает тоннель на АВС, там поднимает докер, кубернет, в них электрон хуетрон, ноджс, хедлесс сервер... дарт и флаттер (позавчера услышал эти имена - new!), и очень красиво фулл-стечно и скалабельно... пишет бота! Бгггг.
Я все модные имена, которые знал, тут перечислил.
Кстати; тебя, наверное, это уже давно не волнует, но я вспомнил, как ты писал про gtk3, что там упоротые дегенераты грохнули темы, потому что темы должен задавать window manager и они везде должны быть одинаковые, а то некрасиво!; или про что-то ещё ты ругался в третьей; ну так вот, прогресс не стоит на месте, он уверен в завтрашнем дне: в gtk4 убрали GtkWindow::set_position. причем диалог совершенно шикарный, его так больно читать, что даже приятно: https://discourse.gnome.org/t/how-to-center-gtkwindows-in-gtk4/3112человек спросил, как ему окно посередине поставить, а ему вежливо и снисходительно объяснили, что на самом деле это никому никогда не бывает нужно, а только кажется, что нужно
From: | (Anonymous) |
Date: | September 9th, 2021 - 04:55 am |
---|
| | | (Link) |
|
Редкий случай, когда дебилы правы. Я бы ещё все эти хинты про декорации, прилипание к днищу и прочее выбросил нахуй. Мы с моим WM сами, блять, решим, в каком углу экрана вашу уродскую аппликуху показывать. Правда, CSD тоже надо выкинуть.
From: | (Anonymous) |
Date: | September 9th, 2021 - 04:57 am |
---|
| | | (Link) |
|
Вот только непонятно, почему эта мудотня ноет про not the toolkit's job, но при этом декорирование у них toolkit's job.
| From: | ketmar |
Date: | September 9th, 2021 - 09:40 am |
---|
| | | (Link) |
|
ну, вот таким дегенератам точно не нужно, у них же в черепе киз: One of the things I’ve come to rely on while working is applications remembering where they were last time I used them. With three monitors, it’s essential. Otherwise, I spend far too much time searching across an expanse of screens to find that dialog box I just opened. This is one of the reasons I keep rejecting Linux as an OS.
а авторы гтк — как верно сказал анон — в кои-то веки сделали что-то правильное. у WM есть хинты, которые указывают логический тип окна. вот задача кодира — поставить хинт и уебать в туман вместе со своими гипергениальными идеями про позиционирование окон. мой WM всё равно лучше знает. в том числе он в курсе, что делать с попапами, контекстными меню, тулбарами, диалогами и прочим хламом — если софт корректно помечает их тип и принадлежность.
Не согласен совершенно; вернее, я был изначально с доводами по ссылке не согласен частично, но наблюдая упертость там же, не согласен совершенно, конечно. Смотри. Я пишу программу для себя, эмуляцию некоторой физической задачи. Я её сейчас разрабатываю, поэтому запускаю её 20 раз в час. Мне неудобно косить глаза в левый нижний угол каждый раз, и перетаскивать её в центр 20 раз в час. А тем более неудобно, если она по экрану скачет, потому что пристрастия у WM меняются. Да, было бы круто, если бы я мог сказать WM "ставь это окно в центр и не выебуйся" (и заодно размер выставить тоже в WM). Но даже с размером уже не так очевидно, потому что по мере разработки оптимальный размер для разглядывания деталей может меняться. Более того, высказывание WM, где я хочу окно и какого размера - это неоднородное действие с написанием программы. А тут я просто пишу set_position(Gtk::WIN_POS_CENTER). Для себя, ага. Когда и если я буду это публиковать, это будет уже другая программа, и ей в себе этот код тащить будет уже ни к чему, пользователю лучше знать, где ему окно удобнее. Но убрать строчку это не проблема. Забавным образом, компромисс давно найден и проблема решена, в случае размера (что, кстати, меня просветлило): там не set_size, а set_size_request (что, понятно, лингвистическая проблема по сути, потому что окно все равно раскладывает на экране WM). Так почему нельзя сделать set_position_request? А со стороны WM, если он не тайловый, дать две возможности на приложение (управляемые конечным пользователем, типа галочки): позволить приложению раскладывать себя на экране, и отключить ему эту возможность. Называется гибкость. Потому что, кстати, бывают огромные инженерные интерфейсы, продуманные, как ни странно, настоящими дизайнерами, а не дезигнерами ( https://normandoors.tumblr.com/), и не сломать это WM у него должен быть искусственный интеллект на месте железяки с тремя if'ами. Что определенные тайлеры понимают, и у них есть возможность дать приложению спокойно вывесить все свои окошки в бешеном количестве (например, у gimp или Lazarus) - что, конечно, неудобный компромисс для человека, который тайлерами привык пользоваться, но не такой неудобный, как когда эти внезапно возникающие окошки засовываются неизвестно куда тайлером в ячейку 1px x 100px. Мораль у этой длинной телеги такая, конечно: кроме правил бывают и исключения (например, Linux на рынке OS), и не надо перекрывать им кислород. И минимораль даже более важная: на самом деле там по ссылке доводы врушные, и они изнасилованы Wayland'ом; а вот почему у Wayland'а все так (то есть можно запросить размер окна, но нельзя - позицию) - это отдельная опера, ответ на которую я пока и не знаю (но очень интересно).
| From: | ketmar |
Date: | September 9th, 2021 - 11:30 am |
---|
| | | (Link) |
|
я как-то всё ещё не вижу проблемы. во-первых, почему твой вм не способен запомнить положение (и, если надо, размер) окна? почему он не способен запоминать их каждый раз по закрытию? мой древний FluxBox это умеет, и умел не один десяток лет. не вижу ни одной причины решать проблемы дефективного WM при помощи хаков в коде приложения.
(флюкс, кстати, спокойно игнорирует попытки софта выёбываться с расположением окон, если я прибил их окна гвоздями. но я предпочитаю, чтобы софт просто изначально не выёбывался.)
а если у какой-то софтины реально интерфейс с кучей окон, и там надо жёстко контролировать расположение, иначе всё поломается — то ей прямая дорога в MDI, и управление своими подокнами вручную. и, конечно, для неё никогда не стоит использовать гробтк (как, впрочем, и для любого другого софта, но для такого особенно).
и да, если тебе всё ещё нужен такой хак — ну так прямое обращение к API графической подсистемы никто не отменял. хак и есть хак, он не должен быть простой в использовании. ;-)
как-то так с моей точки зрения.
В смысле "не вижу проблемы"? Я же описал, что я делаю. Да, я мог бы ещё добавить libwnck (который, кстати, не работает под Wayland), но я давно уже туда не лазил, и это некоторая потеря времени. Мне проще откатиться на gtk 3, тем более, что это одна строчка в CMake. Нет, мой WM (кеды) почему-то не в состоянии запомнить, и кидает окно постоянно по экрану. Теперь, когда ты это сказал, я конечно, нагуглил, и вроде бы это можно сделать ( https://www.dedoimedo.com/computers/plasma-window-position.html - надеюсь, это ещё актуально в контексте постоянного улучшения). Но опять же: вот я меняю дефолтный размер окна, как WM догадается, что нужно сохранять нужно не координаты левого верхнего угла, а координаты центра окна? Теоретически, это должна быть опция в той же настройке по ссылке, но её там нет. Давай я ещё раз все-таки объясню, что мне не нравится (а не "что я не в состоянии сделать при приложении какого-то количества усилий, потому что это с т.з. кого-то идеологически правильно"): вот есть актор, разработчик приложения. Есть такая категория разработчиков, которые делают некоторые приложения исключительно для себя. Мне кажется неправильным не позволять им делать со своими окнами все, что они захотят, и объяснять им, что им на самом деле этого делать не хочется. Особенно, если причина эта врушная: gtk в каком-то смысле __вынудили__ так сделать, и они это вынуждение перекладывают вниз. То есть use cases: а) я пишу приложение для себя, я хочу делать с его окнами все что захочу б) если пользователь ставит приложение, оно делает с окнами чего захочет, а пользователю это не нравится, он: б1) пишет автору приложения, чо за хуйня [и автор не втирает пользователю, что ему, пользователю - а не автору, на самом деле так удобнее, только он ещё не въехал, что это так - а либо добавляет опцию, либо говорит, что ему лень] б2) сносит приложение нахуй и ставит другое Потому что даже если что-то можно настроить в WM, это все равно намного дольше; а хак это грязь и нехорошо и потеря времени, зачем мне это. Потом, хинты, про которые ты писал комментарием выше: мне нравятся хинты! Ведь set_position_request - это тоже хинт! (кстати, неплохо было бы ещё в процентах от экрана, чтобы "на внешнем мониторе выглядело так же"). Но только эти хинты же должны быть унифицированы среди WM, иначе каюк. А ты, кстати, можешь объяснить, что за ебанина в Wayland с surface и почему там нельзя выставить позицию у окна, но у surface можно, поэтому предлагают workaround по созданию своего surface и т.д. и т.п? Но объяснение "в gtk это сделали правильно, потому что его не надо использовать" мне, конечно, нравится - только с точки зрения гномоуебка по ссылке это overreaction. Я уже было переехал на copperspice, но он сука не собирается под arch.
| From: | ketmar |
Date: | September 9th, 2021 - 12:17 pm |
---|
| | | (Link) |
|
>Есть такая категория разработчиков, которые делают некоторые приложения >исключительно для себя. и какая проблема исключительно для себя напрямую сделать что надо через API оконной подсистемы?
>Потому что даже если что-то можно настроить в WM, это все равно намного дольше ну, беда, не надо пользоваться дефективными WM тогда, ящитаю.
>в Wayland знать не знаю, не интересуюсь, не установлено, и не собираюсь интересоваться и устанавливать. оно defective by design, и мне не нужно.
>вот я меняю дефолтный размер окна, как WM догадается, что нужно сохранять нужно не >координаты левого верхнего угла, а координаты центра окна? а зачем ему это знать? он запоминает размер и положение. вот как поменял, закрыл — оно в следующий раз открылось точно там же, с теми же размерами. ну, то есть, так делает WM здорового человека, например.
вообще-то, в X11 ещё есть такая штука, как window gravity, но авторы тулкитов обычно дегенераты, и до этого места в документации не дочитали.
> и какая проблема исключительно для себя напрямую сделать что надо через API оконной подсистемы?
блин, ну ты действительно не понимаешь, что это дольше?
> ну, беда, не надо пользоваться дефективными WM тогда, ящитаю.
это __в любом случае дольше__. ну то есть да, я посмотрел и теперь пользуюсь, в кедах это удобно и там много свойств можно настроить, например, нахождение поверх, что мне особенно важно; и я рад, что этому научился; но это все равно надо кликать мышкой, а не добавить одну строчку в программу.
> точно там же, с теми же размерами.
аргх! мне нужен размер теперь новый, 640x480, я его могу выставить окну руками, конечно, в приличном WM, но это все равно дольше, чем добавить одну строчку в программу (вернее, она эта строчка уже есть, нужно только числа поменять - а ещё они могут динамически вычисляться в зависимости от числа объектов в окне, и меняться в ходе работы программы).
> вообще-то, в X11 ещё есть такая штука, как window gravity, но авторы тулкитов обычно дегенераты, и до этого места в документации не дочитали.
какой ещё X11, ты на Марсе живешь? тебе же там английским по белому написали: существует только Wayland, гном любит Wayland, gtk любит гном.
то есть в нем может быть тоже это существует, но авторы тулкитов дегенераты и ещё не дочитали и заранее знают, как пользователю нужнее.
| From: | ketmar |
Date: | September 9th, 2021 - 12:34 pm |
---|
| | | (Link) |
|
>блин, ну ты действительно не понимаешь, что это дольше? нет, не понимаю. потому что мне такой код вообще никогда писать не надо, у меня для этого WM есть, где в несколько кликов всё Просто Работает. а ты настаиваешь на усложнении своей жизни зачем-то — ну, я тебе и говорю, что без проблем, усложняй, если хочешь.
>но это все равно надо кликать мышкой, а не добавить одну строчку в программу. оно даже в кейбинды не умеет? бида. для включения запоминаний мне надо примерно семь нажатий. значительно меньше, чем для написания этой самой строчки. и да, двигать/ресайзить окно с клавиатуры я тоже могу. но обычно мышью проще, и тогда не так сложно и кликнуть по заголовку окна, да выбрать из меню нужные пункты.
нет, всё ещё не вижу, как это «в любом случае дольше».
>какой ещё X11, ты на Марсе живешь? тебе же там английским по белому написали а мы разве не обсуждаем всю ситуацию в целом, пользуясь гробтк как исходной точкой? про гробтк я уже говорил неоднократно, что использовать его не надо ни в каком случае; и совершенно неважно, что там добавили или убрали. если уж лениво самому написать уй (камон, это совсем несложно), то лучше взять тогда какой-нибудь FLTK уже. тоже корявая херота, но всяко получше.
> нет, всё ещё не вижу, как это «в любом случае дольше».
я же написал кейс, а ты его не заметил. ещё раз: я пишу программу, меняю какие-то её внутренние характеристики, от этого меняется её оптимальный размер (который вычисляется внутри), и я всегда хочу окно в центре, ровненько.
а теперь, внимание, вопрос: сможет ли это твой FluxBox сделать быстрее? У меня в gtk 3 это, повторюсь ещё раз, одна строчка: set_position(Gtk::WIN_POS_CENTER) - вот они хинты, твои любимые хинты, нет? - и я её не меняю вообще. И другая строчка, где я запрашиваю (переменный) размер.
> лениво самому написать уй
да, мне лениво. потому что я начинал это делать (потому что все тулкиты говно), и где-то в середине (начала) меня обламывало, очень много возни, чтобы не выглядело уебищно. Основной геморрой ещё с layouts, я в процессе разработки __правильной математической теории layout__, но она не окончена ещё; FLTK выглядит уебищно.
gtk, Qt и Copperspice не выглядят (настолько) уебищно, потому что их сотни лет вылизывали специально обученные пидарасы; но вот gtk срет мне в штаны (и там, да, оказывается, нет аналога QMDIArea, убивать-убивать-убивать, придется самому писать), в Qt омерзительный богохульный moc, а Copperspice не компилируется (что я сейчас ровно чиню); кошмар, ужас, бедствие!
Я, наверное, по итогам gtk 3 форкну назло вам, угнетателям.
| From: | ketmar |
Date: | September 9th, 2021 - 01:38 pm |
---|
| | | (Link) |
|
>Основной геморрой ещё с layouts в 99% случаев хватает простейшего flexbox. который один раз написал для абстрактных прямоугольников — и дальше просто с собой носишь.
>очень много возни, чтобы не выглядело уебищно делаем вид как в стандартном WindowMaker — и никаких проблем. ;-)
>я же написал кейс, а ты его не заметил я его не понял. я действительно не понимаю, как, когда и зачем такое может понадобиться, и почему — если уже надо — не сделать один раз библиотеку для такой херни. ;-)
но вообще-то да, флюкс может — и центрировать, и прижимать к углам, и устанавливать размеры в процентах от размера work area. окей, там будет две, кажется, строчки: класс окна и команда «центрировай». всё ещё не понимаю, зачем мусорить в коде тем, что без проблем делается внешней тулзовиной, при этом универсально.
>FLTK выглядит уебищно по-моему, нормально выглядит. там даже никому не нужные темы есть.
> как в стандартном WindowMaker да блин, вот стандартный WindowMaker - тут же дофига возни над красивостями - и тенёчки, и плавные линии в табах, тут темненькое, там беленькое, и пупочка трехмерная на скроллбаре.
| From: | ketmar |
Date: | September 9th, 2021 - 02:07 pm |
---|
| | | (Link) |
|
да где там возня-то? четыре цвета, несколько прямых линий — и всё красиво. санс пупочка, которая делается простым пиксмапом. один из самых простых для рендера видов (я делал, я говорю исходя из практического опыта), и при этом отлично выглядит.
| From: | ketmar |
Date: | September 9th, 2021 - 02:07 pm |
---|
| | | (Link) |
|
минус плавные линии — которые я не делал вместе с табами, потому что табы не нужны.
Ну вот о чем я и говорю - кому-то не нужны, кому-то нужны. Зачем форсировать минимальный внешний вид, который правильный с точки зрения кого-то, если можно предоставить всем возможность сделать так, как удобно им?
Извини, что продолжаю, конечно - но эта функциональность же уже была, зачем убирать?
| From: | ketmar |
Date: | September 9th, 2021 - 02:30 pm |
---|
| | | (Link) |
|
не знаю, зачем конкретно им, но если взять абстрактного меня, например, то возможная причина такая, например: «мне не надо, и я заебался маинтаинить».
| From: | ketmar |
Date: | September 9th, 2021 - 05:03 pm |
---|
| | | (Link) |
|
>функциональность выкидывают огромными кусками и пользователи воют это, в принципе, всегда был modus operandi разработчиков гробтк.
Кстати, вот что gtk-евангелисты думают про MDI: https://stackoverflow.com/questions/55317935/mdi-form-in-monodevelop-gtk-sharpсобственно, ровно та же логика (хотя тут она, видимо, не создателями пропонируется, а агитатором): мы это не сделали/выкинули, потому что на самом деле оно вам не нужно, вы ещё спасибо нам потом скажете. а что в MDI Windows-specific, кстати? Впрочем, вот тут, наоборот, MDI ругают с "общих позиций": https://stackoverflow.com/questions/55317935/mdi-form-in-monodevelop-gtk-sharpпри этом в Qt оно есть, в wx есть, даже в FLTK есть. но gtk лучше знает ужасно обидно, мне и по внешнему виду, и по внутренней идеологии gtk гораздо больше нравится всего остального
| From: | ketmar |
Date: | September 9th, 2021 - 08:33 pm |
---|
| | | (Link) |
|
да никто MDI не любит. и, в общем, за дело: потому что почти никто его использовать не умеет правильно. ну, и держать внутри библиотеки, по сути, реализацию WM — тоже удовольствие то ещё. и я бы выкинул. потому что если оно таки надо — то или оно не надо, или тот, кому надо, уже давно созрел писать свой уй-тулкит.
В keybind'ы оно умеет, кстати, это ты хорошую идею подал; тем более, что plasma скриптабельна, и её можно конфигурировать программно. Её главный недостаток - это то, что её непрерывно улучшают, в результате все время все переезжает из одного места в другое.
Но все равно одна строчка в программе это проще. А ещё проще, я вот подумал - сделать базовый класс ExperimentalWindow, у которого в конструкторе set_position, а потом от него наследоваться. Причем в IDE (nvim/emacs) надо будет только нажать E, а дальше оно само мне подскажет.
Неужели и этого можно проще сделать во FluxBox?
| From: | ketmar |
Date: | September 9th, 2021 - 01:39 pm |
---|
| | | (Link) |
|
можно. парой строчек в конфиге — что точно меньше, чем городить базовый класс, да ещё и совершенно не зависит от того, какой ты язык используешь для написания софта. ;-)
Ну, такое. Я напомню, моя точка зрения такая - нужно предоставить в тулките максимальную свободу для разработчика - чтобы он хоть круглые мог окна делать, хоть зюобразные, и располагать их на экране хоть разорванными на десять частей. Соответственно, дальше уже на совести разработчика - если он делает так, что всем неудобно, то просто не будут использовать его тулзу. Но важно сделать, чтобы у разработчика была возможность приобрести полный контроль, и удобно, когда это все внутри тулкита. Зюобразное окно в gtk можно сделать (вернее, можно было раньше - не знаю, как сейчас: https://github.com/GNOME/gtk/tree/gtk-2-24/examples/wheelbarrow ), и это хорошо; соответственно, неплохо бы ему ещё и уметь зюобразно располагаться по-всякому.
| From: | ketmar |
Date: | September 9th, 2021 - 01:59 pm |
---|
| | | (Link) |
|
а я придерживаюсь мнения, что можно, но не обязательно.
думаю, где-то на этой точке мы можем agree to disagree. | |