Опубликованы результаты проверки эффективности...Подробнее: https://www.opennet.me/opennews/art.shtml?num=60952
Серьезно подошли к вопросу измерений. Дёшево и сердито. Это не камерой снимать устройство ввода одновременно с экраном, а потом разбирать видеоряд и получить бóльшую погрешность. Жаль, пока не понятно, сколько потребуется сенсоров, что бы замерять инпут-лаг в игрушках.
Бесполезное писькомерство.
Время отклика очень важно для пользователя. Касательно терминала - вопрос спорный. Но если занялись, это хорошо.
> Время отклика очень важно для пользователя. Касательно терминала - вопрос спорный. Но
> если занялись, это хорошо.Тебе правдо важно 20 или 40 мс ?
>> Время отклика очень важно для пользователя. Касательно терминала - вопрос спорный. Но
>> если занялись, это хорошо.
> Тебе правдо важно 20 или 40 мс ?Важно. Со времён Спектрума у меня неприязнь к недостаточной отзывчивости.
Конечно, за 40 мс успеваю нажать и отпустить из-за чего на механических клавиатурах, где цикл занимает чуть дольше, не получается набирать, например, :wq (SHIFT_UP ':' SHIFT_DOWN 'w' 'q', не успевает отрабатывать SHIFT_DOWN)
А этот терминал Alacritty оказался весьма крут.
С другой стороны, не удивительно, тк он написан на Расте.
Вот тебе скорость и безопасность в одном флаконе)
Да просто этот алла-кретин работает в линуксе, написанном на C, дергает сисколы которые обрабатываются ядром написанном на C, и запущен в гноме, написанном на C
Я придумал! Чтобы построить идеальное общество детей в школах надо учить разговаривать на C!
> Я придумал! Чтобы построить идеальное общество детей в школах надо учить разговаривать
> на C!А как ты будешь бороться с тем, что дети выходят за границы и начинаю там творить какую-то дичь?
Пагади-ка?! Возможно в одной взятой стране такие чудовищные экперементы уже проводили!Я уже молчу про попытки двойного выкидывания ненужных объектов или использование мусора?
Я думаю обучение школьников СИ надо рассматривать как форму пыток!
Согласен!
Предлагаю учить Лисп.
Только когда научатся говорить на Ассембелре! Учить разговаривать на Ассемблере с первого класса!
Руки прочь от наших детей!
> и обгоняет тормозной гном, написанный на С, с его эмуляторами, написанными на C, которые так же работают в линуксеПофиксил, не благодари.
> работает в линуксе, написанном на C, дергает сисколы которые обрабатываются ядромТ.е. ты вендузятник с WSL ... или просто очередной "эксперд опеннета"?
Просто ты днище не читал нормальную статью на лосбстере где аллакрити и саблайм рвёт все терминалы
Какую статью?
xst безопаснее и быстрее
7ms задержка на frame и у вас сверху ещё столько же?Жесть. Почему в следующий frame нельзя успеть?
> Console (GTK 4)
> GNOME 46Не нужно, когда есть swaywm и foot
Я всю жизнь пользуюсь rxvt и не понимаю, зачем что-то в этом менять?
уууу, не отрисовываешь на gpu вывод README.md? ну ты и луддит.
бейте его, насмехайтесь над ним.
А чем хтерм не устроил то???
> А чем хтерм не устроил то???я не он, но отвечу за него как юзер urxvt'a: расширениями и документацией. свой плагин пишется за 10 минут.
rxvt и urxvt это разные программы, они даже на разных языках написаны (первый на C, второй на C++)
> rxvt и urxvt это разные программы, они даже на разных языках написаны (первый на C, второй на C++)Нет, оба на Си
> НетСам знаешь кого ответ.
Из https://github.com/exg/rxvt-unicode/blob/main/src/rxvttoolkit.C:
template<class T>
void refcache<T>::put (T *obj)
{
if (!obj)
return;if (!--obj->referenced)
{
this->erase (find (this->begin (), this->end (), obj));
delete obj;
}
}template<class T>
void refcache<T>::clear ()
{
while (this->size ())
put (*this->begin ());
}
Из https://github.com/exg/rxvt-unicode/blob/main/src/scrollbar.h:private:
// update style dependent data
void update_data ();// scrollbar-next.C
int show_next (int);
> Сам знаешь кого ответ.Ой, все!
Ой, да что вы спорите!rxvt? urxvt?
Это же теорема Эскобара, шо одно @@@, что другое @@@.
> Ой, да что вы спорите!
> rxvt? urxvt?
> Это же теорема Эскобара, шо одно @@@, что другое @@@.urxvt лучший, анон. просто если ты не терминальный з@droт, проходи мимо, смузи вон там, присасывайся и не мешай.
> urxvt лучший, анон. просто если ты не терминальный з@droт, проходи мимо, смузи вон там, присасывайся и не мешай.А не прифигел ли ты? Твой urxvt всасывает rxvt по всем параметрам!
Там чистый си, а не terrible, unmaintainable garbage как в твоем urxvt. Работает всегда и везде.
Так что иди компиляй свои плюсы, смузихлебище.
> rxvt и urxvt это разные программы, они даже на разных языках написаны
> (первый на C, второй на C++)ну да, мой косяк. допустил что тредстартер пользуется все же актуальным форком, а не оригинальной версией.
> Я всю жизнь пользуюсь rxvtИ как вам? Баг с мусорными escape- последовательностями в tmux'е уже починили? А артефакты рендеринга шрифтов?
Я другой аноним, но тоже стало интересно про tmux. Проверил - всё ок
>> Я всю жизнь пользуюсь rxvt
> И как вам? Баг с мусорными escape- последовательностями в tmux'е уже починили?
> А артефакты рендеринга шрифтов?как воспроизвести? пользуюсь screen'ом и не встречал такого, но заведу и tmux если ты не балабол.
>> Баг с мусорными escape- последовательностями в tmux'еhttps://www.reddit.com/r/openbsd/comments/18cxwdy/tmux_causi.../
>> А артефакты рендеринга шрифтов
хз как, иногда появляются в виде обрезков предыдущего текста при скроллинге в "полноэкранных" текстовых приложениях. наблюдал и на ubuntu, и на fedora
* скролинг том в смысле, когда запущенная программа сама экран перерисовывает, а не просто листание буфера вывода
удалось найти свой старый скришнот c артефактами рендеригна
>>> Баг с мусорными escape- последовательностями в tmux'е
> https://www.reddit.com/r/openbsd/comments/18cxwdy/tmux_causi.../пробовал накладывать патч из треда?
https://www.reddit.com/r/openbsd/comments/18cxwdy/comment/kc.../решает проблему?
>>> А артефакты рендеринга шрифтов
> хз как, иногда появляются в виде обрезков предыдущего текста при скроллинге в
> "полноэкранных" текстовых приложениях. наблюдал и на ubuntu, и на fedoraтоже tmux?
> пробовал накладывать патч из треда?
> https://www.reddit.com/r/openbsd/comments/18cxwdy/comment/kc.../
> решает проблему?Да, применял к urxvt v9.31 на Fedora 39, помогло.
> тоже tmux?
Vim, а также самописная прога на ncurses
>> пробовал накладывать патч из треда?
>> https://www.reddit.com/r/openbsd/comments/18cxwdy/comment/kc.../
>> решает проблему?
> Да, применял к urxvt v9.31 на Fedora 39, помогло.так вот, этот патч закрывает этот
https://github.com/tmux/tmux/issues/3582
ишью.Как видишь, дело не в urxvt. Проси прощения у urxvt, дон.
> Как видишь, дело не в urxvtСудя по этим патчам, которые исправили проблему, виноват-таки urxvt
https://github.com/openbsd/ports/tree/master/x11/rxvt-unicod...
Всмысле ты не юзаешь CUDA/OpenCL на GPU для отрисовки вима? Ты больной?
а для вейленд есть rxvt?
Интересно бы было посмотреть на аналогичное сравнение, но с участием не только гномотерминалов, а еще xterm, konsole и т.д.
yakuake же
Ну тогда еще и QTerminal до кучи
И contour.
> yakuake жеТогда уж st.
> а еще xterm, konsole и т.д.И обязательно в т.ч. в иксах без композитного режима. Кажется, gnome с третьей версии так уже не умеет.
а так же aterm и wterm
Оценка влияния оптимизаций в GNOME 46 на эффективность работы эмуляторов терминала
@
реакция на нажатие клавиш в Console и GNOME Terminal снизились до 40 до 12 мс, а в тесте прокрутки в neovim - с 45 до 23 мс.
@
А ТЕПЕРЬ ПРОВЕРЯЕМ KDE и KONSOLE
@
НУЖНАЯ БУКВА РИСУЕТСЯ НА ЭКРАНЕ ЕЩЁ ДО ТОГО, КАК АНОН УСПЕЛ НАЖАТЬ КЛАВИШУ
Не могу понять: это насмешка над GNOME, над KDE, или над обоими сразу? Или в зависимости от предпочтений человека, он увидит то, что ему ближе? Какая-то шутка Шрёдингёра…
Перевожу:
Гном настолько тормозной, что там даже скорость отрисовки в терминале измеряют и радуются что она уменьшилась (заметь, именно уменьшилась, а не исчезла). В то же время в кедах никто даже не задумывался устраивать подобные замеры, т.к. такой проблемы там нет от слова "совсем".
Они просто падают периодически и выглядят отвратительно
оххх, шо падают — то падают
вот буквально вчера упали, когда я планшет уронил 😆
Если только Konsole собран с libastral
когда устал от gtk3+, собрал
vte-0.28.2.tar.xz
и пересобрал всё, что смог, на gtk2.. если вдруг кому нужен по-настоящему отзывчивый терминал на vte..
таки да.
собирал lxterminal (требует vte), а то оно что-то в дебиане с gtk3 собрано. работает норм...
У меня дома и на работе 1050Ti гномовский терминал после последних обновлений тормозят так что даже работать невозможно, причем тормоза исключительно в терминале. Vim превращается в убогое тормозное чмо. Это они всех заболтать так хотят?
> У меня дома и на работе 1050Ti гномовский терминал после последних обновлений
> тормозят так что даже работать невозможно, причем тормоза исключительно в терминале.
> Vim превращается в убогое тормозное чмо. Это они всех заболтать так
> хотят?УМВР, хотя гном последней версии.
Возможно стоит взять линейку и проверить насколько прямые твои руки.
Если они прямы как березки, то придется читать форумы и пердолиться, потому что у лапчатых есть только один путь.
"Работает из коробки" за этим на винду, маскось или хромось.
>>пердолитьсяЭто уместно когда альтернатив нет, а их на Линукс полно, и практически все работают хорошо.
Так, что с подролиться, это без нас.
> Это уместно когда альтернатив нет, а их на Линукс полно, и практически все работают хорошо.Лол, ты это серьезно?
Линукс это когда приходится подбирать счастливую комбинацию, железа, ядра, ДЕ, софта, дров и тд
Или ждать пока кто-то соберет это все в кучу и вупустит свой зверьСД.
На линуксе альтернативы большинстве случаев это нескучные обои и прочее что работает не лучше чем первый вариант.
Серьёзно.
Если задача поработать, то за поковыряться в системе, вместо работы, точно не похвалят.
Кроме хобби, и работы админа, когда цель именно настройка системы.>>Или ждать..
Классический ответ - Вам шашечки, или ехать?
Опускаем крайние случаи решения проблем, типа смены ОС.
Но если есть рабочая альтернатива, работающаая из коробки, или ТОЧНО работающая при настройке по ПРОСТОЙ инструкции, то зачем грызть кактусы.
> Классический ответ - Вам шашечки, или ехать?Жаль, что видеокарты с тысячей CUDA-ядер и процессора с частотой несколько гигагерц не хватает на то, чтобы ехать с шашечками.
Вообще, если кто помнит источник цитаты, это классический выбор между двух стульев.
Для УМВР надо чтобы у тебя как минимум тоже была 1050Ti. У тебя 1050Ti? Или ты поумничать забежал?
выбросьте свою 1050Ti, у меня интеловская встройка - терминал летает.
"Ранее задержки при вводе с клавиатуры в Console и GNOME Termina были ощутимы, что отталкивало многих пользователей"В общем, я как и упомянутые многие пользователи, посмотрел, и переключился на альтернативы.
Отлично работает. Посмотри, нет ли других ошибок в ОС
Нет, других ошибок. Тормоза именно с этой видюхой, на инетловской встройке такой беды не наблюдается.
А драйвер какой?
менять между нуво и нвидиа пробовал?
> Нет, других ошибок. Тормоза именно с этой видюхой, на инетловской встройке такой
> беды не наблюдается.Ну так если проблема в видяхе, то чего гнать на разрабов гнома?
Взял видео от максимально проприетастного производителя, а теперь жалуешься.
urxvt
> У меня дома и на работе 1050Ti4 ядра, 4 гига, игровая видеокарта
Но таки производительнее любой встройки от Intel. Или для vim нужно уже как минимум RTX 4090?
> Но таки производительнее любой встройки от Intel. Или для vim нужно уже
> как минимум RTX 4090?Но таки косячнее любой встройки от intel из-за корявого болоба, а так как карта уже давно не на поддержке, точнее формально на поддержке, а реально большинство улучшений в новых дровах пролетают мимо неё.
> Но таки косячнее любой встройки от intel из-за корявого болобаОх уж эти фантазии из мира розовых поней.
> Ох уж эти фантазии из мира розовых поней.Я с фантазиями о нормальном драйвере для невидии жил с 2012 по 2019 год. Потом плюнул и понял что если нужна нормальная видяха под линукс то надо брать амд.
> что даже работать невозможноВ таком случае, предлагаю альтернативу: отложи клавиатуру и займись чем-нибудь, что тебе под силу, например, подметанием пола.
> Vim превращается в ...
Сразу видно, что ты совсем недавно открыл для себя vim. Он всегда таким был ( ͡~ ͜ʖ ͡°)
>>оптимизации привели к снижению задержек при отрисовке в конфигурациях с GTK 4.Если с гадкими шрифтами ещё и стало бы медленнее, то объяснения, зачем так, потянули бы сказку.
Проверим, как в дистр заедедет. Из-за тормозов при прокрутке и инпут лага перелез на alacritty, но не против вернуться на дефолт, если все будет хорошо. В чем я немного сомневаюсь.
Пользовался разными терминалами, в том числе гном-терминал. Не замечал никаких задержек. О чем речь?
Всё что нужно знать про GNOME разработку.https://felipec.wordpress.com/2024/03/18/stupid-gnome-develo.../
Причём, у них такое в порядке вещей. Уверен, что любой, кто сталкивался с их разработчиками хотя бы пару раз, имеет схожий опыт.
Божечки. Ты серьезно приводишь как аргумент типа, блог которого на 100% состоит из рассказов о том, что все кругом идиоты и забанили его в своих проектах? Который в разделе "о себе" как первый факт -- после имени и того что он девелопер -- указывает что он "anti-woke"? Это же типичный нытик-скандалист. Каждый кто участвовал в проектах знает этот типаж.
> Каждый кто участвовал в проектах знает этот типаж.Конечно. Типичный "непризнанный гений". 99,9% таких выкидывают нафиг примерно сразу ввиду тотальной непригодности к работе.
Именно.
> Который в разделе "о себе" как первый факт -- после имени и того что он девелопер -- указывает что он "anti-woke"Значит, адекватный человек.
>> Который в разделе "о себе" как первый факт -- после имени и того что он девелопер -- указывает что он "anti-woke"
> Значит, адекватный человек.Хм, а давно 3-2-1ы в плохом смысле этого слова стали адекватными?
Хотя после того как питушки ходят в школы за жизнь перетирать и героями называются, то не удивительно.
Ну и дичь ну и драма, я потратил 10 минут своей жизни и еще 10 минут на осознание что я потратил 10 минут своей жизни. Ты мне должен вернуть 20 минут!
>latency tester sends key press events directly over USBUSB не подходит для посылки сообщений клавиатуры и мыши, ибо эта шина не для минимизации латентности предназначена, а для максимизации troughputа. Нужно слать по PS/2. В USB есть интегрированный PS/2, но в тексте сказано USB - значит подразумеваем interrupt-USB-транзакции.
Интересно, звук гонять подходит, а ввод с клавиатуры - нет. Вы уж определитесь там.
Звук идёт большими пакетами через изохронные транзакции.
И даже при этом при использовании ASIO задержка составляет порядка единиц миллисекунд.
Там такая разница, что её даже геймеры не видят. Но терминал, конечно, другое дело.
>геймерыУ них время реакции 300мс, если что, так что, 0.5с плюс, 0.5с минус, едва заметят. А вот, когда работаешь с эмулятором терминала, сразу видно все задержки.
То-то на 144 Гц играть гораздо комфортнее, чем на 60 (а лучше вообще vsync отключить). 300 мс тут вообще не в кассу, это реакция на единовременное событие.
Вряд ли это от частоты обновления. То, что я различаю боковым зрением под 300 фпс, никак не влияет на реакцию и едва ли отличишь, задержка больше или меньше. Она может быть, но сколько, когда она скачет, непонятно. У глаза лаг на аппаратном уровне и он даже не постоянный и равномерный для каждого представителя.
То, что вы называете реакцией, это _мышечная_ реакция. А реакция зрения почти мгновенная, и лаг между нажатием клавиши и изменением изображения оно очень даже видит. Это вот тот самый инпут-лаг, которым в первую очередь мы интересуемся, когда покупаем телевизор или проектор, имея в виду игры. А многим (вот лично мне точно) уже и с vsync иногда играть ватно.
Ну, я много играл в игры на реакцию, в районе 35-50мс задержка уже ощущалась (1 кадр 17мс). Секрет быстрой реакции в том, чтобы не вмешиваться головным мозгом и действовать на рефлексах. А вот если начать думать, то время реакции улетает в космос. И головной мозг просто не осознаёт задержки в норме, так что игорьки это просто мнительная аудитория. С мониторами всё дело в качестве матрицы, а не в рефрешрейте как таковом (прошлые кадры оставляют след) и определённые параметры, такие как цветопередача и динамическая контрастность, имеют большее значение. И да, если просто поменять рефрешрейт на мониторе, он начинает работать совсем по-другому (в частности, компенсационные технологии), поэтому взять и сравнить не получится.
Матрица либо может переключаться с заданной частотой, либо нет. Остальное всю нюансы.
Качество матрицы для геймеров глубоко вторично, ещё лет пять назад (до появления быстрых IPS и VA) киберкотлеты поголовно на TN сидели.
Рефрешрейт для игр ещё на ЭЛТ разгоняли, где и переключение мгновенное, и никакого остаточного изображения нет в помине.
У геймеров время реакции как раз будет поболее твоего
Подключаем клавиатуру по USB, зажимаем клавишу и ждём пускай 10 секунд. По прошествию 10 секунд считаем сколько символов пуспело появиэся в текством ребакторе. То же самое проделываем с.кьавиатуиой подключнной по PS/2. Видим разницу и что PS/2 лучше.
Если у вас USB-порт не успевает обрабатывать 30 символов в секунду (стандартная максимальная скорость автоповтора), материнку в ремонт срочно.
Но для них зачемто продают спец. клавиатуры с увеличенной частотой опроса. А ещё, увеличить частоту опроса USB порта ккоторо?у подкбючена мышка, то пользоваться ею становится приятнее а точность вьзтастает.
> USB не подходит для посылки сообщений клавиатуры и мыши, ибо эта шина не для минимизации латентности предназначена, а для максимизации troughputа. Нужно слать по PS/2. В USB есть интегрированный PS/2, но в тексте сказано USB - значит подразумеваем interrupt-USB-транзакции.Я, конечно, не эксперт, но по-моему, миллиарды пользователей USB-клавиатур и мышей как-то не особо страдают от латентности. Как им теперь жить после твоего открытия я даже и не знаю.
Не мешайте людям фантазировать, что при получении прерывания от PS/2 система бросается, распихивая всех. внеочерёдно выводить символ в терминал.
К мышам вообще не относится, стандартная частота опроса USB — 125 Гц, но при необходимости увеличивается до 1000, а вот на PS/2 по умолчанию 100, и выше 200 Гц не прыгнешь.
Вообще-то при из зависания по определённым причинам, например при вылете в своп, вылезти за вменяемое время можно только с ps/2.
Не шаришь. Проблема со старым USB заключается в невозможности работать по событийному принципу, т.е. устройство ввода не может само инициировать общение с хостом, хост сам должен опрашивать устройства. Из-за чего и появляются задержки. У PS/2 такой проблемы нет. В USB-3 эту проблему починили, но скорее всего не взлетит для устройств ввода т.к. слишком сложная реализация на стороне устройства
у них что до сих пор были проблемы с терминалом? что ж там за модные разработчики такие, что уже 2 мажорных релиза не могут сделать как было в гноме 2 у немодных старых легаси дедов.
гноме 2 всё было относительно просто и поэтому относительно быстро работало. Сейчас там столько говнокода, что его понять и разобраться что же там происходит, очень сложно, думается что они сами путаются, костыляют и т.д. поэтому всё тормозит глючит и т.д.
> поэтому всё тормозит глючит и т.дДа у тебя под столом, небось, динозавр из палеолита пыхтит, а не комп. Собери макулатуру, сдай бyтылки, да купи какой-нить комплект на зеонах с алиэкспресс. Глюки сами собой рассосутся, вот увидишь.
Сравните пинги современных веб-приложений
В дискорде по разделам бегаешь на плюс-минус актуальном железе охреневаешь от того "как так вообще"
А можно мне оконный менеджер, который будет рисовать не медленней, чем NT 4.0?(
Для этого надо графический интерфейс встроить прям в ядро, как в NT 4.0, тогда задержки на переключение контекста сн зятся до минимума и будет быстро
Я вас уверяю, что это не так. Я в свое время когда-то давно загружал линукс с третьим КДЕ и ВЕСА драйвером на ноутбуке с коре дуо и джефорсом 9400, так вот ГУИ был ОЧЕНЬ И ОЧЕНЬ отзывчивым, такой же если не лучше чем у винды старых версий. Я до этого плевался на не отзывчивость ГУИ линуксов и я так же думал, что у линукса никогда не будет отзывчивого интерфейса из-за граф. сервера работающего в пространстве пользователя, но этот случай, а так же другой показал для меня, что тормоза ГУИ в линуксе это из-за ошибок и недоработках в граф. стеке, менеджере памяти и МТРР/ПАТ в ядре.
Ну сейчас переключение видеорежимов в ядре, стало лучше и быстрее
> на ноутбуке с коре дуо и джефорсом 9400Тут многие и сейчас сидят на железе тех лет.
Ничего себе железо. Этого типа должно не хвататть для отрисоски GUI?
И тем не менее, я видел отзывы людей у которых топовое современное железо, а ГУИ не отзывчивый и тормозной, что на интеле, что на амд, что на нвидии.
Дополнительно приведу ещё один мой пример: очень старый, проездом, двух ядерный нетбук с атомом вместо процессора, на котором федора толи 35, толи 36 с гномом хорошо работала - не было такого, чтобы скорость ГУИ вызывала отвращение.
Еще один пример: мой текущий компьютер с Атлоном 5350 и видеокартой RX550 и ГНУ/Линукс Минт толи 20.3, толи 21 версии - ГУИ отзывчивее на дискретной видеокарте, чем на встроенной. При этом на винде 10 разницы между ними нет.
И сейчас можно сделать быстрый gui с рендерингом на vulkan/opengl, проблема в том что все новомодные графические вещи GTK4/QML просто обвешаны мегабайтами анимаций, шейдерами, тенями, сглаживанием и постпроцессингом. ImGui например очень быстрый.
> все новомодные графические вещи GTK4/QML просто обвешаны мегабайтами анимаций, шейдерами, тенями, сглаживанием и постпроцессингом.vulkan/opengl легко могут крутить шейдерами мегабайты анимаций, рисовать тени, сглаживать, и выполнять постпроцессинг. Проблема с gtk/qt в том, что они были зачаты в ту эпоху, когда программисты мерялись тем, кто сможет развесистее иерархию классов запилить, а основным мерилом успешности было "повторное использование кода". Тогда они "повторное использование" понимали в том смысле, что если где-то строка кода написана, то лучше написать 100 строк кода абстракций, чтобы ту строку кода использовать из другого контекста, чем скопипастить эту строку кода в другой контекст.
Это ООП головного мозга, которое приводит к появлению в рантайме объектов, кустистость которых на порядок больше, чем кустистость иерархий классов, в результате банальная попытка обойти объект приводит к тому, что кеши начинают дымиться.
Есть известная мудрость: индайрекция может решить любую проблему программирования, кроме проблемы слишком большого количества уровней индайрекции. (Сорри за "индайрекция", я не знаю как её принято переводить на русский). gtk/qt следуя тому ООП из 90-х, накручивают уровни индайрекции десятилетиями. Это не сегодня началось, 20 лет назад я ковырялся в gtk, пытаясь понять как он работает, но там невозможно доковыряться до дна, лезешь вглубь через бесконечные уровни индайрекции, и к тому моменту когда находишь интересующий тебя кусок кода, ты уже не можешь вспомнить, как ты сюда попал и почему этот кусок кода тебе был интересен. Почему вообще gtk тебе был интересен.
Без ООП проблематично писать более менее вменяемый GUI. Golang биндинг к GTK4 что весь на кодогенерации сделан и там сам автор во многих местах затрудняется давать полные ответы как сделать работу с таблицей или более менее кастомизировать выпадающий список правильно, там везде выходит лапша по виду паскаля или баша, что в итоге у меня вызвало отрыжку. Примерно такие же проблемы и у GTKMM который находится только в режиме поддержки работы, но никак не развивается. Я лично жду carbon lang, но нутром чую что ждать придется еще лет 10. Я уже давно лично убедился что проблема С++ которая отворачивает от него разработчиков это необходимость писать header файлы.
> Я лично жду carbon langТолько не забудь потом пожаловаться, что документации нет, сообщество маленькое и библиотек не хватает.
> Без ООП проблематично писать более менее вменяемый GUI.Если под ООП понимать развесистую иерархию классов, то нет, нет никаких проблем писать вменяемый гуй без развесистых иерархий. Если же, допустим, использование интерфейсов называть "ООП", то тогда да, без таких штук сложно обойтись.
> Golang биндинг к GTK4
> GTKMMБинды по-любому выносят наружу всю сложность низлежащего ООП. И они никак не помогают производительности, потому что идиотские структуры данных ООП кода никуда не деваются.
> Я лично жду carbon lang, но нутром чую что ждать придется еще лет 10.Я бы не ждал)
Т.к carbon-lang#project-status
Carbon Language is currently an experimental project. There is no working compiler or toolchain.
Это конечно исправимо (время + деньги), но в данный момент ситуация такова.А если глянуть их README.md на github com/carbon-language/carbon-lang
Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should.Т.е создатели карбона сами советуют использовать другие языки где можно, а вот где совсем "не можна" - то там использовать его.
icewm
> icewmКогда у тебя калькулятор мощнее, чем комп, но ты все равно хочешь оконный менеджер.
Потихоньку всё возвращается на круги своя, к тормозам терминалов на 300 бод.
Так сейчас чтобы написать хеллоуворлд у тебя скачивается пара гигов всяких зависимостей, прослоек и библиотек.
Если потребности ограничиваются хеллоуворлдами, всякие Tiny C Compiler никто не отменял.
> Если потребности ограничиваются хеллоуворлдами, всякие Tiny C Compiler никто не отменял.Таки сразу видно scrum-мастера по agile-кодингу хеллоувротов ( ͡° ͜ʖ ͡°)
Не понял сарказма. По-моему, очевидную вещь пытался донести: чтобы написать хеллоуворлд, гигабайты зависимостей _не нужны_. Да, гвозди можно выпрямлять гидравлическим прессом, но это не значит, что других вариантов (aka молоток) не осталось.
Окружения для сборки и для исполнения программ сильно различается. Обычно в манифестах обозначается как packages и packages-dev. Для dev нужны линтеры, языковые сервера, анализаторы. Но node_modules и правда весит дохрена. Там же только текст.
Классика гомоведов - Not recommended for new designs or projects.
А смысл, если узкое место все равно не это в современно десктоп линукса, а всякие flathub'ы да snap'ы, плюс сама по себе оболочка тормозная.
Совсем недавно тут писал, что вывод в консольку тормозит. Местные анончики начали меня слюной забрызгивать, мол я с ума сошёл, и это невозможно. А тут только один раунд оптимизации (не первый, и, видимо, не последний) уже увеличение перфы на десятки процентов + снижение задержки в разы. В кедах ситауция лучше, но не сказать чтобы в разы лучше.
Никаких тормозов в Gnome Terminal нет и не было. Лучший терминал вместе с Konsole. А Alacritty не хотят выпускать бинарную сборку для Linux. Почему? Для MacOS/Windows есть.
Есть киношные хацкеры долбящие клаву, это для них наверное :) Думать когда не надо :) Но вот если бы переключение языков ускорили до 10мс было бы да, полезно, бесит.
Современный GNOME это одно большое недоразумение. В дефолте абсолютно неюзабельное толстозадое окружение, которое сделали то ли для сенсорных экранов, то ли для десктопа. Короче окружение для толстолобых приматов.