Для композитного сервера Weston (http://cgit.freedesktop.org/wayland/weston/), развиваемого проектом Wayland, представлен (http://lists.freedesktop.org/archives/wayland-devel/2013-Jan...) бэкэнд, производящий рендеринг через фреймбуфер (FBDEV). Бэкенд fbdev позволяет использовать Weston, выводя графику через фреймбуфер с участием Pixman. Обработка ввода данных производится через evdev.
Отмечается, что код имеет общие части с бэкэндом Weston для Raspberry Pi, включая evdev для работы с устройствами ввода. В данный момент работа кода протестирована только с драйвером nouveaufb на видеокартах от NVIDIA. Примечательно, что патч с поддержкой fbdev уложился в всего 800 строк. Разработка координируется на ресурсе Gitoriuous (https://gitorious.org/~pwithnall/weston/pwithnalls-weston/co...).
Новый бэкенд продолжил развитие подготовленного (https://www.opennet.ru/opennews/art.shtml?num=35782) в начале января бэкенда x11, позволяющего осуществлять программный рендеринг через X-сервер, без привязки к OpenGL и Mesa. В будущем также запланировано создание бэкенда для рендеринга с использованием KMS.
URL: http://www.phoronix.com/scan.php?page=news_item&px=MTI3Njc
Новость: https://www.opennet.ru/opennews/art.shtml?num=35878
Ну наконец-то закопают такое недоразумение как прорисовка DE через llvmpipe.
С чего это вдруг? Wayland тут вообще не при чём.
Простите, если некто желает 3D операции - тут уж увы, увы, через что-то их изображать придется.
Хачу Wayland via VGA 80x25, ну так чиста поржать. :)
> Хачу Wayland via VGA 80x25, ну так чиста поржать. :)Драйвер ascii графики хотите?)
Ну а чё$ mplayer -vo aa SomeVideo.avi;
=)
> Хачу Wayland via VGA 80x25, ну так чиста поржать. :)Так поди и напиши. Libcaca тебе в помощь.
>> Хачу Wayland via VGA 80x25, ну так чиста поржать. :)
> Так поди и напиши. Libcaca тебе в помощь.Я чё, похож на Поттеринга, - велосипеды переизобретать,
или локальный RDP, чтоб потом назвать Wayland?!
> Я чё, похож на Поттеринга, - велосипеды переизобретать,
> или локальный RDP, чтоб потом назвать Wayland?!Дарю идею: заверни граббинг экрана (ффмпегом, vlc, ...) в мплеер с этой либкакой. Получишь то что хотел в первом приближении :)
Еще один аргумент в пику тем, кто кричал "wayland нинужен, уже был framebuffer, не взлетело".
Что-то мне кажется, что разработчики сделали это вовсе не кому-то в пику, а просто для того, чтобы работало.
А он всё правильно сказал. К тому дело и идёт. Только обрастает функциями эта штука стихийно, без планирования и продуманной архитектуры. Потому что первоначально хотели сделать полторы функции а потом, как оюычно и бывает, выяснили, что в реальном мире нужны штуки посложнее. И понеслось - сетевая прозрачность, прикрученная через сжатие битмапов, декорации окон, реализованные через подтягивание софтом некоторой библиотеки, попытки реализовать ICCCM, и так далее, и тому подобное. Потом понадобятся реализации буфера (или они из иксов содрали, как переключение языков?), хитрых систем ввода...
Вот! Стихийно! С революционерами всегда так. И потому все революции обречены, так как люди движимые импульсом делают точно такие-же ошибки как и их заклятые враги. Была одна система - "мы свой, мы новый мир построим, кто был ничем тот станет всем" и на её месте водружается ещё более уродливая. Опять "мы свой, мы новый мир построим" и снова монстр. А всё потому, что когда делали революцию просто не подумали, что людям нужен будет хлеб.
> Вот! Стихийно! С революционерами всегда так.Там нет никакой революции. Граждане просто узаконили фактическое состояние дел, сделав сие менее черезж@пно. И все. Как раз возможна плавная миграция, без всяких революций. Оно базируется на том же низкоуровневом основании что и все прочее. Оно совместимо с большинством программ. Так что все можно аккуратненько и без потрясений.
> А он всё правильно сказал. К тому дело и идёт. Только обрастает
> функциями эта штука стихийно, без планирования и продуманной архитектуры.Это совершенно нормальная инженерная практика. Иксы вон уже напланировали, спасибочки. Под вга-адаптеры наверное даже ничего так было. А в XXI веке - любая программа которой надо активный вывод графики - делает его через что угодно кроме собственно иксов.
Иксы, вообще-то, продержались с 87-го года. И проблемы начались тогда, когда авторы тулкитов в новых условиях предпочли не продвигать нормальное расширение для 2D-отрисовки, а чудить с битмапами и XRender. Мотивы для этого были, не спорю, но ни разу не технические. Технически там всё было решаемо - как раз за счёт вменяемой расширяемой архитектуры.Другое дело, что на ошибках вейланда есть шанс поучиться и сделать что-то более приличное. К тому времени, глядишь, единственным языком работы с графикой останется OpenGL, и его примитивами всё и будет делаться. В общем, если таки взлетит - ждём повторения истории с HAL.
> Иксы, вообще-то, продержались с 87-го года.И вполне неплохо работают на таких устройствах, о наличии которых архитекторы Х могли только читать в фантастических романах. :-) Это, в общем, очень круто.
> И вполне неплохо работают на таких устройствах, о наличии которых архитекторы Х
> могли только читать в фантастических романах. :-) Это, в общем, очень круто.Только у математиков какие-то свои, весьма абстрактные понятия о том что такое "неплохо". Совершенно не совпадающие с понятиями простых смертных. У которых скоро экраны будут с разрешением в 4K повально, судя по всему. А вот иксы на работу с такими объемами данных как-то ну совсем не заточены. По поводу чего вывод элементарной киношки в плеере через OpenGL почему-то оказывается намного быстрее чем через иксы и их костыли. Стоит ли удивляться что возник некислый спрос на замену этого угробища? Со всех сторон. Юзерам нужна быстрая и легкая графическая подсистема. Разработикам графической подсистемы не хочется иметь дело с костылями эн-летней давности, пытающихся сделать из старикана подобие спринтера путем шпигования оного стероидами. Апликушные програмеры еще меньше хотят знать что-либо о интимных особенностях графических подсистем и особо хитровывернутых костылях которые таки необходимо подпихнуть чтобы графика выводилась с человеческой скоростью.
А вейланд для таких экранов вообще непригоден :-)Если помните, у вейланда приложение формирует буфер в памяти и отдает целиком, после чего получает новый и должно рисовать уже в нём. Вот и представьте - тот самый экран в 4К, развёрнут на полный экран браузер, в нём крытится какая-то мелкая анимашка. Эдак 30 FPS. Вот и посчитайте, какие объемы надо гонять в оперативной памяти для этого. А обновление одного региона, а не всего оконного буфера вейланд не умеет.
> А вейланд для таких экранов вообще непригоден :-)А вот это мы будем посмотреть. Само по себе копирование немеряных объемов - не есть проблема в XXI веке. Человечеством понапридумано множество замечательных технологий (по типу DMA). Они запросто гоняют гигазы из источника в назначение вообще не нагружая системный процессор. Ну, есть хардварный автомат. Ему сказали копать от забора и до обеда. Он и копает, покуда обед не наступит. Оно спокойненько себе упирается в бандвиз памяти или шины. Или куда оно там гоняло. Вот этого обычно с запасом. К том же в сях возможны эпик читы с заменой указателей и прочая - от именно копирования во многих случаях возможно отвертеться в пользу операций с указателями.
> А обновление одного региона
Вы мне что, предлагаете киношку смотреть на клочке экрана с кошкин зад чтоли? А как насчет посмотеть киношку на весь экран, с нативным разрешением? Да, с 30FPS и именно теми объемами данных. А вот выковыривать какие-то там регионы на таких скоростях - это будет интересно, да :)
Именно о бандвизе памяти и речь. Разжевываю - полноэкран на 30 FPS и разрешениях 4K это порядка гигабайта в секунду. по максимуму пропускная способность DDR3 2133 ГБ/с (из википедии).Никаких проблем, если загрузить киношкой половину пропускной способности памяти, надо - значит надо. Но вот если её загрузит какая-то мелкая декоративная анимашка в углу экрана - то это как-то странно, не находите? И именно в таком случае нужны регионы - чтобы кидать в видеопамять только обновляемый кусок, а не весь буфер окна. Но вейланд это не может.
> А вейланд для таких экранов вообще непригоден :-)Если так, то за судьбу W можно не беспокоиться. Но неужели они не дали возможность обновлять область окна?
> У которых скоро экраны будут с разрешением в 4K повально, судя по всему.Ваши слова, да богу в уши!
> А вот иксы на работу с такими объемами данных как-то ну совсем не заточены.
Думаю, что всё более-менее нормально - http://www.linux.org.ru/gallery/screenshots/8390471
Никаких жалоб что-то не видно. Ну и на ThinkPad'ах T60 с экраном по-типу Ретиновского народ тоже работает, не жалуется.> Юзерам нужна быстрая и легкая графическая подсистема.
Х Window System - быстрая и лёгкая. Ещё бы им не быть быстрой и лёгкой, если их гоняют на железе 10-ти летней давности. :-) Жрёт-то ресурсы KDE'шка.
> Иксы, вообще-то, продержались с 87-го года. И проблемы начались тогда, когда авторы тулкитов в новых условиях предпочли не продвигать нормальное расширение для 2D-отрисовки, а чудить с битмапами и XRender.С pixmap'ами.
Проблема X'ов как раз и была в том, что продукт работы глиф-рендерера -- bitmap. А он, пардон-те, монохромен. Так что никакого вам anti-aliasing'а.
У X'ов много "родовых травм". Во-первых, дао UNIX-way не надо понимать буквально: текстовый протокол между клиентом и сервером -- это уж запредельно. Зачем? Кто-то будет в текстовом редакторе vi его изучать? А сеть оно засирает весьма и весьма некисло.
Во-вторых, X'ы не умеют говорить клиенту, какая часть окна у него "попорчена" выводом других программ. И, хотя в X'ах можно отрисовывать часть окна, но по факту ваша программа должна уметь обновлять всё окно целиком. В качестве оптимизации, конечно, она может сказать XQueryExtension на тему XDAMAGE -- но XDAMAGE -- это расширение протокола. Оно может быть, а может и не быть.
В-третьих, таки да -- проблема ШГ, я её выше касался. Делать параллельный шрифтовой протокол (внутри'X'овый рендерер может работать отдельно от X-сервера -- xfs(1) для понимания), расширение, есть ли он, ну... короче, вы поняли -- XRender, быстрее и безгеморройнее. :)
В-четвёртых, нет поддержки методов ввода (XKEYBOARD -- тоже расширение, которого может и не быть. Про xmodmap ещё кто-нибудь помнит?).Ну и ещё масса говен и граблей.
С пиксмапами, сорри. Но антиалиасинги и прочее вполне можно было добавить в протокол очередным расширением, сама архитектура позволяет.Иксы вообще практически состоят из расширений, это их изначальное свойство. По факту сейчас есть только одна реализация, на которую стоит ориентироваться - X.Org, так что никаких проблем в этом плане нет, но даже если не так - требования некоторых расширений как-то менее радикальны, чем требования вейланда.
И да, спеклись именно на том, что делать по уму - это долго, требует кучи согласований с разработчиками тогда ещё живых различных версий иксов и т.п. Сейчас всё это не проблема совершенно. Можно спокойно закладываться на то, что определённая пачка расширений - стандарт де-факто.
Кстати, xmodmap воплне себе стоит у меня в .Xsession - отрубает стандартную реакцию на CAPS LOCK и подкручивает Super/Hyper. Отличная штука.
> И да, спеклись именно на том, что делать по уму - это долго, требует кучи согласований
> с разработчиками тогда ещё живых различных версий иксов и т.п.Во-во, я про это же.
> Сейчас всё это не проблема совершенно.
А вот это не факт. Дело в том, что существуют до сих пор не-X.org-реализации X'ов на особо специфичных девайсах (напр. на компьютерах, подключенных к научному оборудованию), для которых, тем не менее, выходят новые версии Application-level софта (для обработки собираемых этим девайсом данных). Ах, да. И ещё eXceed/W :)
Проблема примерно в том же, на что наткнулись TrollTech'и -- я неоднократно приводил выдержку из их README, объясняющую, почему MOC, а не изощрённое шаблонирование всего и всея, предлагаемое стандартом C++ 1999 года издания. Да потому, что не так просто найти компилятор, который бы _корректно_ поддерживал все "тонкие моменты" этого стандарта, работал бы на туевой хуче платформ и не "бажничал" на проектах размером с Qt.
Поэтому и родился концепт X12. Где убраны просто явные несуразности, ну и добавлено всего нужного.
В итоге народ останется сидеть на Х-ах? Или будет два лагеря, и из каждого навстречу другому будут лететь ка... кирпичи.
> из каждого навстречу другому будут лететь ка... кирпичи.А разработчикам - пофиг. Если посмотреть кто пилит вэйланд - так там все лица знакомые. Это троллота на опеннете будет дубинками кидаться. Вот только мнение этой троллоты разработчики иксов которые и пиляют вэйланд спросить немного забудут. В конце концов, иксовый кактус жрут они а не троллота. И им это кажется не по вкусу.
Насколько велик риск того, что вэйланд превратится в такую же свалку костылей, как случилось с Х-ами? Учитывая, как было подмечено, дикий темп развития этого протокола.
Ну если хватит ума остановиться, то всё отлично. По-моему, такой темп нормален с учётом того, что вяленд только появился и его хотят как можно быстрее допилить до рабочего состояния.
> Насколько велик риск того, что вэйланд превратится в такую же свалку костылей,
> как случилось с Х-ами? Учитывая, как было подмечено, дикий темп развития
> этого протокола.через 10-15 лет Wayland точно отстанет от реальности и его надо будет заменить на Zayland ;)))
А на ближайшие 3-7 лет очень даже позитивное решение для Linux систем.
Спасибо за ответ :) А то подавляющее большинство линуксоидов вангуют печальное будущее для вэйдланда. Можно немного успокоиться. А там видно будет.
> подавляющее большинство линуксоидовэто ты где насчитал на опннете и на лоре? так это они ради хохмы
В общем, я даже не знаю, что об этом думать. Нет, у меня, конечно, есть своё мнение, не смотря на анонимность, но тем не менее... Нехорошо получается, что каждое приложение будет отрисовывать себе рамки так, как ему захочется. Ну, не каждое приложение - так каждый тулкит. В иксах с этим нормальнее: если у меня стоят те же кеды, до рамки для всех - одни - и всё тут. А здесь... Ох, блин...
> В общем, я даже не знаю, что об этом думать. Нет, у
> меня, конечно, есть своё мнение, не смотря на анонимность, но тем
> не менее... Нехорошо получается, что каждое приложение будет отрисовывать себе рамки
> так, как ему захочется. Ну, не каждое приложение - так каждый
> тулкит. В иксах с этим нормальнее: если у меня стоят те
> же кеды, до рамки для всех - одни - и всё
> тут. А здесь... Ох, блин...Это не вопрос иксов или Вэйланда, а менеджера окон, приложений и их органихации в DE. В иксах приложение способно рисовать собственные декорации а в Вэйланде наваять декоратор.
Что касается как лучше делать, в обоих случаях есть и плюсы и минусы. В отдельном общесистемном декораторе минусы значительнее и их сложнее обойти, поэтому скорее всего такой подход массово не будут использовать. Те кто тут люто бешено жалуется, не напишут годный менеджер окон и даже декоратор, а те кто способен написать, понимают, что это ущербный подход.
Я немного нуб в некоторых терминах, поэтому хочется расставить точки над i: тулза, которая занимается рисованием обрамления для окон - это декоратор, верно? Менеджер окон, собственно, управляет перетаскиванием, перекрытием окон? Или же менеджер окон выполняет и декорации тоже? Если гнянуть на kwin, то создаётся именно такое впечатление. Weston, думаю, нельзя сравнивать с kwin, но, получается, что weston занимается лишь управлением окнами, но не их декорацией? Блиин, что-то я вообще запутался.
> Weston, думаю, нельзя сравнивать с kwin, но, получается,
> что weston занимается лишь управлением окнами, но не их декорацией?Да. Рамку и заголовок каждая программа доложна чертить сама. Результат такого поведения - http://www.linux.org.ru/gallery/7838451.png (две программы с двумя разными заголовками).
Значит, получается, это обойти практически невозможно by design?
Да всё можно. CrazyAlex, который более в теме, нежели я, утверждает, что они сделали какую-то библиотеку, чтобы рисовать заголовки.Но непонятно, зачем "идти другим путём", когда оконным системам больше 30-ти лет, и везде оконные заголовки рисует оконный менеджер централизовано (в Виндах, правда, несколько костыльно - сперва пытается отрисовать оконная процедура, но опять-таки, централизовано).
Оконная система - штука сложная. И если её архитектуру не продумать хорошенько, она в мгновение ока обрастёт костылями. Соответственно, упадёт производительность, полезут ошибки.
Именно по этому параметру можно судить об архитектуре Х - они функциональны после 25-ти лет допиливания. Это потому, что их архитектуру очень хорошо продумали.
А в Wayland костыли пошли с версии 1.0. То есть, архитектура не очень хорошая.
> Значит, получается, это обойти практически невозможно by design?Можно и нужно. Это позволит не только иметь у всех окон одинаковые декорации, но и даст возможность приложению рисовать декорации со своими особенностями и нюансами, но при этом выглядящие и ведущие себя аутентично системе.
Например кнопка Оперы и ФФ и табы Хрома в венде. В Иксах это сейчас получается костыльно и часто не соостветствует выбранной теме.
Мда, зря я возлагал на подобный стек большие надежды...
> Да. Рамку и заголовок каждая программа доложна чертить сама.С другой стороны, всякие там браузеры вечно желавшие рисовать табы в шапке окна наконец смогут это. Без необходимости очередной допиловки супер-мега-монстра.
> С другой стороны, всякие там браузеры вечно желавшие рисовать табы в шапке
> окна наконец смогут это. Без необходимости очередной допиловки супер-мега-монстра.Они и сейчас это могут. Да и всегда могли - см. древнющий XMMS.
>> С другой стороны, всякие там браузеры вечно желавшие рисовать табы в шапке
>> окна наконец смогут это. Без необходимости очередной допиловки супер-мега-монстра.
> Они и сейчас это могут. Да и всегда могли - см. древнющий
> XMMS.Нет. Тебе уже объясняли, что там декорации даже близко не похожи на остальные. Смотри картинку: http://sourceforge.net/projects/rusxmms/screenshots/129912. В лучшем случае можно навешать костылей как в Хроме, но всё равно не то. Как здесь у хрома голубой декор, а у диалога серый: http://www.htmlcenter.com/wp-content/uploads/2009/08/chrome-...
Да, я знаю, что слов ты не понимаешь пока тебя носом не ткнут, уже проходили. Вот картинки как надо: https://wiki.mozilla.org/images/6/62/Firefox-windows-7-style... http://files.myopera.com/Tamil/albums/210985/Firefox%20... http://blog.brothersoft.com/wp-content/uploads/2009/06/windo...
Сlient-side decorations. Get the facts.
Любопытно даже как ты теперь запляшешь.
> Я немного нуб в некоторых терминах, поэтому хочется расставить точки над i:
> тулза, которая занимается рисованием обрамления для окон - это декоратор, верно?
> Менеджер окон, собственно, управляет перетаскиванием, перекрытием окон? Или же менеджер
> окон выполняет и декорации тоже? Если гнянуть на kwin, то создаётся
> именно такое впечатление. Weston, думаю, нельзя сравнивать с kwin, но, получается,
> что weston занимается лишь управлением окнами, но не их декорацией? Блиин,
> что-то я вообще запутался.Менеджер может рисовать декорации, если захочет. Это по многим причинам не эффективно и с т.зр. эргономики и производительности и эстетики и архитектуры. Хотя есть и плюсы: например когда окно зависло, декорации работают бай дизайн. Но это минорщина.
Вообще зависимость окна приложения от сервера и от WM ― ключевой архитектурный фэйл иксов. Один из.
Он уже на костылях. Поинтересуйтесь, каким образом там таки собрались обеспечивать стандартные декорации.
Опишите ваш способ, не являющийся костылём.
> Опишите ваш способ, не являющийся костылём.Стандартный для современных оконных оболочек (MacOSX, Window, X Window System) - единый WM, отрисовывающий декорации 99% окон. Для одного процента программ, "желающих странного", отрисовка этого WM отключается.
с минимальной латентностью/задержкой и без демоновX11 от этого анально страдает
При чём тут Х11? Речь о недостатках архитектуры Wayland, вроде. Client-Side-Decorations - очевидный недостаток по отношению ко всем распространённым в данный момент оконным системам.
При том, что речь идет об архитектуре рисования для Linux. Ни Wayland, ни X не планируются к замене стандартного WM для Win или Mac.> Client-Side-Decorations - очевидный недостаток по отношению ко всем распространённым в данный момент оконным системам.
Так распространенных систем для Linux всего одна штука - X. Но большинство программистов не желает пользоваться Х напрямую для отрисовки декораций. Стандарт де-факто это Client-Side-Decorations через Qt или GTK. Так что W лишь реализует принятый де-факто стандарт.
> Стандарт де-факто это Client-Side-Decorations через Qt или GTK.Client-Side-Decorations - это не отрисовка оконным менеджером KWM декораций всех открытых окон с помощью API QT. Это отрисовка КАЖДОЙ программой и КАЖДЫМ открытым окном своих декораций самостоятельно.
То есть, если вы запустили KDE, поверх которого запустили программу, реализованную на Gtk, то у всех KDEшных программ обрамление окон будет одно, а у этой программы - другое. У этой программы обрамление будет отрисовано не библиотекой Qt, а библиотекой Gtk.
Пример Client-Side-Decorations вот - http://blog.martin-graesslin.com/blog/wp-content/uploads/201...
Открыто 2 (два) окна, а обрамление у них разное.
> Пример Client-Side-Decorations вот - http://blog.martin-graesslin.com/blog/wp-content/uploads/201...
> Открыто 2 (два) окна, а обрамление у них разное.... чего я и боялся. А ведь захотят же городить какие-то мегакостыли для решения этой проблемы, верно? Не всем же понравится смотреть на 3 разных рамки.
> ... чего я и боялся. А ведь захотят же городить какие-то мегакостыли для решения этой проблемы, верно? Не всем же понравится смотреть на 3 разных рамки.Скорее, оно просто не взлетит. Потому, что если есть такие очевидные абсолютно постороннему человеку косяки, то представьте, что же там найдёт специалист по графике и оконным системам.
Уже городят. Предлагается, что что-то буджет предоставлять библиотеку, которая должна загружаться каждым приложением, которое хочет иметь стандартные декорации, и затем надо дергать функции этой библиотеки - какя понял, там дажеотдельногопотокапод это нет, тупо всвоем event loop обрабатывать. Маразм, в общем.
Теперь понял. Да, это действительно мега-костыль. Так как это не планировалось изначально, как я понял. Разработчики, получается, изначально задали архитектуру: "пусть приложение само себя рисует полностью, а оконный менеджер для манипуляции окнами пусть пишется отдельно". Я правильно понял? Потом выяснилось, что каждый тулкит захочет рисовать такие рамки окон, какие ему захочется и никто и ничто не будет его спрашивать, что, как бы, не будет вливаться в унификацию оформления, а следовательно, с такими результатами нельзя будет сделать нормальное DE с единством оформления окон приложения в нём запущенных. И они решили для этого писать отдельную либу-костыль, которую будут подгружать приложения. Ужас... Действительно: как было сказано, быстро и на коленке, толком не учтя все нюансы, спроектировали вэйланд и вэстон, архитектура которого, получается, уже изначально просто кишит недостатами, по сравнению с которыми Иксы ещё неплохо смотрятся.
Елки-палки... Так вся эта затея станет в разы хуже самих Иксов за намного более короткое время.
Поправьте меня, если я что-либо не так понял. Я пытаюсь для себя подвести итоги.
> Вообще зависимость окна приложения от сервера и от WM ― ключевой архитектурный фэйл иксов. > Один из.Хотя, как пользователю линуксов, нравится тот факт, что, когда приложение зависает, с окном можно что-либо делать: перемещать, скрывать, ресайзить и пр. В винде этого делать нельзя, что немного бесит. И именно такой "виндово-оконный зависон", как я понял, будет в вэйландонском стеке.
> И именно такой "виндово-оконный зависон", как я понял, будет в вэйландонском стеке.Да. Но, думаю, навешиванием очередного костыля это можно исправить.
> Потом выяснилось
Ага. Причём как-то очень много этого, что "потом выяснилось". Хотя, казалось бы, Х есть прямо сейчас, документация по Х тоже имеется - сиди, изучай, на базе этого сделай архитектуру лучше, работающую в тех же условиях.
Но, "что тут думать - трясти надо".
> окон с помощью API QT. Это отрисовка КАЖДОЙ программой и КАЖДЫМ
> открытым окном своих декораций самостоятельно.И это замечательно.
1) Нет центральной точки отказа в виде сложного монстра который навернут до ж**ы. Отвал в одной программе и ее тулките - лучше чем отвал в глобальном графическом монстре.
2) Сожранные ресурсы будут приписаны конкретным программам, так что если некто тормозит и жрет память - его можно будет адресно пристрелить.
3) Многопроцессорность будет использоваться.Минусы - да, есть. Но не факт что они перевешивают плюсы.
А расскажи как что будет если приложение повисло. Как окошко утащить куда-нибудь за пределы экрана?
> А расскажи как что будет если приложение повисло. Как окошко утащить куда-нибудь
> за пределы экрана?Во первых Вы забыли про KISS!
Во вторых зачем его (окошко, а не грелку тузику) таскать когда есть kill.
А вот если мегакомбайн повиснет, да еще запущенный от root-а, то это да, всем сразу хорошо станет ;)
KISS - это когда один механизм делается в одном месте, а не в каждой библиотеке по-своему.
> KISS - это когда один механизм делается в одном месте, а не
> в каждой библиотеке по-своему.Да, за запуск иксовой сесси от рута надо голову отбивать отдельно. А в ином случае WM работает отобычного пользователя. Впрочем, что вы в код WM не сомтрели и так понятно - иначе знали бы,что это, в сущности, софтина очень простая и виснуть там нечему.
> виснуть там нечему.Если только это не E17! ;-) Впрочем, если WM вылетает, можно легко запустить другой, который все окна обратно подхватит.
Трындец какой-то, главное смайликов дурацких понаставить побольше.
На, читай http://blog.martin-graesslin.com/blog/2010/05/open-letter-th.../
А те кто лазил в вяленом говорят там костыль прикрутили на тему перемещение любого окна при нажатии нескольких кнопок.
какой народ?
как решат в основных дистрибутивах - так и будет
>как решат в основных дистрибутивах - так и будетКак решат в федоре, так и будет. Нет больше основных дистрибутивов.
федора такой же основной дистр как воздушный шарик - летательный аппарат
переводим. как скажет redhat - так и будет.
А что там думают хомячки мало кого волнует.
>А что там думают хомячки мало кого волнует.это у вас в винде и маке так, в линуксе всё немного иначе
> переводим. как скажет redhat - так и будет.Ну да, иди, расскажи каноникалу о том что они должны гном 3 на десктопе юзать. И глибцу вместо eglibc. И rpm вместо deb. Ну короче вы врите да не завирайтесь. Хотя с таким ником было бы странно ожидать чего-то другого.
Правда твоя, на самом деле все определяется тем как захочет покоритель космоса, если выкроит минутку - другую и не сильно будет занят биржевыми спекуляциями.
а тем временем пока аналитики спорят появилась новая RebeccaBlackOS
> а тем временем пока аналитики спорят появилась новая RebeccaBlackOSи где она в тексте новости или тут в сообщении?
да везде.
привет гудвину, в следующий раз не перепутайте что берете.
> да везде.
> привет гудвину, в следующий раз не перепутайте что берете.вы, я смотрю, каких-то веществ уже нахватали, гудвины какие-то мерещатся