LINUX.ORG.RU

Wayland: ваше мнение, впечатления, будущее?

 , ,


1

1

Вечер добрый, господа! Хотелось бы узнать ваше мнение про wayland в 2021г, пользуетесь ли им, есть ли какие-нибудь проблемы, если да, то какие? Как там поддержка от NVidia? Да и в целом, пригоден ли он для использования? Кратко о себе: пользуюсь кедами с вялым на ноуте с amd, всё работает прекрасно, ничего не падает, проблем никаких не было, играть вполне можно

Ответ на: комментарий от EXL

Программисты, художники, дизайнейры, Web-разработчики.

Перечислили сорта смузихлёбов, дальше что? :P

коль спрос будет

Маловероятно, там ради поддержки UWP надо нафиг новый вайн писать. Пользы от него как такового становится всё меньше не для игр :P

Помойка «Microsoft Visual 2017 Redistributable»

Оно обычно отдельно распространяется.

осталось только найти кнопку «меню» в них

Аппаратные до сих пор работают :P Даже в новых приложениях, если поддерживают. Можно эмуляцию закостылять.

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

Из-за базара по типу «одни пилят Snap, другие пилят Flatpak» это трудно себе предствить.

SnapOS, FlatpakOS.

15+ лет в этом LSB ещё Qt 3 зачем-то болтался

Это потому что в Qt API ломают. И не надо говорить что в C++ нельзя не ломать API, у разработчиков Haiku почему-то получается не ломать и BeOS приложения 20 летней давности работают. При этом добавляют новый функционал, расширяя API.

Централизация нужна, как для ядра.

Для начала нужен тулкит, который не будут ломать каждые 5 лет. Пока на эту роль подходит только Motif и Wine.

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

И получился в итоге унылый ненужный цугундер, которому даже до распространённости Maemo/Meego далеко.

Этот «цугундер» пробыл на рынке гораздо больше времени, чем Maemo и Meego вместе взятые.

В то время как на современном Librem, например, народ по-прежнему запускает иксы.

PureOS uses Wayland by default.

Ясно, понятно.

Где в этом списке ncurses, UXP, LCL, VCL, FLTK?

На помойке. Кроме ncurses. А VCL как wxWidgets рендерит внутрь GTK+3 или Qt 5. Если ты про VCL из LibreOffice, а не Borland C++ или как там его.

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

Речь не о прибитости к ядру, а о том, что внутри всё прибито. В винде как раз даже встроенных средства куча: uxtheme, Shell менять можно, ресурсы в открытом виде в системные файлы повшиваны вплоть до XML-описаний, а не только картиночек. А через хуки вообще можно декорировать чужие окна, лезть внутри виджетов, скрывать их или переопределять отрисовку, и так далее: всё благодаря той же открытой структуре окон почти на любых тулкитах. К дриснятке похуже стало, многое огородили, но поныне лучше, чем на макоси. На макоси вообще треш и угар, даже для такой банальщины, как заголовки WM сменить.

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

Его ж уже как раз почти портировали на гномтулкит, или за свежатинкой бегать не любите? :P

Ладно, держите полный список:

