Причём доказывается это утверждение на раз-два-три: достаточно написать решение квадратного уравнения.

ossxmix и выключаешь там звук.

РУКАМИ? Ещё одно подтверждение того, что линуксоиды не умеют читать.

программно

Это программно. А твой троллинг с OSS4 (кстати, он научился переживать s2disk?) это ручной труд, для автоматизации частных случаев которого когда-то придумали ЭВМ...

xorg.conf не?

А где взять события клавиатуры?

Примечание: разрешить всем работать с /dev/input == напрашиваться на кейлоггеры от левых юзеров.

Переключиться в плеер (который может быть сотой вкладкой огнелиса), нажать mute, переключиться на звонилку, ответить

Глобальные сочетания клавиш же!

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

Ну во-первых, риторический вопрос: А заниматься программированием — дело пользователя что ли?

А во-вторых, HTML — это именно и есть декларативный язык для создания оной структуры. То, что сам язык херовый и не справляется с задачей, это уже другой вопрос. Браузер и занимается тем, что ты назвал «дурным делом»: превращает логическую структуру в конкретное воплощение в виде пикселей. И с языком разметки это делать можно гораздо проще, чем заниматься интерпретацией теховой нечисти.

Можно сделать браузерам, что б если документ не корректный XML, то обработать то, что уже пришло (закрыть все открытые элементы в уме), а не как сейчас ERROR!!!!!11111 разве что.

Браузеры не осилили.

Вейландоё^Hфаны традиционно демонстрируют полную неадекватность.

Да ладно, тут с обеих сторон баррикад её демонстрируют.

Если что-то внутри огнелиса начнёт создавать глобальные сочетания клавиш

Вот ты теоретизируешь, а они возьмут и сделают. :-D

Ну во-первых, риторический вопрос: А заниматься программированием — дело пользователя что ли?

А как ещё дать задание компьютеру? Телепатические зонды пока не в ходу.

А во-вторых, HTML — это именно и есть декларативный язык для создания оной структуры.

Не, не, не не слезайте — это разметка, причём весьма посредственная. С тем же успехом можно пробелами выравнивать.

Чтобы трололо на игре словами не разводить, открываем википедию и читаем:

It provides a means to create structured documents by denoting structural semantics for text such as headings, paragraphs, lists, links, quotes and other items.

Примечание: разрешить всем работать с /dev/input == напрашиваться на кейлоггеры от левых юзеров.

Разреши работать с /dev/input только пользователю X, в чем проблема?

То есть HTML тоже программирование?

Отличия языков разметки от ЯП сам погуглишь, не маленький.

Нужна совместимость с X.Org API, очень.

Оно есть

Не нужна. За подробностями в FAQ.

Парочка цитат для Ъ

Experienced X developers: Look at the new shiny Wayland we're creating. It's better than X in every possible way.
Masses: Oh noes - you don't list network transparency as a feature. Doom, Doom, Doom.
Experienced X developers: Right, because that will be taken care of by the layer above. It's much better that way.
Masses: You can't get rid of [implementation detail] «network transparency». Doom!
Experienced X developers: Really, it's trivial. All you have to do is run an alternative compositor on Wayland that would scrape the buffers, compress them, and send them over the network. It's far more flexible than the X system, and also gives better performance. For the moment, we aren't even going to bother with this trivial detail because at the start everyone will be using X apps anyway and it will work the same. It will only matter after several years of use when native apps start being used.
Masses: I don't trust these devs. They're obviously going to screw up network transparency. I'm not sure why, i just think they will. Look at windows, it doesn't have X and it sucks.

Let's ignore the network for a moment and just try to understand how Wayland works. That'll make the network bit much easier to understand.

The Wayland protocol lets clients connect to what is essentially just a compositor and input manager. All rendering happens on the client application. The client application posts updated frame buffers to the compositor. Wayland composites all the clients onto the «display.» Wayland delivers input signals to the clients. A few other bits are also done, but that's pretty much the gist of it.

The cool bit of Wayland is that the «display» and input event sources do not at all need to actually be a physical display or OS input devices. They can easily be an X11 window. They can be a hidden surface inside a GUI app test harness that sends scripted input to the apps and records and diffs output frames. They can an offscreen buffer used for compositing over X11, which is what KWin is working on doing (so your Wayland native apps run over X11) and what Weston can already do. They can be just about anything you want, because all the protocol does is coordinate framebuffer updates and handle input events and the like. None of these new applications or special configuration require any kind of new protocol changes. The protocol already works for all of these cases, and more.

This is where networking comes in and becomes so easy. There is no need for Wayland support for networking because Wayland already does everything you'd need to support networking. Since the Wayland server/compositor can easily be any random app (which doesn't even need to have a graphical display of any kind) it's _already supported_ to just drop in any possible networked proxy or remote display system you want. Want VNC? Just write a VNC client that's a Wayland server. Want SPICE? SPICE client that's a Wayland server. Want HTML5? HTTP server with streaming WebM and WebSockets that's a Wayland server. Want something specifically optimized for per-window low-latency low-bandwidth WiFi/Internet remoting of desktop applications? Figure out that new protocol, write a client/server for it, and make the client a Wayland server. _None of these_ will require a protocol change or changes to any Wayland-based applications.

