Mutter linux что это

Обновлено: 02.07.2024

GNOME 3 is the GNOME project's ambitious effort to take its desktop into the future. A key component of the desktop is the window manager, which defines much of the overall feel of the system. Thomas Thurman, the maintainer of Metacity—GNOME's current window manager—is looking ahead to "Mutter" as the window manager for GNOME 3. Metacity 2 will gradually be phased out in favor of Mutter; in GNOME 2.28 it will be an alternative window manager, while in GNOME 3, it will take over the reins from Metacity.

The GNOME Shell, responsible for the new user experience in GNOME 3, runs as a plugin for Mutter. Started as a fork of Metacity, Mutter uses the Clutter toolkit. Clutter does its rendering using OpenGL or OpenGL ES, so using it in Mutter makes hardware acceleration for the window manager possible. Meanwhile, Clutter has just announced its 1.0 release.

500 bugs to squash

With Mutter becoming the new kid in town for GNOME 3, Metacity 2 will not be actively developed any more, except for bug fixes. This makes Mutter essentially Metacity 3. Of course people who would like Metacity 2 to continue because they don't like the Clutter backend may fork it, but it remains to be seen if that would happen. On his blog, Thurman welcomes anybody to do that and offers them " as much support in doing so as possible ", but he will switch to working on Mutter himself. Besides all the work that has been done over the years on Metacity, Mutter has 12 contributors with at least three commits. The project is maintained by Owen Taylor and Tomas Frydrych.

This fork, however, has one big problem: what to do with the more than five hundred bugs open against Metacity? As Thurman describes on his blog, " this is more than one maintainer can humanly tackle. " The simplest "solution" is to close them all, a mistake that GNOME has made in the past with the switch from GNOME 1.4 to GNOME 2. Jamie Zawinski called this the cascade of attention-deficit teenagers model.

Thurman proposes a better solution: work through all the bug reports, then decide what to do with each bug. Enhancement requests will not be fixed, unless Mutter or GNOME Shell could use it. Bugs that can be reproduced in Mutter should be reassigned. Bugs that are already fixed in Mutter, such as enhancement requests, should be marked as already fixed. Thurman kindly asks his readers to help him with this painstaking work, for which no volunteers seem to have stepped up yet.

New directions for a window manager

The development of GNOME 3 seems to be bringing new ideas from many different directions. Thurman has been doing some investigation into switching to a CSS-based format for Metacity themes; as Mutter is just the new incarnation of Metacity, many of these considerations directly carry over into Mutter:

I am convinced that the current theme format is far too complicated (or, it could be said, far too powerful) for the job it does. Designing window border themes is not a very complicated matter, but the current format makes it complicated through requiring complicated algebraic expressions for placement.

Thurman is proposing a switch to CSS, or at least the use of CSS as an alternative format. He sees several advantages of this approach:

    The Metacity/Mutter developers will be able to use existing libraries for layout rather than doing it all with custom code in the window manager.

Thurman is also imagining a theme designer, with a simple mode that is a wizard: it would ask the user a series of questions and would then produce some CSS code. An advanced mode would let the user edit each CSS rule individually, and reflect the changes on the screen. He is also working on a wiki, which he'll announce soon, that allows users to enter CSS and render it to an image of the window borders:

The idea here is that people who like to play with theme design are not necessarily the same people who like to build experimental software, so this lets them test it out using only a web browser.

Owen Taylor explains another new direction: Mutter will get application-aware window management. More specifically it will get knowledge about tabs:

Dave Jordan is working on a GNOME Shell Google Summer of Code project to let applications export information about their tabs to Mutter via window properties. This will allow, for example, switching directly to a specific web browser tab, rather than switching to the window, then switching to the tab.

Another developer, Sam Hoffstaetter, is working on letting the user group together arbitrary windows as tabs, something that so-called tabbed window managers offer. Each application would think it had multiple windows open, but the user would see them as tabs. The reasoning, which your author is very sympathetic to, is as follows:

Being part of the window-manager, every application would make use of tabs without having to re-invent them specifically for that application. It has always struck me that tabs were something that belonged into the window manager, not in browsers, terminals, editors, etc.

Some issues with Mutter

Interesting as the new directions may be, some people fear that Mutter will not run on older hardware. For example, the Sugar developers didn't choose Mutter, and went for Metacity instead, exactly because of this fear. However, Taylor puts that in perspective:

