В состав опубликованного (https://www.kde.org/announcements/kde-frameworks-5.22.0.php) на днях выпуска платформы KDE Frameworks 5.22.0, в рамках которой развивается (https://www.opennet.dev/opennews/art.shtml?num=40158) реструктуризованный и портированный на Qt 5 базовый набор библиотек и runtime-компонентов, лежащих в основе KDE, принята (https://blog.martin-graesslin.com/blog/2016/05/kwayland-join.../) библиотека KWayland, в которую вынесен код Plasma, специфичный для поддержки Wayland.
KWayland отнесён к фреймворкам первого уровня, т.е. является функциональным дополнением к Qt и, кроме Qt, не требует дополнительных зависимостей. При этом KWayland позиционируется не как замена QtWayland, а как дополнение к QtWayland, предоставляющее большую гибкость за счёт приближения программного интерфейса к Wayland API.
Для разработчиков KDE и Qt вхождение KWayland в KDE Frameworks является важной вехой в развитии, так как теперь открыты двери для задействования возможностей KWayland в других фреймворках KDE и для применения всеми, кто заинтересован в использовании Wayland с Qt. Ранее KWayland поставлялся в составе рабочего стола KDE Plasma, что было препятствием для его обособленного использования.URL: https://blog.martin-graesslin.com/blog/2016/05/kwayland-join.../
Новость: http://www.opennet.dev/opennews/art.shtml?num=44446
Позвольте! Но ведь в Qt уже есть QtWayland! На кой ещё один дублирующийся модуль под названием KWayland? Почему бы не допилить QtWayland до юзабельного состояния? Но нет KDE'шники будут дублировать код QtWayland'а в этом KWayland, раздуют зависимостей на пару сот мегабайт, а потом снова будут возмущаться, почему их кодое никто не пользуется.
Насколько я понял KWayland это те нюансы Wayland, которые важны для KDE, но нахрен не нужны в Qt, который ограничивается QtWayland.
Новость не читай, сразу комментируй!
Это ещё один толстый слой наследуемых классов, которые нахрен никому не нужны, но людям хочется понаворотить всякого, ибо помешаны на ООП как таковом. Такие люди встречаются в программировании, вот их и отправляют писать kdelibs и прочую программную толстоту.
C каких пор наследование в C++ влияет на ресурсы?
Ну если классы в этом самом KWayland - виртуальные, то будет небольшой оверхед.
есть мнение, что оверхед от виртуальных функций ничто по сравнению даже с одной открытой вкладкой в браузере, и вообще, не думаю что в реальных приложениях существуют видимые последствия именно виртуальных функций, а не кривого кода.
Если есть массив(коллекция) и во время выполнения в нём не более двух потомков одного класса, то делается инлайнинг скомпилированного кода конкретных методов. Т.о. при вызове просто происходит переход без лукапа по таблице. Это довольно существенно ускоряет исполнение.
Вообще это всё про Java ;-). KDE надо переписать не ней, чтобы оверхеда от ООП было меньше :-D.
Вообще-то, компиляторы вроде GCC умеют то же самое во время компиляции, (если, конечно, докажут, что это возможно).
В Java для этого сам JIT должен это отследить и скомпилить в рантайме - тот ещё оверхед.PS: Я молчу про GC..
> В Java для этого сам JIT должен это отследитьC чего вы решили что это нельзя отследить и сделать при копиляции в байткод?
Когда-то приходилось тыкать жабу, ее ВМ вместе с байткодгенерацией/разборкой и там довольно много оптимизаций, особенно высокоуровневых, делается именно при компиляции в байткод.JIT в этом случае эдакая дополнительная плюшка, которая теоретически может оптимизировать для конкретного рантайма/запуска.
Отлично, про игровые драйвера под Вэйлэнд можно забыть.
Почему?
> игровые драйвера под ВэйлэндЭто что за бред?
nVidia же говорила, что никакой поддержки не будет, Но таки прогнулась. А может палец Линуса подействовал :-) ?
Действие пальца Линуса будет продолжаться и через века.
Вообще могло бы быть непонятно, зачем KDE (и некоторые другие гномы) возятся с этим неработоспособным вэйландом, пытаясь придать ему этим хоть какую-то работоспособность. Потому что если вэйланд неработоспособен и не имеет сферы применений, то ... Тащить его в KDE (и в qt) причин нет. Кроме конечно дебилизма.
В вэйланде конечно могут делать поддержку X-совместимости, чтобы работали X-приложения, но это уже весьма другая тема...
Что вы там курите?1. Wayland пытается заменить Xserver и его композитинг.
2. Причём тут тащить в фреймворк? В фреймворках обеспечивают поддержку работы под wayland и всё!
3. В wayland есть поддержка Xorg -- смотрите XWayland.Хоть бы почитали, прежде чем комментировать.
> Причём тут тащить в фреймворк? В фреймворках обеспечивают поддержку работы под wayland и всё!Проблема Wayland заключается в том, что wayland-клиент не может полноценно взаимодействовать с другими wayland-клиентами и с wayland-композитором. Разработчики wayland "спихнули" эту работу на разработчиков DE.
Для DE такое взаимодействие жизненно необходимо... поэтому вот первые костыли от KDE! Ждем аналогов от Gnome, Enlightenment и прочих.
Ну следуют Unix-way, всё верно. Дано пора разделить обязанности между процессами, а не вешать всё на графический сервер. Мне кажется это правильно, меньше проблем.
> Ну следуют Unix-way, всё верно. Дано пора разделить обязанности между процессами, а не вешать всё на графический сервер.В каком месте вы там увидели unix-way? В графический сервер теперь встроен оконный менеджер, панель задач, переключение окон по alt+tab, глобальные клавиши и т.д. В X11 можно было на лету менять панельки и оконные менеджеры. А теперь это все будет встроено в один жирный блоб под названием "композитор", который вещь в себе для почти для всех (кроме нескольких DE-специфичных утилит, которые умеют полноценно работать только со своим DE-специфичным композитором).
Такая архитектура быстрее в плане производительности. Про проще весьма сомнительно (т.к. вместо готового протокола приходится велосипедить свой). Про расширяемость можете забыть...
> Мне кажется это правильно, меньше проблем.
А мне кажется, что вы просто наслушались всяких самсунгов, у которых несколько другие задачи. У самсунга меньше проблем, т.к. ему важно чтобы анимации были плавными и чтобы тиринга не было. А вот задачи запустить приложения из KDE в Enlightenment у них уже нет... или сменить штатную панельку на альтернативную... или сменить оконный менеджер на тайловый.
Ок, не знал, что там так всё гвоздями прибито, моя вина. Но всё же Wayland избавляет от некоторых проблем Xorg, не так ли?
> Wayland избавляет от некоторых проблем Xorg, не так ли?Да, композитный режим проще и быстрее при условии наличия OpenGL (ну или EGL). Отзывчивость хорошая (не скорость рендеринга, а именно задержки). Можно упростить Xorg до уровня Xnest/Xephyr, если вместо DDX-драйверов заюзать EGL+wayland. Может даже будет с такой же скорость как и раньше работать.
Но вот строить полнофункциональную DE на базе только протокола Wayland - это какая-то авантюра. Странно, что все кинулись этим заниматься... то ли NIH синдром, то ли скучно, то ли есть то что нам не афишируют. На wayland можно запилить быструю DE уровня Android, но на десктопе такая DE сольет всем. Поэтому мне непонятны восхищения wayland'ом.
> то что нам не афишируют.Кое-кто из X org грозит прекращением поддержки X. Но даже и особенно в этом случае предлагаемый этими товарищами wayland с трудом заслуживает доверия.
> А теперь это все будет встроено в один жирный блоб под названием "композитор", который вещь в себе для почти для всех (кроме нескольких DE-специфичных утилит, которые умеют полноценно работать только со своим DE-специфичным композитором).Для этого необходимы качественные расширения протокола, которые будут поддерживать все: композиторы и клиенты.
> А вот задачи запустить приложения из KDE в Enlightenment у них уже нет...Приложение обязано поддерживать core протокол, а значит отрисуется любым композитором. Практически любым: композитор может не поддерживать новые фичи последней версии протокола, а приложение отказывается работать с тем, что есть. Но эта проблема касается всех протоколов, включая X11.
> или сменить штатную панельку на альтернативную...Клиент не имеет доступа к другим клиентам, для такой задачи необходимо расширение протокола, если ты весь из себя дизайнер - пили RFC.
> или сменить оконный менеджер на тайловый.В чем проблема написать модульный премодульный композитор? Видимо, не нужно никому. К тому же при отображении тайловых окон можно применить соответствующие оптимизации.
> необходимы качественные расширения протокола
> Клиент не имеет доступа к другим клиентам, для такой задачи необходимо расширение протоколаРасширения протоколов конечно помогут, но ими даже не начали заниматься (там пока всякие тачскрины и фулскрины в очередной раз переизобретают). Desktop Shell даже в unstable нету.
А вы бы лучше объяснили пользователям что из этого Wayland получится на выходе. А то все два преимущества перечислили (каждый кадр идеален, претензий нет)... а минусов там раз в 20 больше... Потом в процессе беседы пользователь удивляется "Как это нельзя запустить cairodock в wayland?" Мое имхо, что даже win95 фичастее wayland.
> В чем проблема написать модульный премодульный композитор?
А в чем проблема заставить все DE перейти на единый унифицированный модульный wayland-композитор?
Ну вот мне понравилась среда E-какая-то-по-счету. А допустим тайлинга там нет... И получается что раньше можно было взять и сменить wm (это мог сделать пользователь!). А сейчас - пользователь подобрал тайловый композитор... но остальная DE-то с ним не заработает (т.к. нету стандартных расширений). Т.е. надо еще обеспечить. чтобы все DE перешли на унифицированный модульный композитор.
> если ты весь из себя дизайнер - пили RFCВот тут сольюсь быстро и решительно :) Во-первых, опыта у меня нет. Во-вторых, менее геморно выкинуть wayland core protocol и изобрести нормальный X12, чем обвешивать wayland расширениями пока он не превратится в X12...
> Что вы там курите?:-)
Пункт первый. Что там пытается заменить (недоделаный) вэйланд - не первостепенно важно. Особенно для к примеру KDE. Может пытаться дальше.
Пункт второй. Про дебилизм уже сказано.
Пункт третий. Мы знаем. :-)Если всё не осилите, читайте пункт второй.
О боже, так и не прочитали, то, что я хотел сказать.1. Проект пока сырой, что вы от него ожидаете? Подождите ещё года 2-3.
2. В Qt пилят _поддержку_ wayland. А вы написали так, как будто его туда добавили.
3. Если знаете, то почему пишете обратное?>>Если всё не осилите, читайте пункт второй.
А вот это уже оскорбление, я считаю. Я не обязан читать ваш бред.
> А вот это уже оскорбление, я считаю. Я не обязан читать ваш
> бред.Может, если мы вам предложим направление на один довольно широко известный адрес, вы и это оскорблением посчитаете? :-)
> Многие говорят, что ограничения X11 не позволяют создавать красивые GUI, как в других операционных системах. Wayland исправит это и выведет Linux на современный уровень в части графических интерфейсов. Внедрение Wayland в качестве композитного менеджера для Ubuntu ожидается в Ubuntu 13.04 (апрель 2013 года) или в следующем релизе.
Лучший интерфейс - это KDE 3/4.А также слизанная с него Win7.
С тех пор идет непрерывная деградация и добавление тормозов усилиями "улушаторов" и "осовременивателей".
Кто подымал вяленого в многоместных системах? Слыхал что такая возможность уже есть.