libgtk2.0-0
Reverse Depends:
  Зависит: libwebkit2gtk-4.0-37-gtk2 (>= 2.24.10)
  Зависит: xournal (>= 2.14.0)
  Зависит: xfce4-volumed (>= 2.8.0)
  Зависит: winff-gtk2 (>= 2.24.32)
  Зависит: tixati (>= 2.16.0)
  Зависит: solvespace (>= 2.14.0)
  Зависит: ruby-gtk2 (>= 2.24.0)
  Зависит: qt5-gtk2-platformtheme (>= 2.24.0)
  Зависит: python-webkit (>= 2.10.0)
  Зависит: python-rsvg (>= 2.8.0)
  Зависит: python-notify (>= 2.8.0)
  Зависит: python-gtk2 (>= 2.24.0)
  Зависит: python-glade2 (>= 2.18.0)
  Зависит: pdfcube (>= 2.8.0)
  Зависит: orage (>= 2.16.0)
  Зависит: openbox-menu (>= 2.8.0)
  Зависит: mtpaint (>= 2.24.32)
  Зависит: medit (>= 2.24.0)
  Зависит: mdm (>= 2.24.0)
  Зависит: lxtask (>= 2.14.0)
  Зависит: lxpanel (>= 2.24.32)
  Зависит: libxfce4ui-1-0 (>= 2.24.32)
  Зависит: libwxgtk3.0-0v5 (>= 2.24.0)
  Зависит: libwebkitgtk-1.0-0 (>= 2.24.32)
  Зависит: libunique-1.0-0 (>= 2.24.0)
  Рекомендует: libsuil-0-0 (>= 2.24.0)
  Зависит: libgail18 (= 2.24.32-4)
  Зависит: libmx-bin (>= 2.8.0)
  Зависит: libkeybinder0 (>= 2.24.0)
  Зависит: libindicator7 (>= 2.24.32)
  Зависит: libgtksourceview2.0-0 (>= 2.16.0)
  Зависит: libgtk2.0-dev (= 2.24.32-4)
  Рекомендует: libgtk2.0-common
  Зависит: libgtk2.0-bin (= 2.24.32-4)
  Зависит: libgksu2-0 (>= 2.12.0)
  Зависит: libgimp2.0 (>= 2.24.32)
  Зависит: libgarcon-1-0 (>= 2.24)
  Зависит: libgail-common (>= 2.24.32)
  Зависит: libfm-tools (>= 2.12.0)
  Зависит: libfm-modules (>= 2.18.0)
  Зависит: libfm-gtk4 (>= 2.24.32)
  Зависит: libexo-1-0 (>= 2.24.32)
  Зависит: libaudgui5 (>= 2.24.0)
  Зависит: libappindicator1 (>= 2.24.32)
  Зависит: latencytop (>= 2.8.0)
  Зависит: ibus-gtk (>= 2.24.5-4)
  Зависит: gwc (>= 2.16.0)
  Зависит: gtklp (>= 2.8.0)
  Зависит: gpick (>= 2.24.32)
  Зависит: gmidimonitor (>= 2.12.0)
  Зависит: gksu (>= 2.8.0)
  Зависит: gir1.2-gtk-2.0 (>= 2.24.0)
  Зависит: gimp (>= 2.24.32)
  Зависит: flashplugin-nonfree (>= 2.14)
  Зависит: fbpanel (>= 2.24.32)
  Зависит: deadbeef-static (>= 2.12.0)
  Зависит: claws-mail (>= 2.24.32)
  Зависит: browser-plugin-vlc (>= 2.24.0)
  Зависит: audacious-plugins (>= 2.24.0)
  Зависит: ardour (>= 2.24.0)
  Зависит: libcairo-compmgr0 (>= 2.8.0)
  Зависит: cairo-compmgr-plugins (>= 2.12.0)
  Зависит: cairo-compmgr-core (>= 2.14.0)
  Зависит: dwarf-fortress (>= 2.8.0)
  Зависит: xzgv (>= 2.24.0)
  Зависит: xournal (>= 2.14.0)
  Зависит: winff-gtk2 (>= 2.24.32)
  Зависит: viewnior (>= 2.24.32)
  Зависит: trayer (>= 2.24.32)
  Зависит: tint2 (>= 2.14.0)
  Зависит: sweep (>= 2.24.32)
  Рекомендует: libsuil-0-0 (>= 2.24.0)
  Зависит: ruby-gtk2 (>= 2.24.0)
  Зависит: qt5-gtk2-platformtheme (>= 2.24.0)
  Зависит: qiv (>= 2.24.0)
  Зависит: pidgin-plugin-pack (>= 2.8.0)
  Зависит: pinentry-gtk2 (>= 2.14.0)
  Зависит: pidgin-privacy-please (>= 2.8.0)
  Зависит: pidgin-mpris (>= 2.8.0)
  Зависит: pidgin-latex (>= 2.8.0)
  Зависит: pidgin (>= 2.24.0)
  Зависит: pdfcube (>= 2.8.0)
  Зависит: pcmanfm (>= 2.24.32)
  Зависит: obsession (>= 2.14.0)
  Зависит: neko (>= 2.8.0)
  Зависит: mtpaint (>= 2.24.32)
  Предлагает: libmono-system-windows-forms4.0-cil (>= 2.16.0)
  Зависит: malaga-bin (>= 2.8.0)
  Зависит: lxtask (>= 2.14.0)
  Зависит: lxsession-logout (>= 2.24.0)
  Зависит: lxsession-default-apps (>= 2.24.32)
  Зависит: lxsession (>= 2.24.32)
  Зависит: lxrandr (>= 2.24.0)
  Зависит: lxpanel (>= 2.24.0)
  Зависит: lxinput (>= 2.18.0)
  Зависит: lxdm (>= 2.24.0)
  Зависит: lxappearance (>= 2.14.0)
  Зависит: libwnck22 (>= 2.24.32)
  Зависит: libgnomecanvas2-0 (>= 2.24.32)
  Зависит: libglade2-0 (>= 2.8.0)
  Зависит: libfm-tools (>= 2.12.0)
  Зависит: libfm-modules (>= 2.18.0)
  Зависит: libfm-gtk4 (>= 2.24.32)
  Зависит: libdv-bin (>= 2.8.0)
  Зависит: libcanberra-gtk0 (>= 2.24.0)
  Зависит: libcanberra-gtk-module (>= 2.24.5-4)
  Зависит: libkeybinder0 (>= 2.24.0)
  Зависит: ibus-gtk (>= 2.24.5-4)
  Зависит: libgtkspell0 (>= 2.8.0)
  Зависит: libgtkmm-2.4-1v5 (>= 2.24.0)
  Зависит: gtklp (>= 2.8.0)
  Зависит: libgtkglext1 (>= 2.24.0)
  Зависит: libgtk2.0-cil (>= 2.24.32)
  Зависит: libgtk2.0-dev (= 2.24.33-1)
  Рекомендует: libgtk2.0-common
  Зависит: libgtk2.0-bin (= 2.24.33-1)
  Зависит: libgail18 (= 2.24.33-1)
  Зависит: libgail-common (>= 2.24.0)
  Зависит: gir1.2-gtk-2.0 (>= 2.24.0)
  Зависит: gpicview (>= 2.20.0)
  Зависит: xgnokii (>= 2.8.0)
  Зависит: gliv (>= 2.8.0)
  Зависит: libgimp2.0 (>= 2.24.32)
  Зависит: gimp (>= 2.24.32)
  Зависит: libzlui-gtk (>= 2.10.0)
  Зависит: dvdisaster (>= 2.8.0)
  Зависит: doublecmd-gtk (>= 2.24.32)
  Зависит: dia (>= 2.24.32)
  Зависит: claws-mail (>= 2.24.32)
  Зависит: calf-plugins (>= 2.24.32)
  Зависит: audacious-plugins (>= 2.24.0)
  Зависит: libaudgui5 (>= 2.24.0)
  Зависит: ardour (>= 2.24.0)