Our target for Mutter is to provide a good GL-based compositor. This does exclude machines, like the first generation XO, that have no 3D hardware. Almost any desktop or standard laptop built within the last 5 years has sufficiently good graphics.

Another fear that has been expressed is that Mutter will be too tightly coupled with GNOME 3. As GNOME Shell is a Mutter plugin, it depends on it, so users will not be able to use another window manager with GNOME Shell. According to Taylor, this integration is not coincidental but by design. For example, supporting Compiz instead of Mutter would require a window management abstraction layer that " greatly increases the amount of work ".

However, this approach is problematic for some use cases, as Sam Spilsbury, one of the Compiz developers, pointed out a few months ago:

If users were to use compiz with GNOME, they would lose a significant chunk of essential functionality. This is the dilemma I am sure a lot of other desktop-agnostic window managers are facing as well. It would essentially mean that users _must_ use your window manager in order to use their desktop as normal.

Of course it will perfectly be possible to create a GNOME desktop using another window manager, but then the user would miss out on the new desktop experience of GNOME Shell. For example, users will not be able to swap GNOME's window manager with a flexible window manager such as xmonad and still leave all GNOME functionality intact.

Accessibility growing pains

The fact that GNOME Shell and Mutter use Clutter directly makes support for accessibility features such as AT-SPI (Assistive Technologies Service Provider) tricky, because Clutter has no accessibility support at the moment. GTK applications, on the other hand, have ATK (Accessibility Toolkit) which talks with the AT-SPI daemon. However, there's no inherent reason that a switch to a Clutter-based composited user interface should pose any problem for accessibility. The switch in toolkits will need a certain amount of reimplementation. That said, Taylor maintains that some accessibility features such as good magnification could become much easier in Mutter.

An active project to provide accessibility interfaces for Clutter is Cally (the name stems from Clutter + a11y), originally funded by Nokia that uses Clutter in Maemo 5. The main developer, Alejandro Piñeiro Iglesias, explains the work he has done:

Cally implements Gnome's ATK interfaces for the basic Clutter objects, but if you are using a custom Clutter object with extra functionality in your application, probably extra accessibility support would be required, like HAIL was required to implement the extra accessibility support for Hildon widgets.

Cally would be useful to implement accessibility support in Mutter and GNOME Shell, but Iglesias says he should check the code first and see what he needs to implement and how. He presented Cally [PDF.GZ] at the recent Gran Canaria Desktop Summit.

A fresh start

According to Taylor, Mutter is not that exciting in isolation, but it is meant to provide a platform for building exciting user interfaces like Moblin and GNOME Shell: " I'm personally pretty interested in getting applications and the compositor properly synchronized so the user sees everything drawn as smoothly and cleanly as possible. " Thurman is excited about the opportunity to get a fresh start and rethink how to interact with the user:

We have been working for ten years in a mindset which is now, of course, ten years old. There's only so far you can go in a purely evolutionary line of development. That said, I'm very glad the existing Metacity codebase is being integrated into Mutter and not thrown away.

The new directions of CSS-based themes and application-aware window management finally make GNOME's window manager more than a dull but necessary component. However, the developers have made some decisions under the hood that will not be popular in some circles. There is no fallback option for those that cannot or do not want to use compositing, and the integration of GNOME Shell with Mutter shuts out alternative window managers. But maybe this is the price that must be paid for innovation.

Index entries for this article
GuestArticlesVervloesem, Koen

(Log in to post comments)

Mutter: a window manager for GNOME 3

Both my desktop and my laptop have very modern Nvidia video chips, operated with the "nv" X driver. They get about 0.5 frames/s in Celestia, but work fine doing everything I use them for, including driving a 1920x1200 monitor. Is Gnome abandoning me? Or are they assuming Nouveau will be mature before Mutter is, and abandoning everybody else without GL hardware support? Or might Mutter have a mode/theme that uses only GL features that can be faked efficiently?

Mutter: a window manager for GNOME 3

Nouveau will likely mature in that time. It is the default in Fedora 11 already and will get KMS support in the next release. Red Hat also has a full time developer working on it.

orphaned hardware

So your expectation is, "abandoning everybody else without GL hardware support"?