No changes to Wayland itself are needed, period. That's why the Wayland folks are saying they'll worry about it later: because they _can_, because the protocol was designed to be separate from the networking half. It does not need — nor is there any reason to even want — the networking aspect to be built into the Wayland protocol itself. The network proxy stuff hasn't appeared yet because nobody who actually does anything but whine has bothered to write one. It's not because Wayland needs some future extension or changes that are being ignored.

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

А мне нравится: я в каждом медиаплеере настраиваю глобальные сочетания. И отлично все работает: что бы я ни запустил (audacious, deadbeef, clementine) управление работает одними и теми же клавишами. Естественно, параллельно два разных плеера запускать нельзя. Конфликт выйдет.

По-моему, проще латеха может быть только plain text.

Тебе не жир надо со своего монитора вытирать, а слюни и сопли, которыми ты всё забрызгал в истерике.

Непонятным - потому что названия свойств CSS далеко не всегда логичны.

Вот я не понимаю, как можно считать простым XML и сложным латех? Это что, ГСМ?

Много букв. Можно было просто написать «Гоняйте по сети буфера в полную величину на каждый апдейт курсора в окне и не жужжите. Мы ведь всё делаем для вас.»

вяленный пока что вял для десктопа.

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

В 99% случаев таки логичны.

И всё правильно заявляет некрофилы и ораклы сами виноваты.

Потому что XML не язык программирования.

в полную величину
Ну хотите в полную величину - гоняйте в полную, кто же против?

И в самом деле - что вы сделали для сохранения Иксов, коли уж они так ценны для вас, кроме написания постов на ЛОРе?

Раскрой же, о великий мыслитель, нам, убогим, алгоритм передачи вейландобуферов не в полную величину.

На самом деле, очень легко сделать, но нужно поддержка VoIP-клиента.

LaTeX - тоже.

Латекс сложнее. Технология изготовления не столь тривиальна ☺

И в самом деле - что вы сделали для сохранения Иксов, коли уж они так ценны для вас, кроме написания постов на ЛОРе?

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

В использовании латекс проще. А в изготовлении тоже проще: сравни исходники латеха с простым техпроцессом латекса.

В общем, и здесь на вкус и на цвет все изделия разные ☺

In either case, the application must tell the compositor which area of the surface holds new contents.

The idea that even if an application passes a new buffer to the compositor, only a small part of the buffer may be different, like a blinking cursor or a spinner.

Сервер, реализующий Wayland, будет располагать информацией о том, что изменилась только определённая часть поверхности, и сможет отправлять по сети только её, не так ли?

Какой крайне интересный и содержательный ответ
Вопрос превращается... превращается... в ответ!

О да, конечно.

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

И откуда ты это цитируешь, кстати?

Так, глядишь, еще год пройдёт, и они откроют для себя, что не обязательно рендерить клиентом то, что можно из готовых кусков собрать на сервере. :-D

Алхимии еще и не такое подвластно.

Кстати, эта фича pulseaudio очень плохо гуглится, она действительно настолько полезна?

Эм. Я её нагуглил первым же запросом после того, как внезапно увидел, что оно из коробки работает в семёрке. Вещь неплохая, хотя и не необходимая. Да и в любом случае не на одной alsa же жить сейчас, а ossv4 на десктопах до сих пор является лишь темой для троллинга.

И откуда ты это цитируешь, кстати?
Последние две цитаты с офсайта. Сходите туда - там много интересно. В общем, других претензий не осталось, да?
> Так, глядишь, еще год пройдёт, и они откроют для себя, что не обязательно рендерить клиентом то, что можно из готовых кусков собрать на сервере. :-D
А что, кто-то ещё рендерит Иксами? В Кутях например уже вроде год как окончательно переключились на использование встроенного рендера, вместо иксового.

А что, кто-то ещё рендерит Иксами?

Ты не поверишь...

В Кутях например уже вроде год как окончательно переключились на использование встроенного рендера, вместо иксового.

Это исключительно проблемы кутей.

там много интересно

Вообще-то там ровно 2 странички: архитектура и faq. Но и среди них есть «интересное»:

The Wayland architecture integrates the display server, window manager and compositor into one process. You can think of Wayland as a toolkit for creating clients and compositors. It is not a specific single compositor or window manager. If you want a different window manager, you can write a new one.

Бугагашеньки.

Увы, git-сервер у них лежит, так что поговорить предметно не получится. Вся суть в сорцах, а не в писульках на сайте.

В общем, других претензий не осталось, да?

Претензия всё та же: полная неадекватность архитектуры решаемой задаче. Если разработчики этого в упор не видят, это отнюдь не делает чести разработчикам. Вообще нынче это системная проблема разработки всего опенсорса. Начиная от свистелок поттеринга, внедряемых сразбегу куда попало, и заканчивая кедами.

Ты не поверишь...
Так вы рассказывайте, не стесняйтесь! Авось под конец беседы ещё что-то новое для себя узнаете. Например то, что в случае Кутей встроенный рендеринг гораздо шустрее иксового.

franchukroman

GTK3 - нужен, в нем наконец убрали deprecated и сделали адекватные стили.

адекватные стили

ты пробовал эти стили ковырять?
это лютый северный зверюга