LINUX.ORG.RU

LXQT - история

 ,


0

1

Склероз заколебал.

  • LXQT - помесь LXDE (GTK) и RazorQt (Qt)
  • RazorQt - наследник… Кого? Точно помню, что автор RazorQt - Petr Vanek. А автор <кого> - то ли серб, то ли болгарин, имени не помню. Идея была в сделать типа macOS, только на Qt. Возможно что-то насчет Aurora, но это не точно. Помогите вспомнить.

Единственное, что нужно знать о LXQT — это глючное убожество, для которого даже звуковой микшер нужно от Xfce ставить. То есть из коробки даже вывод звука не настроить. Там панель задач, есть ворох глюков, если её разместить вверху экрана — под неё залезают часть окон программ, какие-то ложные\неверные срабатывания на нажатия рядом. Тупо тиринг, при том, что жрет ресурсов LXQT не меньше, чем Xfce — повёлся на утверждение «крысам стала жирной, а вот LXQT есть чудо чудное, диво дивное».

luiswoo
()
Ответ на: комментарий от TI_Eugene

Любомир

Да, и сербское и болгарское имя. Не помогло. :)
Но прогресс есть:

имени не помню

Возможно, память вернётся полностью.

dataman ★★★★★
()
Последнее исправление: dataman (всего исправлений: 1)
Ответ на: комментарий от luiswoo

Единственное, что нужно знать о LXQT — это глючное убожество, для которого даже звуковой микшер нужно от Xfce ставить.

А чем не устроил стандартный pavucontrol-qt? Я вот себе ставил kmix, то же не плохой вариант.

Тупо тиринг, при том, что жрет ресурсов LXQT не меньше, чем Xfce — повёлся на утверждение «крысам стала жирной, а вот LXQT есть чудо чудное, диво дивное».

В стандартной поставке LXQt идёт openbox, он работает без композитора, который делает вертикальную синхронизацию и он же добавляет всякого рода эффекты, отображение с полупрозрачностью. Чтобы решить проблему с разрывом картинки ставится композитор picom, либо вместо openbox устанавливается kwin, у которого уже есть встроенный композитинг (xfwm кстати тоже работает), в крайнем случае лезем в настройки Иксов. По идее с переходом на Wayland эта проблема должна отпасть сама собой.

По моему опыту это одно из самых стабильных DE, ставил на нетбук thinkpad с одноядерным intel atom, работало отзывчиво, по потреблению памяти было в районе 270-300 МиБ с композитингом и без запуска лишних программ.

В остальном же - welcome to bug tracker.

Dr64h ★★★
()
Последнее исправление: Dr64h (всего исправлений: 1)

Вот здесь про Antico сказано, про браузер Aurora, и про то, что разработчик забросил Antico перейдя на Mac OS X.

Developer comment:

ANTICO DEVELOPMENT IS ENDED (I SWITCHED TO MAC OS X). I'M AVAILABLE TO PROVIDE ANY CLARIFICATION TO ALL INTERESTED DEVELOPERS TO CONTINUE THE PROJECT

P.S. Название конечно у этого Antico соответствующие, чтобы его найти надо изрядно покопаться в интернетах.

Dr64h ★★★
()
Ответ на: комментарий от hobbit

Нашёл! Antico!

Походу да. Теперь мой склероз подсказывает, что это Antico подхватил некто, капитально переработал и пытался сделать закос под macOS. А уже потом оно превратилось в RazorQt.

TI_Eugene ★★
() автор топика

Razor-qt - самобытная де. В начале десятых годов вполне косила под четвертые кеды, без жирных квинов и плазм. Однако оно глючное было, с кучей своих багов. Идея забросить LXDE пришла автору LXDE - pcman. Из-за неприятия гтк3, не помню конкретно в чем деталь. Он пригласил разрабов razor-qt, вот они вместе и написали основу lxqt на qt. Разрабы razor-qt, разумеется забросили своё творение, и переключились на lxqt. Однако, где-то году в 16-17 большинство разрабов razor-qt, да и пакман тоже, перестали комитить в lxqt. Как пишет сам пакман, из-за недостатка свободного времени, работа на первом месте. Года 4 последних lxqt на себе тащит один разраб tsujan, он не из razor-qt, и не разраб lxde, просто сам по себе. Вполне себе лёгкое окружение, с минимальным джентельменским набором лешких и простых приложух. Кому нужно простое окружение, без функций кед. Что до жора памяти, ну так сейчас 2024 год, жрёт lxqt больше lxde на 100-150 мб больше памяти, это ничего по сути. Сейчас легковесность меряется отсутствием горы зависимостей, и отсутствием излишней функциональности. Сейчас у всех минимум 4-8 GB ОЗУ, это в нулевые 256-512 мб памяти остро не хватало для тех программ, а сейчас ОЗУ как грязи. Уже давно нет смысла экономить сотню мегабайт, ради чего-то вообще :) Когда пишут, что lxqt тормозит на атлоне xp 2003 года, ну так это одноядерный шлак, оно гниёт на свалках давно. Наивно ожидать современный быстрый рабочий стол на таком хламе. LXDE там не тормозит, из-за гтк2 начала нулевых. Начнешь запускать файрфокс - он там не запустится вообще :) Минимум уже давно для десктопа нужна кора дуба, а на лаптопах самый дешманский 4-х ядерных проц начала десятых очень быстро с lxqt работает.

gtk222
()
Последнее исправление: gtk222 (всего исправлений: 1)
Ответ на: комментарий от Dr64h

So far I have tried this with Qt2 on a 486/33 with 16MB and it felt fast. Qlwm is available for Qt2, Qt3 and Qt4.

Да, раньше совсем всё по другому было, сейчас те же openbox или icewm если поставить, то система метров 70-90 съест.

Dr64h ★★★
()
Ответ на: комментарий от TI_Eugene

Меню есть в pcmanfm это если забыл как программа называется а так удобней хоткеи на часто используемые и лончер на остальное, rofi например или скрипт

anonymous
()
Ответ на: комментарий от Dr64h

А чем не устроил стандартный pavucontrol-qt?

В Федоре он не подтянулся с зависимостями, и значится как pavucontrol-qt.x86_64 : Qt port of volume control pavucontrol что ни как не намекает на стандартность для LXQT.

Чтобы решить проблему с разрывом картинки

Проще было установить XFCE, чем разбираться с проблемами этого DE.

…это одно из самых стабильных DE… В остальном же - welcome to bug tracker

Звучит несколько противоречиво.

в районе 270-300 МиБ

Не знаю, за счёт чего это было достигнуто — у меня один easyeffects, отказаться от которого довольно проблематично, установленный через flatpak кушает около 90мб. Но LXQT у меня потребляло от силы на 100 мб меньше Xfce, что несущественно.

luiswoo
()
Ответ на: комментарий от luiswoo

В Федоре он не подтянулся с зависимостями, и значится как pavucontrol-qt.x86_64 : Qt port of volume control pavucontrol что ни как не намекает на стандартность для LXQT.

pavucontrol-qt порт на Qt оригинального pavucontrol написанного на gtkmm, разрабатывается командой LXQt.

Это проблема Федоры, раз там не смогли нормально опакетить LXQt. Вот например метапакет из Дэба, там уже есть всё, миксер на выбор, оконный менеджер на выбор и прочие компоненты.

У многих дистрибутивов есть wiki статьи по ручной установке LXQt и о том какие для него пакеты рекомендовано устанавливать.

Dr64h ★★★
()
Ответ на: комментарий от Dr64h

Это проблема Федоры, раз там не смогли нормально опакетить LXQt.

Подозреваю, что в Fedora LXQt всё это учтено — это не отменяет кривость метапакета, как и проблем с панелью LXQt (для меня), но всё же никакой особой разницы между LXQt и Xfce, какая есть между Xfce и Гномом, не наблюдаю.

luiswoo
()
Ответ на: комментарий от Dr64h

тиринг это неправильно настроенный графический адаптер. picom тиринг не решает, – да, в интерфейсе его не будет видно, но в играх (если там не предусмотрены свои фишки), в видео, тиринг остается.

я давно решил эту проблему в xorg:

Option «TearFree» «on»

и неважно в каком я гуи, всё работает плавно.

beeper
()
Ответ на: комментарий от beeper

picom тиринг не решает

picom --vsync

Почитай как работает композитор, он выводит итоговую картинку, работает с буферами графики, соответственно может делать синхронизацию кадров и большинство оконных менеджеров со встроенным композитором поддерживают эту функцию.

я давно решил эту проблему в xorg

Про Иксовые настройки я упоминал, хорошо, если получится эту опцию включить, что не всегда удаётся.

да, в интерфейсе его не будет видно, но в играх

Смотря как, если игра запущена в режиме «полноэкранное окно без рамки» (fullscreen borderless window), то будет работать синхронизация кадров вместе с рабочим столом, если же игра запущена в режиме «полный экран» (fullscreen), то игра монополизирует вывод картинки и тут уже придётся включать синхронизацию в самой игре.

На счёт видео примерно всё тоже самое, всё зависит от того как и где оно запускается.

Dr64h ★★★
()
Ответ на: комментарий от Dr64h

Почитай как работает композитор, он выводит итоговую картинку, работает с буферами графики, соответственно может делать синхронизацию кадров и большинство оконных менеджеров со встроенным композитором поддерживают эту функцию.

Я понимаю как оно работает, создается виртуальный буфер и с него уже копируются смешанные элементы в экран. Сама видеокарта как обычно фигачит на полную свои фпс на износ.

Для меня это вообще не приемлемо, костыль который работает как виртуальная прослойка. И так же, видео и графика, тут не станет без тиринга. Просто интерфейс через костыль. И зачем это надо?

Проще настроить видеокарту свою, и это применять везде.

beeper
()