orphaned hardware

There is no one who will be running GNOME 3 (currently scheduled for Spring 2010 at the earliest) who will not have GL hardware. There simply isn't any chip out there that doesn't do GL at some level. Even my three year old smartphone has a 3D accelerator. If the Linux driver situation with regard to the only three chip families (Intel, NVidia and ATI) lacks 3D support, that should be considered a bug. Hardware GL is now as mandatory as 2D acceleration of scrolling a browser web page--you can scroll a web page without 2D acceleration (say on the VESA driver) but it's slow and painful.

orphaned hardware

The hardware universe is unfortunately a little broader than just nVidia, intel, & ATI/AMD. Via/S3 still produce embedded graphics chipsets as does Imagination Tech(PowerVR).

The PowerVR based GMA500 chips that Intel is selling right now have rather poor drivers, and the prospects for improving them are quite poor as documentation won't be released and nouveau style reverse engineering will take quite a long time.

Via has released some documentation on their chips, but from cursory observation, the OpenChrome folks don't have much in the way of developers to work on getting the drivers up to snuff.

Nouveau itself is improving, but by the time they can offer solid support for the chips that are shipping now, nvidia will have released their new DirectX11 chips that will likely require a substantial amount of new reverse engineering work.

Virtualized environments are just now starting to get decent 3d support, and properly working compositing in virtualized environments is still a ways away.

This is not to mention there are situations where disabling compositing is desirable because of problems that applications experience when they are composited. For instance, many windows applications running under wine, crawl to a halt under compositing and lord knows if those problems can ever be fixed.

My point is not that Gnome3 shouldn't be designed to heavily take advantage of compositing, but that it if it does, it should provide some graceful fallbacks that doesn't totally gut the functionality of the environment when compositing doesn't work as expected.

orphaned hardware

I seriously doubt that Gnome is going to break compatibility with other Window managers like Open Box. Could you imagine breaking GTK applications unable to run under KDE or whatever?

It's just that you'll lose the features that Mutter provides if you don't want to use Mutter.

orphaned hardware

Interesting point regarding virtualised hardware. At work almost all interaction we have with our linux boxes is through NX, so it seems Gnome 3's not going to be usable for that either.

orphaned hardware

I hope that the drivers for my laptop get better by the time I'm forced to start using this new window manager.

18 months ago, I bought a laptop with an Intel GM965 video card. This is supposed to be one of the amazing Intel graphics cards that "just works". It has not lived up to this expectation. Currently I can run stellarium, but celestia and anything based on clutter runs at a pitiful 1 frame per 3-4 seconds, when they are lucky to run at all, rather than causing X to segfault.

Now that Intel's newer graphics cards have gone all proprietary, I doubt this situation will ever improve.

orphaned hardware

Second, something about your driver situation is horribly, horribly wrong. You need to fix it; the 965 has stellar support and performance is two orders of magnitude better than what you are getting.

Third, a netboot graphics chip, so far, shipped in two netbooks is not the future of Intel graphics. Larabee is. Google it.

Last, just speculation but by the way in which the TTM/GEM has been developed, I suspect that we'll see OpenCL (yes, CL, not GL) available in some officially supported fashion on Linux on Larabee in the form of a 100% open-source driver before the end of 2010.

orphaned hardware

Приветствую! Копаясь в черновиках, я обнаружил старую заготовку для статьи, которую собирался написать несколько месяцев назад. К сожалению жизненные (и не только) обстоятельства не позволили это сделать вовремя. Но сейчас я наконец нашёл время, и сегодня мы поговорим о нескольких оконных менеджерах в популярных графических окружениях для Linux. Я подробно рассмотрю функции оконного менеджера, функционал, напишу о так называемых композитных оконных менеджерах и так далее. Надеюсь будет интересно всем. Начнём.