Это ещё не считая HexChat, который стоит через Nix, и, возможно, чего-нибудь ещё :P А также мимикрирующего под GTK+2 Qt5.

А теперь оправдывайтесь, почему это всё не нужно, по пунктам. Можете с другими гимптулкитофобами скооперироваться и разбить, чтобы быстрее было :P

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

GTK2 нужен для firefox. Без него не собирается. Баг висит уже 2 годика.

Во-первых, три года назад: Firefox окончательно удаляет поддержку GTK+2

Во-вторых:

$ cd /usr/lib64/
$ sudo mv libgtk-x11-2.0.so.0.2400.32 libgtk-x11-2.0.so.0.2400.32~
$ gimp
gimp: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory
$ firefox
<всё работает, в т. ч. и файловый диалог>

По твоей же ссылке отчётливо сказано о том, что GTK+2 нужен был для NPAPI (ныне выпиленого) и Adobe Flash (ныне тоже выпиленного).

То что сборочная система Firefox – лютая помойка, в которой со скрипом проходят вообще какие-либо изменения, давно уже не секрет. Но эти сопли подотрут после убийства Flash’а в этом году.

А для полноценной работы браузера Firefox библиотека GTK+2 давно уже не нужна, более того в https://github.com/mozilla/gecko-dev/tree/master/widget/gtk давно уже GTK+3 only вакханалия.

