Mutter: a window manager for GNOME 3

August 4, 2009

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:

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.

Theme designers will be able to use their existing knowledge of CSS rather than having to learn a complicated new format.

CSS's box model is far more amenable to a simple drag-and-drop editor program than Metacity's current expression-based system.

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
GuestArticles	Vervloesem, Koen

to post comments

Mutter: a window manager for GNOME 3

Posted Aug 6, 2009 1:41 UTC (Thu) by ncm (guest, #165) [Link] (11 responses)

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

Posted Aug 6, 2009 10:42 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (8 responses)

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

Posted Aug 6, 2009 18:53 UTC (Thu) by ncm (guest, #165) [Link] (7 responses)

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

orphaned hardware

Posted Aug 6, 2009 19:34 UTC (Thu) by me@jasonclinton.com (subscriber, #52701) [Link] (6 responses)

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

Posted Aug 6, 2009 22:42 UTC (Thu) by yokem_55 (subscriber, #10498) [Link] (2 responses)

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

Posted Aug 7, 2009 3:33 UTC (Fri) by drag (guest, #31333) [Link]

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

Posted Aug 7, 2009 8:52 UTC (Fri) by aquasync (guest, #26654) [Link]

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

Posted Aug 7, 2009 15:21 UTC (Fri) by cortana (subscriber, #24596) [Link] (2 responses)

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

Posted Aug 7, 2009 18:36 UTC (Fri) by me@jasonclinton.com (subscriber, #52701) [Link] (1 responses)

First, no one will force you to do anything.

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

Posted Aug 10, 2009 12:41 UTC (Mon) by kingdon (guest, #4526) [Link]

If you want to google it, spelling it "Larrabee" should work better.

Mutter: a window manager for GNOME 3

Posted Aug 6, 2009 12:21 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses)

I suppose if all it's doing is drawing rectangular window borders in the same way that people have for the last thirty years, then software OpenGL will be easily fast enough to do it.

Mutter: a window manager for GNOME 3

Posted Aug 7, 2009 4:11 UTC (Fri) by drag (guest, #31333) [Link]

EXACTLY.

OS X used composited desktop with NO acceleration AT ALL for a long time.

They didn't have acceleration until 'Quartz Extreme' came out. You know what the hardware requirements were for GPU driven compositing?

* AMD (ATI) Radeon, AGP-based, 16MB VRAM minimum, or better
* NVIDIA GeForce2 MX, 16MB VRAM minimum, or better

OS X 10.0 came out over EIGHT YEARS AGO with a software-driven composited desktop. This thing ran fine on PowerMAC G3 with 266mhz processors. I know, because I had to set them up for a part-time job I had at the time. (as long as you had enough RAM)

Composition is a GOOD thing.

Mutter: a window manager for GNOME 3

Posted Aug 6, 2009 2:36 UTC (Thu) by yokem_55 (subscriber, #10498) [Link] (8 responses)

I'm amazed that gnome is going all in on requiring a system to be cabable of gl compositing. The
approach that KDE has with kwin seems much more optimal: Provide a robust gl compositing
mode that offers the "full experience" along with graceful fallbacks to xrender compositing (great
for chips that have good EXA support, but poor opengl drivers) and to still offer a solid user
experience with compositing completly disabled. While the driver situation has much improved
since Compiz and KDE4's kwin were first showing up, there are still a lot of problem areas, and if
Gnome 3 is going to require GL compositing outright, I have a feeling there will be A LOT of
pushback.

Mutter: a window manager for GNOME 3

Posted Aug 6, 2009 3:04 UTC (Thu) by quotemstr (subscriber, #45331) [Link] (7 responses)

I for one neither need nor want compositing. Between the shell being part of the window manager, removing icons from menus, and requiring 3D hardware for basic desktop work, GNOME is heading in a disturbing (yet all too familiar) direction.

Mutter: a window manager for GNOME 3

Posted Aug 6, 2009 15:57 UTC (Thu) by drag (guest, #31333) [Link] (6 responses)

You do realize that in a very short time that newer computers will have no 2D engine at all for acceleration?

Whether anybody likes it or not even your 2D APIs will need to be rendered using a 3D engine for any sort of good performance. So I don't see a problem with taking advantage of it to improve usability.

The R200 ATI graphics engine was released in 2001. The early GMA chips for Intel stuff was released in 2004 or so...

So most average computers sold in the past 7-8 years can support good-enough 3D graphics to support a composited desktop. Even low-end machines made in the past 3-5 years or so can support composited desktops just fine.

Hell back when OS X was first released it had a composited desktop and it had no acceleration at all and it was fine to use.

Mutter: a window manager for GNOME 3

Posted Aug 6, 2009 16:36 UTC (Thu) by quotemstr (subscriber, #45331) [Link] (5 responses)

You realize that current cards still accelerate 2D operations just fine, right? My point is that graceful degradation is a critical property for a robust system to have.

Oh, and try to use a composited desktop on an otherwise perfectly-good Matrox G450: it crashes all over the place. Why should someone have to give up this perfectly good generic dual-head 2D VGA (the 3D isn't worth mentioning) card just because someone can't be bothered to write a UI without going through Composite and OpenGL?

Mutter: a window manager for GNOME 3

Posted Aug 6, 2009 22:05 UTC (Thu) by me@jasonclinton.com (subscriber, #52701) [Link]

s/perfectly-good/complete shit/g

Mutter: a window manager for GNOME 3

Posted Aug 7, 2009 3:39 UTC (Fri) by drag (guest, #31333) [Link] (2 responses)

Why should Gnome hold back developing and improving it's software to take advantage of modern computers because some people use older, poorly supported hardware?

If they/you/whoever does not want to run decent hardware then you should be prepared to sacrifice having the latest and greatest features. It's not like I am going to try to run a dozen virtualized environments from my netbook or whatever.

Mutter: a window manager for GNOME 3

Posted Aug 8, 2009 20:00 UTC (Sat) by quotemstr (subscriber, #45331) [Link] (1 responses)

I'm not asking for the latest and greatest. I'm asking for basic functionality on basic hardware without having to use stale software. The latest Linux kernel will still run on a 486SX, although what you can do with it will be limited. Why shouldn't the same apply to graphics chipsets?

Mutter: a window manager for GNOME 3

Posted Aug 8, 2009 20:06 UTC (Sat) by jordanb (guest, #45668) [Link]

Because people who work on graphical interface are mostly attention deficit teenagers who still see their computers as video game consoles that also do some other boring stuff that must be made BETTER by making the windows wobble and spin.

And anyone who doesn't see the point in getting graphics cards that cost more than the rest of the system and installing proprietary pound-me-in-the-ass drivers from nVidia are useless Luddites who can go frig off as far as they're concerned.

Mutter: a window manager for GNOME 3

Posted Aug 8, 2009 9:08 UTC (Sat) by Los__D (guest, #15263) [Link]

Don't expect the rest of us to wait, just because YOU want to use old junk.

It's 9 years old, use something that was made for that time.

(Yes, I do realize that it was a marvelous card once. It is no more)

Mutter: a window manager for GNOME 3

Posted Aug 6, 2009 6:16 UTC (Thu) by aleXXX (subscriber, #2742) [Link] (1 responses)

Seems the Gnomies like German nowadays: Mutter, Zeitgeist, let's see what
comes next :-)

Alex

Mutter: a window manager for GNOME 3

Posted Aug 9, 2009 20:29 UTC (Sun) by Felix.Braun (guest, #3032) [Link]

Actually "mutter" also parses as an english verb.

Mutter: a window manager for GNOME 3

Posted Aug 6, 2009 7:41 UTC (Thu) by kalle (guest, #548) [Link]

To me this seems to indicate a commitment to actually providing an interesting new environment instead of just rewriting or replacing a few components. Exciting!

Mutter: a window manager for GNOME 3

Posted Aug 6, 2009 9:02 UTC (Thu) by mjthayer (guest, #39183) [Link] (2 responses)

The tabs-in-the-window-manager thing sounds like a very good idea to me. Can someone explain to me though, why Gnome shell needs to be so tightly integrated with the window manager? And does the OpenGL rendering have to be such a problem, or can things not just fall back to fast paths, which will work fine on legacy hardware, when no special transformations, rotations or things are in use?

Mutter: a window manager for GNOME 3

Posted Aug 6, 2009 12:02 UTC (Thu) by iq-0 (subscriber, #36655) [Link] (1 responses)

Gnome shell effectively does desktop management (switching and zooming of desktops) at it's core. Virtual desktops however are merely an illusion created by a window manager.

Furthermore gnome shell seems to make heavy use of zooming, which in software is extremely expensive, but zooming of tiles in opengl comes almost for free.

One could come up with some mediocre half blood that would emulate this using no opengl, but that would mean the tricks like "taking a snapshot of a virtual desktop and scaling it in software". This couldn't be done fluently and can't do real-time updates giving it a very amateuristic and uncomfortable feeling. And this has to be made, tested and maintained practically forever.

The alternative (a good alternative for non-opengl system) would be how gnome 2 does it. That is: use a window manager that does simple window management and simple virtual desktops. Many window managers supply this (including the simple taskmanager and other panel features).
And you pager, menu, systray etc. are just undecorated windows that stick to the sides of your viewport. Nothing is stopping anybody from using them even if they are using the gnome shell (they can be combined if you really want to).

So it simply comes down to: Gnome 3 is shipping a opengl based default look and feel for it's desktop environment. Some people can't or don't want that. The only thing they (or some distribution for that matter) has to do is create another configuration that don't use these features and that could easily serve as a alternative default. This would probably depend on some non-main gnome applications, but frankly, hardly anybody uses the raw main gnome set of applications, they use their distributions version of them. Which ofcourse don't care if they depend on some non-main gnome package :-)

Mutter: a window manager for GNOME 3

Posted Aug 6, 2009 12:44 UTC (Thu) by mjthayer (guest, #39183) [Link]

I assume that was an answer to my third point, but I think you may have misunderstood me there. To take an example, if I use Compiz as a window manager, with wobbly windows enabled, most of the time my windows will not be wobbling. If they wobbled while I typed into them, that would annoy me greatly. At this point in time, there is little visible difference between Compiz and Metacity - all windows are shown front on, at 100% with no rotation or anything. And if I were using the Mesa software rasterer instead of an accelerated graphics card (yes, I know that Compiz refuses to start in that case, but that is not my point), it would not be very difficult for the rasterer to spot that the onscreen tiles (my windows) were identical before and after Compiz had finished transforming them. So the transformation can be reduced to a simple blit, which can be handled perfectly well by legacy cards.

So in effect, what I was meaning was that it ought to be possible for Mutter/Gnome shell to use OpenGL as a backend and still work fine on legacy systems in most situations. And with a bit of smart optimisation (setting the level of effects, handling the effects cleverly) it should even be possible for them to work reasonable well on legacy hardware at all times.

Mutter: a window manager for GNOME 3

Posted Aug 6, 2009 11:20 UTC (Thu) by russell (guest, #10458) [Link] (3 responses)

Most of the servers I work with don't have 3D hardware. There will be no GNOME 3 for them. Anyhow, I doubt GNOME 2 will be going away any time soon. It'll be years before they stabilize such radical changes.

Mutter: a window manager for GNOME 3

Posted Aug 6, 2009 16:00 UTC (Thu) by drag (guest, #31333) [Link] (2 responses)

> Most of the servers I work with don't have 3D hardware. There will be no GNOME 3 for them.

I don't even have a X server installed on _any_ of my servers...

> It'll be years before they stabilize such radical changes.

I hope not.

It's not like the KDE3 to KDE4 transition were they had to break everything and port all the applications over. This is just using a different Window manager, using a new theme engine for GTK, adding some features while eliminating some bloat and dependencies that people don't use anymore.

Mutter: a window manager for GNOME 3

Posted Aug 7, 2009 1:56 UTC (Fri) by russell (guest, #10458) [Link] (1 responses)

My servers are not the typical use case, they are connected to a KVM and are running interactive radar simulations ( X is a requirement for me ).

Perhaps they won't break everything from a code point of view, they are even reusing code. However, they will only be considering a small set of use cases. That will effectively undo all the usability polish that has been built up over the years ( not just in GNOME ), and IMO will take years to redo all over again.

I'll probably have to rework my simulation tools to fit into the new environment, i.e. applets, etc. That is not going to sit well with my employer, who will want to avoid that for as long as possible.

I doubt that I'm alone in this

Mutter: a window manager for GNOME 3

Posted Aug 7, 2009 3:41 UTC (Fri) by drag (guest, #31333) [Link]

> I'll probably have to rework my simulation tools to fit into the new environment, i.e. applets, etc. That is not going to sit well with my employer, who will want to avoid that for as long as possible.

In what way would you have to rework your program?

Mutter: a window manager for GNOME 3

Posted Aug 6, 2009 23:39 UTC (Thu) by jordanb (guest, #45668) [Link]

One step forward.

Twenty steps back. :(

I just hope that this crap is decoupled enough from gtk that I can keep on using fluxbox.

Mutter: a window manager for GNOME 3

Posted Aug 7, 2009 4:48 UTC (Fri) by ringerc (subscriber, #3071) [Link] (2 responses)

I'm really concerned about the effect of this on remote desktops (over remote X11, NX, or VNC/RFB).

Remote clients increasingly seem to be being forgotten, to the point where I recently had to track down a bug in Evolution (actually turned out to be in gtk) that caused "reply" and "new mail" windows to take MINUTES to appear on remote X11 displays.

When people _do_ examine remote desktops, they seem to assume the remote desktop machine is a grunty desktop that just happens to be running remote X - not a Via C7 or the like as is often really the case. Hardware accelerated 3D and fast CPUs are NOT guaranteed in distributed client environments.

Mutter: a window manager for GNOME 3

Posted Aug 7, 2009 19:21 UTC (Fri) by zlynx (guest, #2285) [Link] (1 responses)

Most X terminals had to run a local window manager. I remember back with twm on 10 Mbit Ethernet and some kind of X terminal ... NEC I think it was.

It had twm in ROM.

Running a remote window manager sucked quite a lot as I recall.

So if you run Mutter on your local system it should display remote applications just fine, I would think. Assuming that Gnome can still handle a half-local, half-remote configuration.

Mutter: a window manager for GNOME 3

Posted Aug 8, 2009 1:37 UTC (Sat) by ringerc (subscriber, #3071) [Link]

These days you generally use XDMCP to initiate a session and run *all* clients remotely, from the WM on up. Many X11 thin clients are netbooted minimalist compact PCs (mini-ITX or the like) with no HDD. Canned setups are offered by LTSP and the like.

Remote WMs work pretty well - with modern WMs like Metacity at least. In fact, they're pretty strongly preferable because of all the GNOME communication stuff that happens via D-BUS, gconf, etc rather than X11.

Even if Mutter was to be run locally, though, that doesn't change the fact that you're often talking about a 700MHz Via C7 (or even a 500MHz C3) system that while it supports insanely fast hardware crypto doesn't have any hardware 3D support.

Mutter: a window manager for GNOME 3

Posted Aug 7, 2009 8:01 UTC (Fri) by thedevil (guest, #32913) [Link] (1 responses)

If they keep Alt-Tab as the hardcoded keybinding for window switching, I refuse to use it.

Mutter: a window manager for GNOME 3

Posted Aug 7, 2009 8:50 UTC (Fri) by johill (subscriber, #25196) [Link]

It's never been hardcoded in GNOME, since I've been use cmd-tab for the past, uh, four years? Or are you saying mutter hardcodes it?

Mutter: a window manager for GNOME 3

Posted Aug 7, 2009 15:44 UTC (Fri) by jospoortvliet (guest, #33164) [Link]

It's good they're working on improving window management, but I hope they
coordinate this with KDE. Tabs in the windowmanager is being worked on for
KDE and the application-aware windowmanagement sounds like something you
need to collaborate on as well...

Mutter: a window manager for GNOME 3

Posted Aug 9, 2009 6:37 UTC (Sun) by jlokier (guest, #52227) [Link]

On my 3 year old laptop with Intel graphics, I can run compiz or not.

Compiz runs ok (apart from the occasional hard lockup, and crashes during video playback, and... all of which will surely be fixed eventually, but rule it out for regular use right now).

It seems a bit slower to display things with Compiz on than off, but usable both ways.

But I'm sure it uses a more battery when Compiz is used. That's my main reason for turning it off. The computer just feels like it's working harder with Compiz on, and you can see the redraw rate.

I found all the *useful* features of Compiz (like how it lays out windows and lets you move them) would work equally well with 2d acceleration, especially if there's 2d scaling. The 3d effects are pretty but I didn't find any of them useful; neither do I find translucent windows useful - just harder to read.

So I turned it off to save battery and make everything a bit smoother.

Please fix basic window management

Posted Aug 11, 2009 22:37 UTC (Tue) by spitzak (guest, #4593) [Link] (6 responses)

PLEASE:

Make it possible so that clicking in a window does not raise it, as an optional mode.

Don't make that mode disable the program's ability to raise itself.

When in that mode, make dragging the window title move the window and not raise it, and make a click raise it.

It is unbelievable that usability features we had 25 years ago are not being implemented today because so many people are used to the restrictions of Windows.

We need working non-raise window management as this is probably the biggest advantage that Unix has over Windows in the GUI area. Yet everybody is ignoring it, either making it impossible, or giving broken implementations such as Metacity's.

Please fix basic window management

Posted Aug 12, 2009 8:24 UTC (Wed) by Los__D (guest, #15263) [Link] (5 responses)

Maybe it's because "everybody" doesn't agree, and most think that do-raise window management is better?

Please fix basic window management

Posted Aug 12, 2009 16:30 UTC (Wed) by spitzak (guest, #4593) [Link] (4 responses)

Okay, you have responded with the first typical fallacy every time I mention this.

Take a look in the xlib/xcb documentation. See the call XRaiseWindow()? Okay, let's examine this advanced code that THE APPLICATION can do. Please pardon me if this is too complicated and over your head:

if (event == MOUSE_CLICK)
XRaiseWindow(dpy, mywindow);

Basically this defeats all arguments about "raise on click is better" because I am not saying it is not possible. All I want is for the application to have a CHOICE!!!

Please fix basic window management

Posted Aug 12, 2009 16:56 UTC (Wed) by Los__D (guest, #15263) [Link] (3 responses)

Don't worry, your fallacy is the same as everyone who has a pet feature; "You absolutely MUST bloat the settings UI with this! See, almost 1% of the users need it!".

Who cares if the implementation is simple? It's quite ok with me implement and stuff archaic (and unneeded by 99% of the target audience) features in an obscure text file or GConf setting, but not to clutter settings windows with it.

All I want is for the application to have a CHOICE!!!

And I want the window to iconify when I look at it evilly, but that doesn't mean that settings windows should be cluttered by my wishes.

Please fix basic window management

Posted Aug 12, 2009 17:50 UTC (Wed) by spitzak (guest, #4593) [Link] (1 responses)

I'm terribly sorry that the source code was too complicated for you to understand. It obviously went way over your head for you to make that response.

Please fix basic window management

Posted Aug 12, 2009 18:42 UTC (Wed) by Los__D (guest, #15263) [Link]

Oh, I'm terribly sorry, I DID misunderstand, you are not talking about the user at all.

I'm still not sure that I agree, though. As far as I see it, it should be the window manager that dictactes how the application windows behaves on user interactions, not the application.

- But a window class/mode that behaves like that in relation to other windows from the _SAME_ application could be useful.

This opinion is of course completely destroyed by my love of Desktop apps like gDesklets (horribly implemented as they are), which never raise. But hey, I never claimed to be consistent.

Please fix basic window management

Posted Aug 12, 2009 17:52 UTC (Wed) by spitzak (guest, #4593) [Link]

I should further qualify that.

Please point out where in my post I said that I wanted to "bloat the UI with another choice".

In fact I want to REMOVE the need for that UI configuration option! I'm sorry I'm acting like an ass probably here, but I am very very annoyed that you would accuse me of the exact opposite of what I want.

Mutter: a window manager for GNOME 3 and 3D effects

Posted Jul 24, 2011 3:26 UTC (Sun) by Tuxo (guest, #77324) [Link]

Hi all. I would like to say some things.

There are people that uses a linux desktop/workstation for everything: from a videograme console, to flight sim or serious research. I remember some flamewars regarding Gnome vs. KDE, and I put it simple: I had used gnome for numerical calculation on quantum computers (yes, there are some papers published) and all programs where written while I was using gnome, just because it was very comfortable to work with instead of KDE. In the same way I spent several hours playing quake or flying with FGFS, of course using gnome.

But what I had found very very very useful are basic 3D desktop effectrs: woobly windows and 3D cube, and here is why:

3D cube allows me to move in a comfortable way between viewports, the same way as with desktops. People who write pappers, do research or do numerical calculations often needs to drag windows between desktops or viewports.

Wobbly windows just feel natural and comfortable. For me is pure ergonomics, just think on real objects: they get deformed while you move them! I've found not only for me but also for my students and colleages the woobly efect really useful, it feels just unnatural to move a "solid" window.

And now something you may not expect, but while I am giving a conference or a lecture, both effects are just great, not only people like them (and of course get a desire to try GNU/Linux), but it allows me to have several papers, PDF files for conferences and running programs on cube faces and switch between them in a very attractive and efficient way.

So 3D effects are not only for teenagers who play a lot twith their computers, also for teachers and researchers who give lectures and conferences, and use linux in a dayly basis.

For the moment I haven't found a solution, but there are some missing features that makes a desktop much more useful, something as simple as move a window with alt+left-mouse. As I said befere, some people just need to move a compare window contents, and alt+left-click just solves that problem, now I have to click on title bar: the most uncomfortable way to move a window, just like Windows(TM).

SALUDOS
ALVARO