Оконный менеджер - это программа, которая управляет окнами приложений в системе. А именно: осуществляет позиционирование окон на экране, отвечает за изменение их размера, фокусировку и прочее. При этом оконный менеджер работает поверх существующей оконной системы. В простейшем случае, оконный менеджер просто управляет окнами и взаимодействием с ним оборудования ввода, и не делает с ними ничего другого. При этом нагрузка за отрисовку ложится на центральный процессор (так называемая программная отрисовка). Некоторые оконные менеджеры, помимо управления окном, могут отрисовывать тени на его гранях, добавлять различные анимации, плавности, полупрозрачности и так далее. В этом случае, оконный менеджер является композитным. Одной из важнейших (но необязательных) функций композитного оконного менеджера является задействование для отрисовки окна возможностей видеокарты, как правило посредством OpenGL. Тем самым увеличивая качество отрисовки и значительно снижая нагрузку на центральный процессор. Функционал композитного менеджера может быть как встроенным в оконный менеджер, так и являться отдельной программой. Часто отрисовку окна через композитный оконный менеджер называют просто - композитингом. Если вы хорошо знакомы с Windows, то вот пример из Windows 7: когда в ней отключены эффекты Aero, отрисовка ведётся силами центрального процессора. Нагрузка на видеокарту меньше, однако при воспроизведении видео на экране появляются артефакты, известные как тиринг (когда кадры меняются слишком быстро и посередине видно прозрачную мерцающую полосу).


Когда эффекты Aero включены - отрисовка ведётся силами видеокарты. Что становится очевидным, так как появляются анимации появления и сворачивания окна, полупрозрачности и так далее.


Однако, композитинг имеет и обратную сторону. При отрисовке рабочего стола силами видеокарты, частота кадров в секунду синхронизируется с частотой монитора (как правило 60 кадров в секунду, что соответствует стандартным 60 герцовым мониторам), поэтому в играх частота будет несколько ниже, так как будет идти двойная синхронизация кадра. В тяжёлых случаях - производительность игры может упасть вдвое. Поэтому часто можно встретить рекомендации отключать графические эффекты при запуске игр (к примеру выключать тот же Aero в Windows 7). Вернёмся непосредственно к Линуксу. В данный момент доминирующей графической подсистемой в Линуксе является Xorg (иксы). И работа оконного менеджера в ней точно такая, какой я описал её выше. При этом функционал композитинга не был изначально в Xorg, и его реализовали значительно позже, потому композитный менеджер работает там как-бы сбоку. В общем случае, получается весьма толстый бутерброд различных слоёв, через который происходит отрисовка картинки.

В большинстве случаев для пользователя это не важно. Но вот в играх это даёт ощутимые ограничения. Сейчас же на смену Xorg идут две графические подсистемы - Wayland и Mir. Первый не привязан к какому-либо дистрибутиву или графической оболочке, в то время как второй разрабатывается для Ubuntu и её графической оболочки Unity, и уже работает в мобильной редакции Ubuntu. О Mir поговорим в отдельной статье. Что же касается Wayland - в нём отсутствуют привычные понятия оконного и композитного менеджера. В нём есть только композитор, который и производит все операции над окнами, без лишних прослоек. Отрисовка приложения при этом ложится на программный инструмент (тулкит), на котором оно написано. Например Qt, или GTK. Это так называемая отрисовка на стороне клиента. В случае же если отрисовка окна идёт непосредственно в Wayland-композиторе, то это называется отрисовкой на стороне сервера. В случае отрисовки на стороне клиента, заголовок окна приложения, его внешний вид и прочее целиком ложится на разработчика приложения. В результате может случиться так называемый "эффект Windows": если в приложение не заложен функционал изменения размера окна, то окно приложения будет всегда фиксированного размера. Пример окна с декорацией заголовка на стороне клиента (обратите внимание на кнопки управления приложением в заголовке окна):


Этот функционал реализован в GNOME. В KDE же используется отрисовка на стороне сервера, в результате все окна будут иметь одинаковый заголовок и легко меняться в размере:



Кстати, если запустить приложение с CSD (Client-Side Decorations) в оконном менеджере, не поддерживающем отрисовку на стороне клиента - приложение получит два заголовка:


CSD кстати говоря, оказался довольно удачным решением. Настолько удачным, что его взяла к себе сама Apple:


Wayland уже работает в автомобильных ОС, в мобильных операционках Tizen и SailfishOS, и много где ещё. Философия Wayland - "Каждый выводимый кадр должен быть идеальным". И это действительно так. Отрисовка в Wayland по качеству превосходит таковую в Xorg (к примеру в Wayland в принципе невозможен тиринг), плюс ко всему - в Wayland сильно затруднено создание кейлоггеров (перехватчиков клавиатурных нажатий), что положительно сказывается на безопасности. Однако Wayland пока не поддерживается фирменными проприетарными драйверами Nvidia и AMD, что сильно затрудняет его введение по умолчанию в дистрибутивах Linux. К вопросу поддержки его Линуксовыми графическими оболочками мы вернёмся чуть позже. Говорить на эту тему можно очень долго, потому предлагаю перейти непосредственно к обзору оконных менеджеров в популярных графических окружениях в Linux.

