- Mutter (оконный менеджер)
- Полезное
- Смотреть что такое «Mutter (оконный менеджер)» в других словарях:
- Mutter linux ��� ���
- Mutter: a window manager for GNOME 3
- 500 bugs to squash
- New directions for a window manager
- Some issues with Mutter
- Accessibility growing pains
- A fresh start
- Mutter: a window manager for GNOME 3
- Mutter: a window manager for GNOME 3
- orphaned hardware
- orphaned hardware
- orphaned hardware
- orphaned hardware
- orphaned hardware
- orphaned hardware
- orphaned hardware
Mutter (оконный менеджер)
Mutter — оконный менеджер, который используется по умолчанию в рабочей среде GNOME 3. Mutter был разработан в качестве альтернативы Metacity. Mutter сочетает в себе функции композитного и оконного менеджера, базируется на плотном привлечении средств OpenGL и использует в своей работе функции библиотеки Clutter.
Логика управления окнами в Mutter полностью унаследована от оконного менеджера Metacity. Из значительных улучшений можно отметить гибкую систему расширения функциональности за счёт подключения плагинов, которые могут полностью изменить логику управления окнами и организацию оформления экрана. Mutter может использоваться как отдельный оконный/композитный менеджер, так и вступать в качестве основы для таких оболочек, как GNOME Shell или Moblin.
 Проект GNOME | ||
|---|---|---|
| Сообщество | ||
| Please consider subscribing to LWN |
Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.
This article was contributed by Koen Vervloesem
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:
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.
Theme designers will be able to use their existing knowledge of CSS rather than having to learn a complicated new format.
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:
Owen Taylor explains another new direction: Mutter will get application-aware window management. More specifically it will get knowledge about tabs:
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:
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:
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:
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 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:
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 | |
|---|---|
| GuestArticles | Vervloesem, Koen |
(Log in to post comments)
Mutter: a window manager for GNOME 3
Posted Aug 6, 2009 1:41 UTC (Thu) by ncm (subscriber, #165) [Link]
Mutter: a window manager for GNOME 3
Posted Aug 6, 2009 10:42 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
orphaned hardware
Posted Aug 6, 2009 18:53 UTC (Thu) by ncm (subscriber, #165) [Link]
orphaned hardware
Posted Aug 6, 2009 19:34 UTC (Thu) by me@jasonclinton.com (subscriber, #52701) [Link]
orphaned hardware
Posted Aug 6, 2009 22:42 UTC (Thu) by yokem_55 (subscriber, #10498) [Link]
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
Posted Aug 7, 2009 3:33 UTC (Fri) by drag (guest, #31333) [Link]
It’s just that you’ll lose the features that Mutter provides if you don’t want to use Mutter.
orphaned hardware
Posted Aug 7, 2009 8:52 UTC (Fri) by aquasync (guest, #26654) [Link]
orphaned hardware
Posted Aug 7, 2009 15:21 UTC (Fri) by cortana (subscriber, #24596) [Link]
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
Posted Aug 7, 2009 18:36 UTC (Fri) by me@jasonclinton.com (subscriber, #52701) [Link]
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.
Источник
