Исправление Skullnet, (текущая версия) :
Дело в том, что вейленд - это протокол не для чистого композитора, а для композитинг виндоу менеджера.
Я тебе больше скажу. Самопального графического сервера.
ВМ работает в одном процессе с композитором, а не отдельно, как было до вейленда.
Это не важно, в одном процессе или в нескольких. В иксах тоже могли в теории сделать оконный менеджер в процессе Xorg-а, просто код оконного менеджера был представлен в виде .so библиотеки и вызывался бы через dlopen. Суть в том, что у вейланда нет никакой разделяемой библиотеки, чтобы унифицировать фичи оконных менеджеров и так далее. Нет никаких libwayland-wm.so, libwayland-ipc.so, libwayland-screencasting.so и так далее - они должны реализовываться самопально разработчиками DE. Тогда как у иксов был бы один «wayland-server», который бы подгружал ту же DE в виде разделяемой библиотеки, а фичи были прилинкованы к этому DE через libx11-%featurename%.so. Конечно, как в иксах с процессами лучше, потому что краш процесса клиента, не крашит весь сервер.
wlroots предоставляет пример АПИ для скриншоттинга.
У тебя уже KDE и гнум накостылили свою собственную реализацию, и другие DE тоже будут костылить. Блин, не спрашивай даже почему, вот не понравился им wlroots или элементарный NIH-синдром. В иксах, ты строго ограничен фичами иксов и это намного больше хорошо, чем плохо. От X12 требовалось обновить протокол и выкинуть ограничения предыдущей версии, но вместо этого запилили хрен знает что.
Исправление Skullnet, :
Дело в том, что вейленд - это протокол не для чистого композитора, а для композитинг виндоу менеджера.
Я тебе больше скажу. Самопального графического сервера.
ВМ работает в одном процессе с композитором, а не отдельно, как было до вейленда.
Это не важно, в одном процессе или в нескольких. В иксах тоже могли в теории сделать оконный менеджер в процессе Xorg-а, просто код оконного менеджера был представлен в виде .so библиотеки и вызывался бы через dlopen. Суть в том, что у вейланда нет никакой разделяемой библиотеки, чтобы унифицировать фичи оконных менеджеров и так далее. Нет никаких libwayland-wm.so, libwayland-ipc.so, libwayland-screencasting.so и так далее - они должны реализовываться самопально разработчиками DE. Тогда как у иксов был бы один «wayland-server», который бы подгружал ту же DE в виде разделяемой библиотеки. Конечно, как в иксах с процессами лучше, потому что краш процесса клиента, не крашит весь сервер.
wlroots предоставляет пример АПИ для скриншоттинга.
У тебя уже KDE и гнум накостылили свою собственную реализацию, и другие DE тоже будут костылить. Блин, не спрашивай даже почему, вот не понравился им wlroots или элементарный NIH-синдром. В иксах, ты строго ограничен фичами иксов и это намного больше хорошо, чем плохо. От X12 требовалось обновить протокол и выкинуть ограничения предыдущей версии, но вместо этого запилили хрен знает что.
Исправление Skullnet, :
Дело в том, что вейленд - это протокол не для чистого композитора, а для композитинг виндоу менеджера.
Я тебе больше скажу. Самопального графического сервера.
ВМ работает в одном процессе с композитором, а не отдельно, как было до вейленда.
Это не важно, в одном процессе или в нескольких. В иксах тоже могли в теории сделать оконный менеджер в процессе Xorg-а, просто код оконного менеджера был представлен в виде .so библиотеки и вызывался бы через dlopen. Суть в том, что у вейланда нет никакой разделяемой библиотеки, чтобы унифицировать фичи оконных менеджеров и так далее. Нет никаких libwayland-wm.so, libwayland-ipc.so, libwayland-screencasting.so и так далее - они должны реализовываться самопально разработчиками DE. Тогда как у иксов был бы один wayland-server, который бы подгружал ту же DE в виде разделяемой библиотеки. Конечно, как в иксах с процессами лучше, потому что краш процесса клиента, не крашит весь сервер.
wlroots предоставляет пример АПИ для скриншоттинга.
У тебя уже KDE и гнум накостылили свою собственную реализацию, и другие DE тоже будут костылить. Блин, не спрашивай даже почему, вот не понравился им wlroots или элементарный NIH-синдром. В иксах, ты строго ограничен фичами иксов и это намного больше хорошо, чем плохо. От X12 требовалось обновить протокол и выкинуть ограничения предыдущей версии, но вместо этого запилили хрен знает что.
Исправление Skullnet, :
Дело в том, что вейленд - это протокол не для чистого композитора, а для композитинг виндоу менеджера.
Я тебе больше скажу. Самопального графического сервера.
ВМ работает в одном процессе с композитором, а не отдельно, как было до вейленда.
Это не важно, в одном процессе или в нескольких. В иксах тоже могли в теории сделать оконный менеджер в процессе Xorg-а, просто код оконного менеджера был представлен в виде .so библиотеки и вызывался бы через dlopen. Суть в том, что у вейланда нет никакой разделяемой библиотеки, чтобы унифицировать фичи оконных менеджеров и так далее. Нет никаких libwayland-wm.so, libwayland-ipc.so, libwayland-screencasting.so и так далее - они должны реализовываться самопально разработчиками DE. Тогда как у иксов был бы один wayland-server, который бы подгружал ту же DE в виде разделяемой библиотеки. Конечно, как в иксах с процессами лучше, потому что краш процесса клиента, не крашит весь сервер.
wlroots предоставляет пример АПИ для скриншоттинга.
У тебя уже KDE и гнум накостылили свою собственную реализацию, и другие DE тоже будут костылить. Блин, не спрашивай даже почему, вот не понравился им wlroots или элементарный NIH-синдром. В иксах, ты строго ограничен фичами иксов и это намного больше хорошо, чем плохо. От X12 требовалось обновить протокол и выкинуть ограничения предыдущей версии, но вместо этого запили хрен знает что.
Исправление Skullnet, :
Дело в том, что вейленд - это протокол не для чистого композитора, а для композитинг виндоу менеджера.
Я тебе больше скажу. Самопального графического сервера.
ВМ работает в одном процессе с композитором, а не отдельно, как было до вейленда.
Это не важно, в одном процессе или в нескольких. В иксах тоже могли в теории сделать оконный менеджер в процессе Xorg-а, просто код оконного менеджера был представлен в виде .so библиотеки и вызывался бы через dlopen. Суть в том, что у вейланда нет никакой разделяемой библиотеки, чтобы унифицировать фичи оконных менеджеров и так далее. Нет никаких libwayland-wm.so, libwayland-ipc.so, libwayland-screencasting.so и так далее - они должны реализовываться самопально разработчиками DE. Тогда как у иксов был бы один wayland-server, который бы подгружал ту же DE в виде разделяемой библиотеки. Конечно, как в иксах с процессами лучше, потому что краш процесса клиента, не крашит весь сервер.
wlroots предоставляет пример АПИ для скриншоттинга.
У тебя уже KDE и гнум накостылили свою собственную реализацию, и другие DE тоже будут костылить. Блин, не спрашивай даже почему, вот не понравился им wlroots или элементарный NIH-синдром. В иксах, ты строго ограничен фичами иксов и это намного больше хорошо, чем плохо.
Исходная версия Skullnet, :
Дело в том, что вейленд - это протокол не для чистого композитора, а для композитинг виндоу менеджера.
Я тебе больше скажу. Самопального графического сервера.
ВМ работает в одном процессе с композитором, а не отдельно, как было до вейленда.
Это не важно, в одном процессе или в нескольких. В иксах тоже могли в теории сделать оконный менеджер в процессе Xorg-а, просто код оконного менеджера был представлен в виде .so библиотеки и вызывался бы через dlopen. Суть в том, что у вейланда нет никакой разделяемой библиотеки, чтобы унифицировать фичи оконных менеджеров и так далее. Нет никаких libwayland-wm.so, libwayland-ipc.so, libwayland-screencasting.so и так далее. Тогда как у иксов был бы один wayland-server, который бы подгружал ту же DE в виде разделяемой библиотеки. Конечно, как в иксах с процессами лучше, потому что краш процесса клиента, не крашит весь сервер.
wlroots предоставляет пример АПИ для скриншоттинга.
У тебя уже KDE и гнум накостылили свою собственную реализацию, и другие DE тоже будут костылить. Блин, не спрашивай даже почему, вот не понравился им wlroots или элементарный NIH-синдром. В иксах, ты строго ограничен фичами иксов и это намного больше хорошо, чем плохо.