Metacity - оконный менеджер ныне покойной графической среды GNOME 2. Пришёл на замену использовавшимся там Sawfish и Enlightenment. Отличается весьма скромным потреблением ресурсов. Поддерживает простой программный композитинг (отбрасываемые тени, прозрачности, предпросмотр окон). Изначально был написан на GTK+ 2, позже был переписан на GTK+ 3, что сделало возможным его использование в GNOME 3.0-3.8. В настоящее время является частью проекта GNOME Flashback, ипользуется в графической среде Cinnamon для запуска на оборудовании, не поддерживающим аппаратное ускорение графики, а также поставляется в качестве опции в Linux Mint MATE и UbuntuMATE.


Mutter - дальнейшее развитие Metacity для GNOME 3. Mutter является полностью композитным менеджером, для отрисовки 2D задействует высокопроизводительную библиотеку векторной графики Cairo, а для отрисовки 3D - Clutter, который использует для ускорения OpenGL. Работа оболочки GNOME Shell реализована в виде плагина для Mutter, в результате чего задействуются все возможности этого оконного менеджера во всём функционале GNOME 3. Начиная с GNOME 3.10, работа среды без Mutter невозможна. Mutter также является оконным менджером с наиболее полной и законченной поддержкой Wayland, отрисовка ведётся на стороне клиента (клиентом выступает библиотека GTK+ 3). Функциональность Mutter может расширяться с помощью плагинов. Mutter нельзя назвать легковесным оконным менеджером, и он абсолютно не годится для старого и слабого оборудования.

Muffin - форк Mutter от разработчиков графического окружения Cinnamon. Разрабатывается командой разработчиков Linux Mint. Muffin унаследовал многие функции Mutter, для отрисовки также задействует Cairo и Clutter. Однако не имеет поддержки Wayland (разработчики пока не считают его готовым для применения), а также абстрагируется от возможностей GTK+ (если релизы Mutter привязаны к релизам GTK+, то Muffin может собираться с любой версией GTK+, не ниже минимально поддерживаемой). В отличии от Mutter, Muffin почти вдвое меньше потребляет оперативной памяти, а также меньше нагружает видеоподсистему, что делает применение Cinnamon идеальным для бюджетных ноутбуков. Функционал также расширяем за счёт плагинов.

Marco - форк Metacity от разработчиков графического окружения MATE. Использует те же принципы отрисовки окон, программный композитинг и так далее. Может быть заменён на Metacity или Compiz.





Xfwm4 - стандартный оконный менеджер графической среды Xfce. С версии 4.2 обзавёлся программным композитингом. Данный оконный менеджер весьма легковесный, простой и может применяться не только в Xfce, но и, например, в MATE. В настоящее время разработчики портируют его на GTK+ 3, а также реализуют поддержку отрисовки через OpenGL. Может быть заменён на Compiz, Metacity или Marco.


Kwin - один из самых полнофункциональных, стабильных и гибких оконных менеджеров в Linux. Является стандартным для графической среды KDE. Начиная с KDE 4, стал полностью композитным, поддерживает многие эффекты из Compiz, может задействовать для отрисовки OpenGL 2.0, 3.1, OpenGL ES или отрисовку через расширение Xrender, способен блокироваться полноэкранным приложением (например игрой, увеличивая тем самым производительность), имеет широкие возможности настройки эффектов, анимации, а с версии 5 - имеет поддержку Wayland, отрисовки через расширения EGL (вместо стандартного интерфейса GLX), и многое другое. В KDE 4 может быть без проблем заменён на Compiz. Kwin написан на Qt, и задействует многие возможности этого фреймворка. Но если GNOME практически прибит гвоздями к GTK+ 3, разработчики которого всё время ломают его API с новыми релизами, то в Qt ситуация во много раз лучше, и выпуски KDE не привязаны жёстко к выпускам Qt. В аварийных ситуациях, Kwin показывает потрясающую стабильность - он будет автоматически переключать режимы отрисовки, в случае проблем с видеодрайвером, будет перезапускаться, но не прекратит отрисовку. Также Kwin, при всём своём функционале, весьма легковесен (в сравнении с Mutter и отчасти Muffin), что делает его пригодным к применению на слабых ноутбуках, нетбуках и подобном.