EXL ★★★★★
()
Ответ на: комментарий от s-warus

не хочу чтобы меня ограничивали

И именно из-за этого некоторые технологии на онтопике не присутствуют.

Например, серьёзные реализации DRM отсутствуют, поскольку они требуют проверку целостности системы на всех уровнях во избежание утечек и перехвата данных.

Нет здесь и всяких модных мессенджеров, которые принудительно удаляют отправленное содержимое на чужом устройстве. За обход этого можно поиметь не только проблемы с ToS и бан, но во многих странах и проблемы с законом, так что с таким подходом Вы ССЗБ ;)

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

и 15+ лет в этом LSB ещё Qt 3 зачем-то болтался

Затем, чтобы написанные 15 лет назад программы на Qt3 работали, это же очевидно.

Иначе какой смысл в LSB?

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

Маловероятно, там ради поддержки UWP надо нафиг новый вайн писать. Пользы от него как такового становится всё меньше не для игр :P

Тогда смысл всех этих стенаний о том, что какие-то фанаты Wayland запилили форк Wine для игр? Для главной цели Wine и запилили свои хотелки.

Оно обычно отдельно распространяется.

Суть одна и та же. Вот AppImage, кстати, тоже из похожей оперы.

Аппаратные до сих пор работают :P Даже в новых приложениях, если поддерживают. Можно эмуляцию закостылять.

Закостылять, если поддерживают и т. д. Это к вопросу о стабильности API у Android, кстати было.

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

Белка-истеричка

Он начал разрабатывать свою операционную систему, т.к. в этом линуксе бардак и шатание.

ls-h ★★★★★
()
Ответ на: комментарий от EXL

Проблема с AppImage гораздо обширнее

Он там не только проблемы с AppImage называет, у него длинный список.

ls-h ★★★★★
()
Ответ на: комментарий от mertvoprog

там ради поддержки UWP надо нафиг новый вайн писать

Зачем? Этих UWP приложений всего в магазине 3.5 штуки и они практически никому не нужны.

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

Решать будут разработчики и мейнтенеры дистрибутивов. Не нравится? Ок, тебе выше уже несколько раз предложили исправить положение. Но ныть на ЛОРе ведь проще, да?

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

RedHat признаёт ошибку и возвращается обратно мейнтейнить Xorg

При чём здесь ваш редхат? :P

Взять проект изначально предназначенный для мобильных

То есть то, что все актуальные мобильные ОС для смартфонов/коммуникаторов изначально для них не предназначены, Вас не смущает? :P

Android/KaiOS — порты изначально PC-шного Linux; iOS — потомок Mac OS X; даже покойные WP8 и WM10 основаны на Windows NT.

А Symbian (потомок эмбеддедного EPOC), Windows Mobile (отпрыск WinCE), изначально мобильная BB OS ≤7 и основанная на эмбеддедном QNX BB OS 10, всяческие чисто мобильные или эмбеддедные ОС для фичерфонов типа IPA, OSE, SPH, Nucleus — мертвы. Разве что MTK/SpreadTrumOS/MocorOS (на ThreadX) ещё шевелятся.

Так что Android-x86 просто «вернули домой» ;) (ану цыц, не разводить 5.3!)

выкинув нахрен это промежуточное звено

Промежуточные в этой архитектуре вообще-то WM. X.Org выше всего. А композиторы по факту являются скорее заменой X.Org, чем заменой WM. То есть сменяемые WM в вяленом мирке по факту отсутствуют, равно как и межкомпозиторная совместимость.

Ты в одном предложении сам спрашиваешь и сам отвечаешь.

То есть мочёные — говноеды, или как?

Линус вон git запилил, когда ему мейнстрим не понравился и нормально - создал свой мейнстрим

Мейнстрим не заменяется, он плавно изменяется. Git не единомоментно победил другие СКВ. И чтобы победить, ему пришлось из мейнстрима многое в себя вобрать, иначе эту нипаняяяяяяятную поделку восприняли бы в штыки и дальше сидели на своих CVS/SVN ;) В итоге Git получился кривой-косой с кучей родовых травм, что в целом характерно для мейнстримовых поделий ;)

А чтобы запилить что-то хорошее, под мейнстрим не стоит прогибаться, а лучше вообще его игнорировать.

У жены есть

Дефолт, конечно же? ;)

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

SnapOS, FlatpakOS.

Ты лично веришь в то, что подобное получит распространение? Я – нет.

Это потому что в Qt API ломают. И не надо говорить что в C++ нельзя не ломать API

Ломают в Qt API на самом деле не так уж и сильно после Qt 4. А эта ломка предназначена в первую очередь для улучшения архитектуры Qt и его гибкости. Если тот же Qt 4 был прибит гвоздями условно к xcb, то для Qt 5 ты волен создавать QPA-плагины и очень быстро адаптировать новые версии Qt под целевую платформу.

Очевидный пример – 3DEyes** который делает полнофункциональный порт Qt 6 под Haiku в день его релиза. И такие же дядечки делают его для всяких там других экзотических платформ, вроде VxWorks или OS/2, просто скомпилировав код и подцепив нужный QPA-модуль. И в Qt 6 должны идти ещё дальше и абстрагировать гвоздями прибитый к QtGui OpenGL, дабы иметь возможность работы с другими GAPI.

у разработчиков Haiku почему-то получается не ломать и BeOS приложения 20 летней давности работают. При этом добавляют новый функционал, расширяя API.

Для операционной системы сбрасывать груз Legacy всегда труднее, чем для фреймворка или тулкита.

Для начала нужен тулкит, который не будут ломать каждые 5 лет. Пока на эту роль подходит только Motif и Wine.

Смех, смехом, но Win32 API действительно подходит, ведь он активно развивается. Там есть всякие GDI с поддержкой HiDPI, рендеринг шрифтов с моднявым сглаживанием в оттенки серого и пр. А Motif нисколько на эту роль не годится, он остался в начале нулевых и чтобы осовременить его, требуется чудовищное вложение времени.

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

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

Иногда проще, костыльно-кривокосо поменять в памяти (обмануть), освободить файловые inode под root (чтобы работало прямо сейчас). Не раз, не два костыль из xdotools ускорял рутинные операции.

s-warus ★★★
()
Ответ на: комментарий от EXL

пробыл на рынке гораздо больше времени

Толку с этой стагнации? Дурить народ и инвесторов можно десятилетиями. Продаж-то нет.

by default

Во всяких бубунтофедоробедианах тоже по дефолту вяленд засовывают, и что? :P А потом ещё и высовывают!

На помойке

То есть Мы их с помойки притащили, ясно :P А почему не весь онтопик тогда сразу?

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

Как удобно приводить список зависимых пакетов (большинство из которых байндинги) от libgtk2, но опускать при этом в два или три раза больший список зависимых пакетов от libgtk3 из репозитория твоего же даже пускай какого-то замшелого DEB-based дистрибутива.

Его ж уже как раз почти портировали на гномтулкит, или за свежатинкой бегать не любите? :P

Жду офицального пакета. С переходом на GTK+3 он наконец-то будет работать нормально с HiDPI-мониторами.

А GTK+2 так и не получит подобную поддержку.

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

Ты лично веришь в то, что подобное получит распространение? Я – нет.

Почему бы и нет? Я скорее за целостные дистрибутивы с единой системой установки софта, инициализации, системным тулкитом и т.д.. Пусть на системе с GTK программы на Qt запускают через что-то наподобие GTK Qt platform plugin. И не будет проблем с протоколами GUI серверов. Бардак — это зло.

Ломают в Qt API на самом деле не так уж и сильно после Qt 4.

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

Для операционной системы сбрасывать груз Legacy всегда труднее, чем для фреймворка или тулкита.

С технической точки зрения Haiku Kits ничем не отличается от Qt Modules. Какой-то особой прибитости к ядру нет.

Смех, смехом, но Win32 API действительно подходит, ведь он активно развивается.

Для Линукса там есть проблема с виртуализацией файловой системы, отдельным списком процессов и форматом исполняемых файлов. Надо делать Wine более нативным для Линукса.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 2)
Ответ на: комментарий от EXL

Для главной цели Wine и запилили свои хотелки

Так Wine сам по себе становится бесполезен для незадротов :P Да и для задротов тоже, ибо нативные игры под онтопик благодаря Steam растут, как на дрожжах.

Суть одна и та же

Ни фига, оно становится в систему одно, а не с каждой программой отдельно.

Это к вопросу о стабильности API у Android, кстати было

А каким боком стабильность API относится к тому, что в новых аппаратах обычно не завозят аппаратную кнопку меню, и в дефолтных программных статусбарах от разных вендоров (и пусть даже в стоковом AOSP’овском) её нет тоже? :P

Может, WinAPI тоже нестабилен, потому что винду ставят на всякие ноутбуки с ущербными клавиатурами, где то цифрового блока нет, то правых модификаторов, то ещё чего, при этом сканкоды у выкинутых клавиш иные, чем у якобы заменяющих, и некоторым некропрограммам нужны именно они? ;)

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

При чём здесь ваш редхат

По крупному десктопный линукс пилит RH, Canonical и … всё.

То есть сменяемые WM в вяленом мирке по факту отсутствуют

Вяленые WM обязаны (!) единообразно обрабатывать stable протоколы. Чем тебе не сменяемость?

или как

Вот и пили вот такие стильные приложения. Для отработки модели - норм (кнопки есть, флажки есть, канва есть - хрена-ли ещё надо), пользователь с такими Гуями пошлёт нахрен сразу же.

А чтобы запилить что-то хорошее, под мейнстрим не стоит прогибаться, а лучше вообще его игнорировать

А я тебе что предлагаю. Возьми и делай, тебе же нужно не мне. Сделаешь хорошо, я даже скажу что ты молодец. Наверное.

Дефолт, конечно же? ;)

Говорит да. Ей на кастомости глубоко начхать, ей работать надо.

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

Смех, смехом, но Win32 API действительно подходит, ведь он активно развивается.

Ещё авторов Wine покусали гномеры: CreateProcess doesn’t set hProcess correctly when starting a Linux program (CLOSED WONTFIX). Хотя в Windows как-то умудрялись чтобы процесс был виден из DOS, Win16 и Win32, для этого создавались отдельные записи в каждой из трёх сред.

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

Прикладуха всякая новая на UWP делается, кому-то да нужна :P Это пока что мало, но когда вёнды старше дриснятки уверенно отомрут, на нём больше программ будет.

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

ибо нативные игры под онтопик благодаря Steam растут, как на дрожжах.

Ты до сих пор в 2013 живёшь? Покажи хоть одну полностью нативную игру под онтопик, за последние пару лет?

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

Толку с этой стагнации? Дурить народ и инвесторов можно десятилетиями. Продаж-то нет.

А у гиковских и довольно дорогих N900 и N9 эти продажи что ли были? У Sailfish всякие там бюджетки BQ в больших количествах продавались.

То есть Мы их с помойки притащили, ясно

Нет, они сами отслужили свой срок и отправились туда банально перестав развиваться.

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

Решать будут разработчики и мейнтенеры дистрибутивов

Вот поэтому Мы и настаиваем, что проблема с Wayland больше политическая, чем техническая, и решать её надо соответствующе: spread the word, и открывать людям глаза, чем Мы и занимаемся, и далеко не только на ЛОРе :P

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

Прикладуха всякая новая на UWP делается

Где? Не видел такой. Только примитивные программы вроде карт, часов и т.п… Сам Microsoft делает серьёзные программы на WinAPI или Electron (VS Code).

Это пока что мало, но когда вёнды старше дриснятки уверенно отомрут, на нём больше программ будет.

Смысл существования Windows исключительно в среде для запуска Win32 программ Без Win32 программ Windows отомрёт т.к. он будет ничем не лучше Android, Chrome OS и дистрибутивов Линукса.

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

чем Мы и занимаемся

Ещё раз - кто вы? Секта иксофанатиков? Ну так объединитесь с теми дятлами, которые божественный systemd хейтят и пилите свои уютные маргинальные дистрибутивы. Ты сейчас только что подтвердил мои слова - вас хватает только на нытьё на лоре и опеннете. И всё. Вы бесполезны. Так что сидите и молча наблюдайте за окончательной смертью иксов.

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

Покажи хоть одну полностью нативную игру под онтопик

Эм, ну, справедливости ради, Frictional Games все нативные под онтопик (даже недавняя Rebirth). Габен обещает Alyx, тут вон кто-то даже играл я помню.

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

Я скорее за целостные дистрибутивы с единой системой установки софта, инициализации, системным тулкитом и т.д.. Пусть на системе с GTK программы на Qt запускают через что-то наподобие GTK Qt platform plugin. И не будет проблем с протоколами GUI серверов. Бардак — это зло.

Считаешь, что подход «KDE OS» и «GNOME OS» оздоровит Linux-десктоп? А что тогда делать со всякими там WM-щиками, которых пруд пруди?

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

Считаешь, что подход «KDE OS» и «GNOME OS» оздоровит Linux-десктоп?

Да. Сказано что в дистрибутиве KDE — значит будьте добры все программы делать на Qt, а GTK, SDL и прочие запускать поверх Qt. А что там за протоколы внутри — не важно. Во всех без исключения нормальных десктопных и мобильных ОС так.

Тот же Wayland будет проще ввести т.к. им будут пользоваться только внутренние компоненты дистрибутива. А программы пусть используют системный тулкит, kdelibs и т.п..

А что тогда делать со всякими там WM-щиками, которых пруд пруди?

Пусть свой дистрибутив организуют, может быть один для нескольких схожих WM на одной платформе (X11, Wayland).

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 3)
Ответ на: комментарий от Sunderland93

Ок, тебе выше уже несколько раз предложили исправить положение

Дядь, я как раз тот, кто в этой помойке и шуршит. Не надо тут рассказывать в духе «сперва добейся».

То, тчо у тебя завелось без проблем на твоём железе - поздравляю! У меня VSCode на мощном железе с Intel HD люто тормозит, видно на глаз задержку (Debian testing, Sway. Arch, Sway) до 0.5 секунд.

Я тот, кто с токсиками как раз в wlroots каждый день, так как все хотелки пилят на нём. Самим сложна композитор накакакть с обвязкой утилит. В 2-3 рыла хрен теперь твой протокол запилишь, а если шмогла, то обвязки НЕТ. Нет ни хренушки. Ещё напрямую пасусь у чудика, разрабатывающего нормальную обвязку, а не поделки школьников: Foot, Fnott, Fuzzel, Fcft и так далее. https://codeberg.org/dnkl

Работы - вагон. При этом всё уже завязано на Wlroots. Чем пахнет знаешь? А?

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

С таким же успехом можно прислать на ЛОР патч с анимированными аватарками, смайликами и кармой, который после долгих трудов тупо отправится в /dev/null ;) Аналогия ясна?

mertvoprog
()
Ответ на: комментарий от s-warus

Иногда проще, костыльно-кривокосо поменять в памяти (обмануть)

А как Вы ещё хотели? ;) Программа работает с либами, а тут они внезапно меняются? Вы ж понимаете, какими непредсказуемыми последствиями чревата такая «хотелка», и что трудоёмкость её реализации не является умышленным огораживанием?

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

То, тчо у тебя завелось без проблем на твоём железе - поздравляю! У меня VSCode на мощном железе с Intel HD люто тормозит, видно на глаз задержку (Debian testing, Sway. Arch, Sway) до 0.5 секунд.

Если бы это реально была проблема - тормозило бы у всех. А так с тем же успехом можно посетовать и на тормоза чего-то иксового.

Я тот, кто с токсиками как раз в wlroots каждый день, так как все хотелки пилят на нём.

Ты свое DE пилишь или что? ты будто гуглотранслейтом общаешься

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

Ни фига, оно становится в систему одно, а не с каждой программой отдельно.

Как одно, если условно «каждая» программа требует какой-то свой там runtime определённого года и даже версии? Если бы было одно – такой параши в мире Windows бы не было. В мире Linux, например, её нет.

А каким боком стабильность API относится к тому, что в новых аппаратах обычно не завозят аппаратную кнопку меню, и в дефолтных программных статусбарах от разных вендоров (и пусть даже в стоковом AOSP’овском) её нет тоже? :P

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

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

которые божественный systemd хейтят и пилите свои уютные маргинальные дистрибутивы.

Я наконец понял кто ты. А сам то что можешь? Админить можешь? А в Embedded? А программировать? А, я забыл. Ты же видосометатель.

Топи за однофюрерность. Потом, когда придут времена 90х, такие как ты будут говорить, что не вы виноваты, что файл открывать надо в ПО за 300уе по подписке на год. И версия должна быть новая программы, старая подписка не проходит. И игру поиграть - 70баксов. Будешь своим детям на Новый Год или ДР дарить. А чё? Нормально. Так и заживём. Плюс, чтобы подойти к машине (как раньше было) сертификацию для лохов за 2к зелени, а чего нет? Альтернатив то нет. Зато унификация.

И я спрошу, а что сделал ты?

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

но опускать при этом в два или три раза больший список зависимых пакетов от libgtk3

А толку, там сплошной неюзабельный мусор, который надо бы сносить, даунгрейдить или форкать, но некогда :P Gajim, например, с версии 1.0 скатился совершенно, но там и не только в GTK+3 дело, а ещё и в Python 3 и внутренних переделках.

С переходом на GTK+3 он наконец-то будет работать нормально с HiDPI-мониторами

Амашужвать, в который раз спрашиваем: что в GTK+2 не так с HiDPI? ;) Кого ни спрашиваем — все сливаются. По ходу, слышали звон, но сами толком не знают, что не так. Зато пару УМВРщиков встречали.

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

Ты свое DE пилишь или что? ты будто гуглотранслейтом общаешься

WM под Wayland - да.

А ты просто лемминг. Вот тебе и мысли кажутся оторванными. Иди на Gnome и там живи. Хотя какой Gnome, с таким раскладом накопишь на ARM с логотипом и будешь рассекать )))

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

Если бы было одно – такой параши в мире Windows бы не было.

Это скорее претензии к авторам компилятора C++ от Microsoft. Ему почему-то для каждой версии нужен отдельный рантайм. Вроде бы в libstdc++ не такой бардак.

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

Я как минимум не ною на форумах, в отличии от некоторых. Что толку с того что ты программист, или кто ты там? Что конкретно ТЫ сделал для исправления такой неприятной для тебя и мертвопрога ситуации? Вы с ним на пару только ноете и всё.

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

Пусть на системе с GTK программы на Qt запускают через что-то наподобие GTK Qt platform plugin

Мощное кедерастское лобби с этим не согласится.

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

Иди на Gnome и там живи

Спасибо, мне и на KDE хорошо. А вот на твой Wayland-композитор глянул бы, если он конечно пригоден на что-то.

Sunderland93 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.