Compton - композитный менеджер, форк Xcompmgr. Не является оконным менеджером, а просто дополняет существующий функционалом композитного. Часто применяется в паре с Openbox, Metacity и Marco. Эффектами не богат, но наиболее популярные, такие как прозрачности, тени, анимации, плавные переходы и, конечно же, отрисовка через OpenGL, реализованы в полной мере. Также поставляется как опция в Linux Mint MATE и UbuntuMATE.


Openbox - популярный суперлегковесный оконный менеджер. Не имеет в себе функционала композитного, даже программно. Является стандартным оконным менеджером в окружениях LXDE и LXQt. Может быть заменён на любой другой, как и использоваться для замены во многих окружениях, например MATE и Xfce.



Разумеется это далеко не все доступный в Linux оконные менеджеры. И в будущем я напишу как создать своё собственное графическое окружение из разных компонентов. Некого монстра Франкенштейна, сшитого из разных кусков :) Если есть пожелания - пишите в комментариях.

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

Оконные менедежры есть только в Xorg. Эквивалент оконных менеджеров в Wayland называется композиторы, потому что они также работают как композитные менеджеры окон.

Contents

Обзор

Оконные менеджеры работают в роли клиентов оконной системы X, которые управляют внешним видом и поведением прямоугольных фреймов ("окон"), где отображаются элементы интерфейса графических программ. Они добавляют фрейму рамку, панель заголовка, возможность изменять его размер и т. д., а также часто предоставляют дополнительную функциональность — например, создают специальные области на экране для "приклеивания" виджетов (dockapps), как Window Maker, или позволяют объединить несколько приложений в одном окне, переключаясь между ними с помощью вкладок, как Fluxbox. Некоторые оконные менеджеры даже включают в свой набор простые утилиты вроде меню запуска программ или графического инструмента для настройки самого менеджера.

Спецификация Extended Window Manager Hints от X Desktop Group создана и используется для того, чтобы позволить разным оконным менеджерам единообразно взаимодействовать с сервером X и другими клиентами.

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

Другие оконные менеджеры предназначены для независимого использования, что даёт пользователю полную свободу выбора других приложений, которые будут использоваться. Это позволяет пользователю создавать более легкую и настраиваемую среду, адаптированную для их собственных нужд. «Дополнения» (значки, панели и т.п.) при необходимости добавляются сторонними приложениями.

Некоторые независимые оконные менеджеры можно использовать для замены стандартного оконного менеджера в среде рабочего стола; аналогично, некоторые DE-ориентированные оконные менеджеры можно использовать независимо.

Перед установкой оконного менеджера необходимо установить и настроить сервер X. Подробную информацию вы сможете получить на странице Xorg.

    (также плавающие) оконные менеджеры следуют традиционной метафоре рабочего стола, которая используется в коммерческих операционных системах вроде Windows и macOS. Окна отображаются подобно листкам бумаги на столе, накладываясь и перекрывая друг друга. Список статей о стековых оконных менеджерах смотрите на странице стековые оконные менеджеры. (тайловые) оконные менеджеры располагают окна на экране в виде плиток (фреймов) так, что они не перекрывают друг друга. Как правило, фреймовые оконные менеджеры подразумевают активное использование клавиатуры для управления окнами, и имеют слабую поддержку мыши (либо не имеют ее вовсе). Фреймовые оконные менеджеры могут предлагать набор стандартных расположений фреймов или позволять задавать их вручную. Список статей о фреймовых оконных менеджерах смотрите на странице фреймовые оконные менеджеры. оконные менеджеры позволяют динамически переключаться между двумя режимами — стековым и фреймовым. Список статей о динамических оконных менеджерах смотрите на странице динамические оконные менеджеры.

Сравнение популярных оконных менеджеров вы можете найти на страницах Сравнение тайловых оконных менеджеров и Wikipedia:Comparison of X window managers.

Читайте также: