Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
Personally, we should cede the desktop to other projects like XFCE that work very well with minimal hardware requirements. I've noticed a lot of projects in GNOMEFiles with goals to write lightweight panels and what not. 10 years is a reasonable amount of time to expect hardware requirements to change. Looking forward seems to be the best course. Not that I have anything against a crazy high-traffic thread making a peaceful conclusion, but I found it odd how this discussion ended as soon as Sri made this awesome point. I, for one, fully agree. It's already the case that users can switch pretty seamlessly between GNOME and XFCE since the two use mostly the same technologies at heart. It could be made smoother, for example bridging Evolution and the calendar / email system XFCE uses. That could be as simple as providing a GNOME Clock Applet clone for xfce that distros could ship. XFCE does an awesome job; it is mature, fast and attractive. Its panel works quite well. It would be really great to see that product treated like a first class alternative instead of duplicating efforts :) Bye Dylan signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
Will the 3d shell work well on OpenMoko? On Tue, Mar 31, 2009 at 11:10 AM, Owen Taylor otay...@redhat.com wrote: And the same applies to virtualized desktops, but more so. Don't put the effort into avoiding 3D. Put the effort into making 3D work. - Owen -- Andy Tai, a...@atai.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Mon, 2009-04-06 at 16:52 -0700, Andy Tai wrote: Will the 3d shell work well on OpenMoko? 1. OpenMoko is the name of the company; do you mean on the GTA02? 2. why should a UI oriented towards the desktop work on a 3.5 display? 3. the GTA02 does not have a GPU. and it barely runs 2D frameworks. but the real point is (2): GNOME Shell is not for embedded devices, just like the current (metacity+gnome-panel) shell is not meant for embedded devices. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomas Frydrych a écrit : Josselin Mouette wrote: I don’t think maintaining a few more packages (especially packages that already exist today) is a big effort. But it stills bother me if we are going to propose two entirely different user experiences with two different configurations. For the end user, it will just feel like we are shipping two desktop environments. I think that is a wrong way of looking at it; we are going to be shipping one, unified desktop environment with a particular set of HW requirements. In addition to this it will be possible to downgrade this to the older Gnome desktop environment for legacy HW that does not meet the requirements. I couldn't agree more. Furthermore, this is already the case today. The GNOME based environment running on my N810 tablet is different from the one I run on my big iron desktop machine. And I find that very cool that we can have different flavors of GNOME tailored for different HW capabilities - if, of course, we can afford it. I am not sure users are complaining about that state of things today. D. - -- Tant que l'on n'a pas la tête coupée, on peut espérer mettre un chapeau. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Remi - http://enigmail.mozdev.org iEYEARECAAYFAkngjAAACgkQPejI7lrem2HQFwCggYVwEx+2iOKTrR0KJfcfH4nd YFgAn0g2TzuBnhqRpUJHScQrybrSCemv =FPXT -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Sat, 2009-04-11 at 14:24 +0200, Dodji Seketeli wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomas Frydrych a écrit : Josselin Mouette wrote: I don’t think maintaining a few more packages (especially packages that already exist today) is a big effort. But it stills bother me if we are going to propose two entirely different user experiences with two different configurations. For the end user, it will just feel like we are shipping two desktop environments. I think that is a wrong way of looking at it; we are going to be shipping one, unified desktop environment with a particular set of HW requirements. In addition to this it will be possible to downgrade this to the older Gnome desktop environment for legacy HW that does not meet the requirements. I couldn't agree more. Furthermore, this is already the case today. The GNOME based environment running on my N810 tablet is different from the one I run on my big iron desktop machine. And I find that very cool that we can have different flavors of GNOME tailored for different HW capabilities - if, of course, we can afford it. I am not sure users are complaining about that state of things today. Furthermore, users running old hardware generally don't expect to be able to run state of the art software anyway. Not that we should forcefully deny anyone running systems older than X years, but neither should we let ancient hardware stand in the way of innovation, when over Y% of the population runs machines that are sufficiently capable. Ruben -- Ruben Vermeersch (rubenv) http://www.savanne.be/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
Personally, we should cede the desktop to other projects like XFCE that work very well with minimal hardware requirements. I've noticed a lot of projects in GNOMEFiles with goals to write lightweight panels and what not. 10 years is a reasonable amount of time to expect hardware requirements to change. Looking forward seems to be the best course. sri On Sat, Apr 11, 2009 at 5:55 AM, Ruben Vermeersch ru...@savanne.be wrote: On Sat, 2009-04-11 at 14:24 +0200, Dodji Seketeli wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomas Frydrych a écrit : Josselin Mouette wrote: I don’t think maintaining a few more packages (especially packages that already exist today) is a big effort. But it stills bother me if we are going to propose two entirely different user experiences with two different configurations. For the end user, it will just feel like we are shipping two desktop environments. I think that is a wrong way of looking at it; we are going to be shipping one, unified desktop environment with a particular set of HW requirements. In addition to this it will be possible to downgrade this to the older Gnome desktop environment for legacy HW that does not meet the requirements. I couldn't agree more. Furthermore, this is already the case today. The GNOME based environment running on my N810 tablet is different from the one I run on my big iron desktop machine. And I find that very cool that we can have different flavors of GNOME tailored for different HW capabilities - if, of course, we can afford it. I am not sure users are complaining about that state of things today. Furthermore, users running old hardware generally don't expect to be able to run state of the art software anyway. Not that we should forcefully deny anyone running systems older than X years, but neither should we let ancient hardware stand in the way of innovation, when over Y% of the population runs machines that are sufficiently capable. Ruben -- Ruben Vermeersch (rubenv) http://www.savanne.be/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Tue, 2009-04-07 at 07:09 +0800, Sam Spilsbury wrote: A bit of work needs to be put into separating the code out (i.e separating clutter contexts, etc) with my Clutter maintainer hat on: Clutter currently, and for the foreseeable future, assumes that it will be the one library creating the GL context on every platform for which it has a backend. while there has been work to separate most of the actual canvas mode (the basic scenegraph) from the toolkit (event processing and windowing system) and that work made metacity-clutter, and thus gnome-shell, possible I'm wary of adding yet another layer in which Clutter is not even responsible of creating the GL context. on a more technical level: Clutter uses the GL pipeline in its own way through the COGL abstraction API; it sets up its own state to provide caching. stomping over that system *will* create issues. I'm pretty sure that trying to make Compiz, its plugins and an eventual compiz-gnome-shell plugin work together while part of the process drops into GL and other parts will use Clutter will suck. badly. through a clogged straw. dipped in a septic tank. Such a design would be easy to implement in compiz via it's plugin system. maybe Compiz should start looking at using Clutter instead. or maybe Compiz should just rewrite a gnome-shell as its own plugin; it's not like gnome-shell is using an esoteric set of little known libraries. bending and twisting three projects (Clutter, Compiz and gnome-shell) to make sure that Compiz stays relevant in a world where kwin and mutter exist (and are the default compositing window managers for KDE and GNOME respectively) is clearly not only a waste of time but its going to impact negatively on at least two projects of those three. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
Calum Benson a écrit : I guess the other category here is the current generation of thin clients... not 'legacy hardware' by any means, they just aren't really designed for this sort of thing. Then why not just run the current metacity + gnome applet combinations of today on that hardware ? Assuming metacity + current gnome applets are not going to vanish all of a sudden. Of course, that would result in more work for distributions because they'll have to propose the new GNOME Shell setup as well as a poor man setup. Now the resulting question would be, are distros ready to make that effort ? Dodji. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
Le samedi 04 avril 2009 à 15:33 +0200, Dodji Seketeli a écrit : Then why not just run the current metacity + gnome applet combinations of today on that hardware ? Assuming metacity + current gnome applets are not going to vanish all of a sudden. Of course, that would result in more work for distributions because they'll have to propose the new GNOME Shell setup as well as a poor man setup. Now the resulting question would be, are distros ready to make that effort ? I don’t think maintaining a few more packages (especially packages that already exist today) is a big effort. But it stills bother me if we are going to propose two entirely different user experiences with two different configurations. For the end user, it will just feel like we are shipping two desktop environments. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
Josselin Mouette wrote: I don’t think maintaining a few more packages (especially packages that already exist today) is a big effort. But it stills bother me if we are going to propose two entirely different user experiences with two different configurations. For the end user, it will just feel like we are shipping two desktop environments. I think that is a wrong way of looking at it; we are going to be shipping one, unified desktop environment with a particular set of HW requirements. In addition to this it will be possible to downgrade this to the older Gnome desktop environment for legacy HW that does not meet the requirements. My concern is that as long as we are going to allow significantly *outdated* HW capabilities to dictate the *future* direction of GNOME, we stand no chance of making GNOME into a platform of choice for the mainstream user. There are good reasons to provide legacy support, and it's great to be able to run GNOME on a machine that is 5 years old, but it must be seen for what it is -- legacy support, it cannot be where the collective effort of GNOME should be concentrated. Tomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
2009/4/6 Jason D. Clinton m...@jasonclinton.com: On Mon, Apr 6, 2009 at 10:34 AM, Tomas Frydrych t...@linux.intel.com wrote: mainstream user. There are good reasons to provide legacy support, and it's great to be able to run GNOME on a machine that is 5 years old, but it must be seen for what it is -- legacy support, it cannot be where the collective effort of GNOME should be concentrated. Actually, compositing requirements are fairly low. A machine that's five years old would be right on the border of being supported. The Intel 915 chipset with GMA 900 was released in June of 2004.[1] While there aren't a lot of people out there testing on this older hardware, it's supported by the same `intel` driver used on the newest Intel chips. airlied (and Red Hat) is doing great work on the DRI2 driver for R200/R300 ATI chipsets. And for the newest ATI/NVidia stuff, there's always the proprietary option (regrettable though it may be). You are missing the remote desktop scenario here. This is not only a matter of working on old hardware, being able to run gnome smoothly on a thin client solution through XDM, or VNC, or whatever is also needed. So, we're really talking about much older systems. [1] http://en.wikipedia.org/wiki/List_of_Intel_chipsets#90nm_.22Dothan.22_Pentium_M.2FCeleron_M_Chipsets ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Un saludo, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Mon, Apr 6, 2009 at 11:37 AM, Alberto Ruiz ar...@gnome.org wrote: You are missing the remote desktop scenario here. This is not only a matter of working on old hardware, being able to run gnome smoothly on a thin client solution through XDM, or VNC, or whatever is also needed. VNC is not an issue--it works regardless of the compositor/WM running. Speaking as a former LTSP admin/slave/developer, remote X11 is *always* a non-starter regardless of whether we are talking about 3D or not. More doesn't work than does. An approach similar to what Dave Richards is using at City of Largo is actually the right way to do this: the compositor and a few video-intensive apps run locally on the hardware. There's no technical reason that Shell couldn't do the same thing. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Mon, 2009-04-06 at 17:37 +0100, Alberto Ruiz wrote: 2009/4/6 Jason D. Clinton m...@jasonclinton.com: On Mon, Apr 6, 2009 at 10:34 AM, Tomas Frydrych t...@linux.intel.com wrote: mainstream user. There are good reasons to provide legacy support, and it's great to be able to run GNOME on a machine that is 5 years old, but it must be seen for what it is -- legacy support, it cannot be where the collective effort of GNOME should be concentrated. Actually, compositing requirements are fairly low. A machine that's five years old would be right on the border of being supported. The Intel 915 chipset with GMA 900 was released in June of 2004.[1] While there aren't a lot of people out there testing on this older hardware, it's supported by the same `intel` driver used on the newest Intel chips. airlied (and Red Hat) is doing great work on the DRI2 driver for R200/R300 ATI chipsets. And for the newest ATI/NVidia stuff, there's always the proprietary option (regrettable though it may be). You are missing the remote desktop scenario here. This is not only a matter of working on old hardware, being able to run gnome smoothly on a thin client solution through XDM, or VNC, or whatever is also needed. I've already answered this previously: Composited desktops may not well with today's network protocols, but that's a software issue, nothing inherent to thin clients. I have no sympathy for the complaint that nobody has been working on it and we just have to live with VNC and remote X (*). If we care about thin clients, we have to compete on today's terms. We can't compete on yesterday's terms and hope that will be good enough. But in the end, what we do for GNOME Shell doesn't come down to what we think would be nice to have, it comes down to what we write the code to do. Writing two versions of GNOME Shell, one using modern technology and one using ancient technology, and then switching between them depending on the available hardware is a big project. Not one person has showed up with an interest in working on this. If someone shows up and thinks this is how they want to spend their time, I'm certainly willing to discuss how that can be accomplished. - Owen (*) Of course, Novell _has_ done some work on this in the context of Compiz recently. And even results with plain old remote X and remote GLX are surprisingly good; that's my understanding of how the City of Largo is using Compiz. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Tue, Apr 7, 2009 at 5:23 AM, Owen Taylor otay...@redhat.com wrote: On Mon, 2009-04-06 at 17:37 +0100, Alberto Ruiz wrote: 2009/4/6 Jason D. Clinton m...@jasonclinton.com: On Mon, Apr 6, 2009 at 10:34 AM, Tomas Frydrych t...@linux.intel.com wrote: mainstream user. There are good reasons to provide legacy support, and it's great to be able to run GNOME on a machine that is 5 years old, but it must be seen for what it is -- legacy support, it cannot be where the collective effort of GNOME should be concentrated. Actually, compositing requirements are fairly low. A machine that's five years old would be right on the border of being supported. The Intel 915 chipset with GMA 900 was released in June of 2004.[1] While there aren't a lot of people out there testing on this older hardware, it's supported by the same `intel` driver used on the newest Intel chips. airlied (and Red Hat) is doing great work on the DRI2 driver for R200/R300 ATI chipsets. And for the newest ATI/NVidia stuff, there's always the proprietary option (regrettable though it may be). You are missing the remote desktop scenario here. This is not only a matter of working on old hardware, being able to run gnome smoothly on a thin client solution through XDM, or VNC, or whatever is also needed. I've already answered this previously: Composited desktops may not well with today's network protocols, but that's a software issue, nothing inherent to thin clients. I have no sympathy for the complaint that nobody has been working on it and we just have to live with VNC and remote X (*). If we care about thin clients, we have to compete on today's terms. We can't compete on yesterday's terms and hope that will be good enough. VNC as been obsoleted by RDP anyways - however you can split your output backends into plugins (like compiz) and either autodetect/allow the user to drop to non-3D mode. But in the end, what we do for GNOME Shell doesn't come down to what we think would be nice to have, it comes down to what we write the code to do. Writing two versions of GNOME Shell, one using modern technology and one using ancient technology, and then switching between them depending on the available hardware is a big project. Not one person has showed up with an interest in working on this. If someone shows up and thinks this is how they want to spend their time, I'm certainly willing to discuss how that can be accomplished. - Owen (*) Of course, Novell _has_ done some work on this in the context of Compiz recently. And even results with plain old remote X and remote GLX are surprisingly good; that's my understanding of how the City of Largo is using Compiz. This is fairly easy to implement AFAICT - you just need something handle the DMX and RDP channel transmission via the local instance of mutter and the remote one. The only gotcha with this is that you need to write code that would have windows in a 'tree' and make all the code aware of that tree. On a side note - I'll be doing some work to see if we can abstract the panel drawing bit of gnome-shell into a lib that will draw under any openGL context. The actual gnome-shell plugin will display the rendered shell onscreen and also handle the animation of the 'overlay' mode. I think this can be done by setting a few function callbacks to notify when certain animations need doing. A bit of work needs to be put into separating the code out (i.e separating clutter contexts, etc) but hopefully it should all work out. I think the situation we want to avoid here is that other composite window managers need to fork / rewrite the code in order that users don't lose functionality when they want to use their window manager with GNOME. Such a design would be easy to implement in compiz via it's plugin system. Kind Regards, Sam Spilsbury ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Sam Spilsbury ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
Le mardi 31 mars 2009 à 14:10 -0400, Owen Taylor a écrit : I just don't think it makes sense to code GNOME Shell to the limitations of other pieces of the software stack. The effort to fix the other pieces of the stack - to create free software ways of doing thin clients with a composited snazzy desktop - is going to be comparable or less then the extra effort we'd need to put into GNOME Shell, and the end result is much better. And the same applies to virtualized desktops, but more so. Don't put the effort into avoiding 3D. Put the effort into making 3D work. It really sounds like the good thing to do, but I'm not convinced that this will actually happen. No one has been really working on this in the last years, and I don’t see any efforts in this direction currently. I understand the rationale for going “full 3D” for GNOME Shell, but the overall result is that we will have to maintain the gnome-panel + metacity solution separately, for ever. This will not be a big burden, but the real issue behind this is there will be two entirely different user experiences. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
Il giorno mer, 01/04/2009 alle 19.34 +0200, Josselin Mouette ha scritto: I understand the rationale for going “full 3D” for GNOME Shell, but the overall result is that we will have to maintain the gnome-panel + metacity solution separately, for ever. This will not be a big burden, but the real issue behind this is there will be two entirely different user experiences. I've got an old laptop (7-8 years), and it really cringes with compiz if I enable it. At work, we have a couple of machines with GNU/Linux + GNOME. They have integrated low-cost graphic cards, or are old machines. In fact, a common trend nowadays is to recycle old machines bought for 100-150€ moving them from Windows XP to GNOME. I see this happening quite frequently also in the developing countries, when I talk to people I know that live there. I wouldn't mind the default being 3D-oriented, if at least a disable-most-effects mode is available. Also for all those who have to use a software renderer. For now, my laptop lives very well with GNOME despite its age. I'd like it to stay so. Only trying KDE here is so slow it makes your eyes water... Cheers, Matteo signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
Le lundi 30 mars 2009 à 15:20 -0500, Ted Gould a écrit : Swappable Window Managers isn't important. Being able to have graceful degradation down to non-composited environments is. I totally agree with this. There is way too much hardware for which acceleration is not supported under Linux, and even for those that support it, the drivers can be so buggy some want to disable them anyway. Yes, it’s terrible to make the user experience depend on hardware support, but there has to be a fallback. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
Hi everyone, Sam Spilsbury wrote: I don't get why that statement is true. For a GNOME Shell project to be successful, it hast to be freakin good. Mac OS X and Windows XP are way far more successful desktop environments than GNOME or KDE are, and they don't even have the notion of swappable windows managers, and if they do, none uses them. So what's your point here? See KDE. They've abstracted a lot of their stuff and made special efforts so that it works with other composite window managers. There is one thing to be said for pretty much any abstraction -- it gives you the worst of all possible worlds, makes most things possible, and allows nothing to be done well. Abstractions are only meaningful if you need to use multiple components of similar functionality *concurrently*, in all other cases abstractions are just waste of effort and HW resources. I dare to say that WMs fall into the latter category. The argument for swappable window managers is not far removed for an argument for swappable libc. The reality is users do not give the proverbial about window managers, all they care about is a good, smooth, pain free user experience, a system that allows them to do things *they* care about with minimal effort and intrusion. There is only one thing that really matters about a window manager -- the user should not know they have one; as soon as the user is conscious of what a WM does and does not do, and what WM they are using, it means we, the developers, are getting in the way of what the users is actually doing. Someone else in this thread mentioned that while swappable WMs are not an issue, being able to degrade to a non-compositing WM is. Degrading is not the right term for this; we want alternate desktop that can be run on older (or crippled) HW. We already have that, so this really is a non-issue; it does not matter that the legacy desktop is (very) different from the new desktop, but it is important that legacy support does not hold back future development. The Gnome Shell should be all about enabling the user, everything else is just a distraction. The way you achieve this is you pick one WM that has the potential to enable you to achieve that goal with the least and most sustainable effort and you get on with it. My guess is that the Gnome Shell devs picked Mutter because it makes this easy, not least because of its heritage of Metacity's reliable window management, but also the fact it is build on common Gnome technologies (GObject, Clutter), and because it is being developed precisely with view toward what the Shell is about. From what I can see with the code, I know so far that gnome-shell is really just a plugin to gnome, making the job of abstracting it about 100 times easier. I don't think there needs to be a specific dependency on Mutter's scene graph - the shell isn't really transformed in any way, so it can just use the GL context and spawn another clutter context in which it draws on top. Even if that was the case (which it is not), why would you want to do that ? What exactly would you gain in the pursuit of the ultimate goal of enabling the users to focus on their tasks ? At best you gain just a layer of indirection, wasting the users HW resources and impacting performance. If it can be demonstrated that Compiz is technically a superior starting point on which to build the Shell, that it will be easier to develop the Shell on the top of it, that it has better prospects for long-term maintainability, and that will provide useful features improving the user experience that Mutter cannot facilitate, then the Shell should be switched over to Compiz -- one or the other, but both make no sense. Kind regards, Tomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Mon, 2009-03-30 at 15:20 -0500, Ted Gould wrote: On Mon, 2009-03-30 at 20:23 +0100, Alberto Ruiz wrote: 2009/3/30 Ted Gould t...@gould.cx: On Wed, 2009-03-25 at 12:07 -0400, Owen Taylor wrote: So, basically, no I don't see a way that GNOME Shell coexists with Compiz other than as two separate shells for the GNOME desktop. And I think that coexistence is part of the problem with GNOME Shell becoming the default GNOME interface. Distributions need something that can gracefully decline between a composited and a non-composited environment. Not saying that Compiz can do that today, but we effectively get that with the combination of metacity and Compiz and lots of nasty hacks. But, overall it works. For a GNOME Shell like project to be successful it will need to have either two backends or some sort of architecture that would allow for GNOME Shell features to be integrated in other less featureful shell-like tools. I don't get why that statement is true. For a GNOME Shell project to be successful, it hast to be freakin good. Mac OS X and Windows XP are way far more successful desktop environments than GNOME or KDE are, and they don't even have the notion of swappable windows managers, and if they do, none uses them. So what's your point here? Swappable Window Managers isn't important. Being able to have graceful degradation down to non-composited environments is. To be entirely honest, some of these are problems of our own situation. Neither Mac nor Windows have to worry about shipping binary nvidia drivers either. I'm not a fan of the situation, but we've solved this problem in the past with swapping window managers. I don't think that's the only way to do it, but it's definitely the easiest today. I'm not sure of all of the demo CDs out there, but I don't think that almost all of them come up in non-composited environments on the vast majority of hardware. Having the demo be entirely different than what you get when install seems like a really bad idea. It doesn't sound like a good idea to me to have a demo CD that demos something that isn't the same thing that you get when you install. If someone has a nice new njvidia card, what incentive do they have to switch to Linux if the demo CD they try out looks like something from 1998? Nouveau is coming along nicely. As is 3D support for the latest AMD cards. I have every expectation that in a year (which is when we are really talking about GNOME Shell starting to be widely deployed) we will be able to support it with open source 3D drivers on the vast majority of what people are running. Including netbooks and other low-end devices. What isn't going to be able to run GNOME Shell is really old hardware ... if you have a Rage128, GNOME Shell isn't going to happen. But when we are talking legacy hardware of that age, I think a special purpose environment makes sense. Whether it's XFCE, or metacity + gnome-panel, or something else. Of course, low-graphics fallbacks that integrated seemlessly with GNOME Shell would be nice to have. But given the reality that they would be an enormous amount of extra work, and would seriously compromise the design vision, they don't make sense. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
Owen: I just don't think it makes sense to code GNOME Shell to the limitations of other pieces of the software stack. The effort to fix the other pieces of the stack - to create free software ways of doing thin clients with a composited snazzy desktop - is going to be comparable or less then the extra effort we'd need to put into GNOME Shell, and the end result is much better. And the same applies to virtualized desktops, but more so. Don't put the effort into avoiding 3D. Put the effort into making 3D work. As a general rule, I agree with you. However, there are bound to be a few 3D features that do not work well in low-network-latency environments. I think it would be unreasonable to expect that such users (and users in general) won't want some degree of configuration control to make the desktop as usable as possible. However, such configuration should obviously be kept to a minimum and only when there is a strong use case for supporting it, I'd think. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Wed, 2009-03-25 at 12:07 -0400, Owen Taylor wrote: So, basically, no I don't see a way that GNOME Shell coexists with Compiz other than as two separate shells for the GNOME desktop. And I think that coexistence is part of the problem with GNOME Shell becoming the default GNOME interface. Distributions need something that can gracefully decline between a composited and a non-composited environment. Not saying that Compiz can do that today, but we effectively get that with the combination of metacity and Compiz and lots of nasty hacks. But, overall it works. For a GNOME Shell like project to be successful it will need to have either two backends or some sort of architecture that would allow for GNOME Shell features to be integrated in other less featureful shell-like tools. While I love many of the concepts being explored and have suggested ideas for some of them, I just simply can't see the currently incarnation of GNOME Shell being the default for GNOME. --Ted signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
2009/3/30 Ted Gould t...@gould.cx: On Wed, 2009-03-25 at 12:07 -0400, Owen Taylor wrote: So, basically, no I don't see a way that GNOME Shell coexists with Compiz other than as two separate shells for the GNOME desktop. And I think that coexistence is part of the problem with GNOME Shell becoming the default GNOME interface. Distributions need something that can gracefully decline between a composited and a non-composited environment. Not saying that Compiz can do that today, but we effectively get that with the combination of metacity and Compiz and lots of nasty hacks. But, overall it works. For a GNOME Shell like project to be successful it will need to have either two backends or some sort of architecture that would allow for GNOME Shell features to be integrated in other less featureful shell-like tools. I don't get why that statement is true. For a GNOME Shell project to be successful, it hast to be freakin good. Mac OS X and Windows XP are way far more successful desktop environments than GNOME or KDE are, and they don't even have the notion of swappable windows managers, and if they do, none uses them. So what's your point here? While I love many of the concepts being explored and have suggested ideas for some of them, I just simply can't see the currently incarnation of GNOME Shell being the default for GNOME. --Ted ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Un saludo, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Mon, 2009-03-30 at 20:23 +0100, Alberto Ruiz wrote: 2009/3/30 Ted Gould t...@gould.cx: On Wed, 2009-03-25 at 12:07 -0400, Owen Taylor wrote: So, basically, no I don't see a way that GNOME Shell coexists with Compiz other than as two separate shells for the GNOME desktop. And I think that coexistence is part of the problem with GNOME Shell becoming the default GNOME interface. Distributions need something that can gracefully decline between a composited and a non-composited environment. Not saying that Compiz can do that today, but we effectively get that with the combination of metacity and Compiz and lots of nasty hacks. But, overall it works. For a GNOME Shell like project to be successful it will need to have either two backends or some sort of architecture that would allow for GNOME Shell features to be integrated in other less featureful shell-like tools. I don't get why that statement is true. For a GNOME Shell project to be successful, it hast to be freakin good. I could not have said this better. :-) - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Mon, 2009-03-30 at 20:23 +0100, Alberto Ruiz wrote: 2009/3/30 Ted Gould t...@gould.cx: On Wed, 2009-03-25 at 12:07 -0400, Owen Taylor wrote: So, basically, no I don't see a way that GNOME Shell coexists with Compiz other than as two separate shells for the GNOME desktop. And I think that coexistence is part of the problem with GNOME Shell becoming the default GNOME interface. Distributions need something that can gracefully decline between a composited and a non-composited environment. Not saying that Compiz can do that today, but we effectively get that with the combination of metacity and Compiz and lots of nasty hacks. But, overall it works. For a GNOME Shell like project to be successful it will need to have either two backends or some sort of architecture that would allow for GNOME Shell features to be integrated in other less featureful shell-like tools. I don't get why that statement is true. For a GNOME Shell project to be successful, it hast to be freakin good. Mac OS X and Windows XP are way far more successful desktop environments than GNOME or KDE are, and they don't even have the notion of swappable windows managers, and if they do, none uses them. So what's your point here? Swappable Window Managers isn't important. Being able to have graceful degradation down to non-composited environments is. To be entirely honest, some of these are problems of our own situation. Neither Mac nor Windows have to worry about shipping binary nvidia drivers either. I'm not a fan of the situation, but we've solved this problem in the past with swapping window managers. I don't think that's the only way to do it, but it's definitely the easiest today. I'm not sure of all of the demo CDs out there, but I don't think that almost all of them come up in non-composited environments on the vast majority of hardware. Having the demo be entirely different than what you get when install seems like a really bad idea. --Ted signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Tue, Mar 31, 2009 at 3:23 AM, Alberto Ruiz ar...@gnome.org wrote: 2009/3/30 Ted Gould t...@gould.cx: On Wed, 2009-03-25 at 12:07 -0400, Owen Taylor wrote: So, basically, no I don't see a way that GNOME Shell coexists with Compiz other than as two separate shells for the GNOME desktop. And I think that coexistence is part of the problem with GNOME Shell becoming the default GNOME interface. Distributions need something that can gracefully decline between a composited and a non-composited environment. Not saying that Compiz can do that today, but we effectively get that with the combination of metacity and Compiz and lots of nasty hacks. But, overall it works. It can, see compiz 0.9.x (admittedly this is the new development branch and won't be stable for a while but it _can_ do it, if the opengl or composite plugins can't initialize for whatever reason compiz just falls back to being a normal WM and all the bling plugins aren't loaded. For a GNOME Shell like project to be successful it will need to have either two backends or some sort of architecture that would allow for GNOME Shell features to be integrated in other less featureful shell-like tools. I don't get why that statement is true. For a GNOME Shell project to be successful, it hast to be freakin good. Mac OS X and Windows XP are way far more successful desktop environments than GNOME or KDE are, and they don't even have the notion of swappable windows managers, and if they do, none uses them. So what's your point here? See KDE. They've abstracted a lot of their stuff and made special efforts so that it works with other composite window managers. While I love many of the concepts being explored and have suggested ideas for some of them, I just simply can't see the currently incarnation of GNOME Shell being the default for GNOME. --Ted To be frank in the end, unless we see some kind of co-operation we are going to have to take a really bad route, which is forking shell so that compiz users aren't unfairly locked out of half of their desktop functionality when using future GNOME versions - I'd really hate it to come down to this. From what I can see with the code, I know so far that gnome-shell is really just a plugin to gnome, making the job of abstracting it about 100 times easier. I don't think there needs to be a specific dependency on Mutter's scene graph - the shell isn't really transformed in any way, so it can just use the GL context and spawn another clutter context in which it draws on top. The idea would be to make your plugin a wrapper to the lib, so that the lib doesn't depend on mutter and the plugin is linked to the lib. We can do something similar in compiz as can a lot of other window managers. I was told however, that there were some javascript bits and bobs in the code which would make the task harder - but I couldn't find them in the source. Could anybody point me to these? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Un saludo, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list Kind Regards, -- Sam Spilsbury ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Mon, 2009-03-23 at 17:11 -0400, Owen Taylor wrote: On Mon, 2009-03-23 at 17:02 -0400, Colin Walters wrote: On Mon, Mar 23, 2009 at 4:41 PM, Owen Taylor otay...@redhat.com wrote: 2) Mutter could be renamed as a project to mutter (binary, GConf schemas, etc. Presumably, the internals would stay Meta*) and imported into GNOME version control independently of metacity. The uncomposited and RENDER code paths would gradually be removed leaving just a Clutter based WM/CM. The main disadvantage of this approach is that any ongoing maintenance of Metacity would not feed from or to this project automatically. I'd like to toss in here: 4) o Import mutter as a branch of metacity o When built, it installs its binary by default by default as metacity-compositor o We share a common GConf schema subset (even if e.g. compositor has a few more keys) o We share the bugzilla name metacity o Replay some of the non-compositing changes like GObject-ification and introspection support on to mainline to reduce the divergence There are some tradeoffs here, but I'd like to avoid creating a distinct mutter brand and forking the GConf keys, even if the display technology is changing a lot. A branch in the (future) Metacity git repository is an interesting idea, in that it allows changes to be moved somewhat more conveniently between the trees. But it could also be confusing, and unless you are going to keep on merging Metacity wholesale into mutter, there's not a big advantage in having them in the same repository. 'git cherry-pick' has no special intelligence over just applying a patch. I am sure there will be users that do not like the change in mental model gnome-shell will bring. It would be a shame if those users missed out on the improvements to Metacity (aka mutter). I think whatever development model allows Metacity to ship with a clutter based compositing backend, or an alternative metacity-clutter binary would be best. John How would you see packaging and installation working with your scheme? I don't see how different programs (metacity and metacity-clutter) could share the same GConf schema keys. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Tue, 2009-03-24 at 19:42 +0100, Xavier Bestel wrote: Eh, for now compiz is working and is the reference WM for linux (and more) Interesting point of view. I thought that the reference window manager for GNOME was Metacity, what with it being the only window manager which is in the GNOME release. Linux, being a kernel, doesn't have a reference window manager. If you are talking about X I believe the reference window manager is twm. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Wed, Mar 25, 2009 at 12:47 AM, Owen Taylor otay...@redhat.com wrote: On Tue, 2009-03-24 at 16:17 +0900, Sam Spilsbury wrote: On Tue, Mar 24, 2009 at 8:18 AM, Johannes Schmid j...@jsschmid.de wrote: Hi! 2) Mutter could be renamed as a project to mutter (binary, GConf schemas, etc. Presumably, the internals would stay Meta*) and imported into GNOME version control independently of metacity. The uncomposited and RENDER code paths would gradually be removed leaving just a Clutter based WM/CM. The main disadvantage of this approach is that any ongoing maintenance of Metacity would not feed from or to this project automatically. Actually I am bit in favor of this approach. Having the window manager and the shell separated has the advantage that they can be used independently. Think about things like Gnome Mobile or Netbooks - probably you want a composited wm here but you don't want GNOME Shell (but probably another shell that is based on a mutter-plugin). Definitely. If the WM and the shell were integrated, it would mean that a severe chunk of functionality would be lost when using other window managers like compiz with GNOME. It's totally possible to separate the shell and the WM and instead abstract calls to the WM with DBUS. That way compiz can have a plugin to support functionality required by gnome-shell. To try and make GNOME Shell integrate with multiple window managers would either greatly constrain the user interface vision or greatly increase the amount of work involved. The power of the GNOME shell approach is that we are working within the desktop scene graph of the window manager/compositor. Hi, I'm not going to deal with a later remark about compiz, because I don't feel that this is what this discussion is about (Even though I am a compiz developer). We at compiz actually had a discussion over the phone with all the developers, including those at Novell about the future direction of our project and what our place would be (especially with the recent KWin and GNOME-Shell projects). It would be difficult to have any sort of position within the desktop if those two projects were to take hold, however it would be very disappointing to see a lot of code be dropped, especially considering that it may not see a life in KWin or Mutter/Metacity-Clutter/GNOME-Shell. We decided that KWin was not going to be a huge issue for us - it is perfectly up to the user to decide which WM they want to use, and if they used either, we believe there would be no significant loss in functionality. GNOME-Shell on the other hand is a far greater issue for us. While I believe the panel will be kept around until 3.2, after that point, 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. A lot of window managers are starting to tinker with compositing, and the functionality as far as I can see is easily achievable with any window manager. If GNOME-Shell were made into a library, then it would be possible for normal compositing window managers such as Mutter and Compiz to hook into events generated by that library and do all the effects themselves. This is certainly a much better approach than what we had originally planned - which was duplicate code from GNOME-Shell into a compiz plugin so that users don't lose functionality. I understand that GNOME-Compiz relations have been rather sour recently (and it has been, up until last year, a dilemma we face with KDE), however working together on this one would be a great step forward between a productive relationship between the two projects. Kind Regards, Sam Spilsbury Using Compiz to create a GNOME desktop using GNOME applications, the GNOME control-center, and so forth will of course remain possible. We have no current plans to create hard dependencies on GNOME Shell within the GNOME desktop (just as there are no hard dependencies on gnome-panel now.) - Owen -- Sam Spilsbury ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
Hi! To try and make GNOME Shell integrate with multiple window managers would either greatly constrain the user interface vision or greatly increase the amount of work involved. The power of the GNOME shell approach is that we are working within the desktop scene graph of the window manager/compositor. Using Compiz to create a GNOME desktop using GNOME applications, the GNOME control-center, and so forth will of course remain possible. We have no current plans to create hard dependencies on GNOME Shell within the GNOME desktop (just as there are no hard dependencies on gnome-panel now.) I think we kind of loose the direction of this discussion here. IMHO, users don't care about window managers at all (have you ever asked a Windows/Mac user about a window manager?). My point is that it should be possible to use mutter without gnome-shell because there might be use-cases where the gnome-shell model does not fit. The other way round is not very interesting because gnome-shell tries to create a new user model for the whole desktop which of course includes lots of stuff that were historically tied to window management. If someone wants to implement a window manager compatible with mutter that gnome-shell can use - that's ok, but it shouldn't be something GNOME Shell development should care about in the first place. Regards, Johannes signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Wed, 2009-03-25 at 20:54 +0900, Sam Spilsbury wrote: On Wed, Mar 25, 2009 at 12:47 AM, Owen Taylor otay...@redhat.com wrote: On Tue, 2009-03-24 at 16:17 +0900, Sam Spilsbury wrote: On Tue, Mar 24, 2009 at 8:18 AM, Johannes Schmid j...@jsschmid.de wrote: Hi! 2) Mutter could be renamed as a project to mutter (binary, GConf schemas, etc. Presumably, the internals would stay Meta*) and imported into GNOME version control independently of metacity. The uncomposited and RENDER code paths would gradually be removed leaving just a Clutter based WM/CM. The main disadvantage of this approach is that any ongoing maintenance of Metacity would not feed from or to this project automatically. Actually I am bit in favor of this approach. Having the window manager and the shell separated has the advantage that they can be used independently. Think about things like Gnome Mobile or Netbooks - probably you want a composited wm here but you don't want GNOME Shell (but probably another shell that is based on a mutter-plugin). Definitely. If the WM and the shell were integrated, it would mean that a severe chunk of functionality would be lost when using other window managers like compiz with GNOME. It's totally possible to separate the shell and the WM and instead abstract calls to the WM with DBUS. That way compiz can have a plugin to support functionality required by gnome-shell. To try and make GNOME Shell integrate with multiple window managers would either greatly constrain the user interface vision or greatly increase the amount of work involved. The power of the GNOME shell approach is that we are working within the desktop scene graph of the window manager/compositor. Hi, I'm not going to deal with a later remark about compiz, because I don't feel that this is what this discussion is about (Even though I am a compiz developer). We at compiz actually had a discussion over the phone with all the developers, including those at Novell about the future direction of our project and what our place would be (especially with the recent KWin and GNOME-Shell projects). It would be difficult to have any sort of position within the desktop if those two projects were to take hold, however it would be very disappointing to see a lot of code be dropped, especially considering that it may not see a life in KWin or Mutter/Metacity-Clutter/GNOME-Shell. We decided that KWin was not going to be a huge issue for us - it is perfectly up to the user to decide which WM they want to use, and if they used either, we believe there would be no significant loss in functionality. GNOME-Shell on the other hand is a far greater issue for us. While I believe the panel will be kept around until 3.2, after that point, 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. A lot of window managers are starting to tinker with compositing, and the functionality as far as I can see is easily achievable with any window manager. If GNOME-Shell were made into a library, then it would be possible for normal compositing window managers such as Mutter and Compiz to hook into events generated by that library and do all the effects themselves. This is certainly a much better approach than what we had originally planned - which was duplicate code from GNOME-Shell into a compiz plugin so that users don't lose functionality. I understand that GNOME-Compiz relations have been rather sour recently (and it has been, up until last year, a dilemma we face with KDE), however working together on this one would be a great step forward between a productive relationship between the two projects. GNOME Shell is an integrated window manager, compositor, and application launcher. This integration isn't some coincidental thing,it is basic requirement of the user interface thing GNOME Shell depends on two things: - Metacity's basic window management code: property fetching, stacking, etc, etc. - The Clutter OpenGL scene graph Now, of course Compiz has window management code. And it knows how to draw a scene with OpenGL. So we could have written GNOME Shell on top of Compiz, but for various reasons we didn't. Create some sort of window management abstraction layer and scene graph abstraction layer is what I mean by greatly increase the amount of work. And by greatly, I don't mean 20%, I mean multiple times the work. Because any time we wanted to do anything that involved the parts beneath the abstraction layer, we'd have to get the Compiz and Metacity and Clutter developers to all agree. And there would be no point. If working on top of Compiz was the right way to go, then we should have
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
Owen Taylor wrote: So, basically, no I don't see a way that GNOME Shell coexists with Compiz other than as two separate shells for the GNOME desktop. IMHO, rather than looking for gnome-shell to work with compiz or another VM, one should rather try and make a way for applets to work on gnome-shell and, say, compiz-shell (which would then mostly be a receptacle for those applets) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Thu, Mar 26, 2009 at 12:29 AM, Johannes Schmid j...@jsschmid.de wrote: Hi! To try and make GNOME Shell integrate with multiple window managers would either greatly constrain the user interface vision or greatly increase the amount of work involved. The power of the GNOME shell approach is that we are working within the desktop scene graph of the window manager/compositor. Using Compiz to create a GNOME desktop using GNOME applications, the GNOME control-center, and so forth will of course remain possible. We have no current plans to create hard dependencies on GNOME Shell within the GNOME desktop (just as there are no hard dependencies on gnome-panel now.) I think we kind of loose the direction of this discussion here. IMHO, users don't care about window managers at all (have you ever asked a Windows/Mac user about a window manager?). My point is that it should be possible to use mutter without gnome-shell because there might be use-cases where the gnome-shell model does not fit. The other way round is not very interesting because gnome-shell tries to create a new user model for the whole desktop which of course includes lots of stuff that were historically tied to window management. If someone wants to implement a window manager compatible with mutter that gnome-shell can use - that's ok, but it shouldn't be something GNOME Shell development should care about in the first place. Hi, It works both ways - if you want to separate shell from mutter than the shell API must be exposed. If you want to separate mutter from shell, mutter must have some way to communicate with shell, so the API must be exposed. Kind Regards, Sam Regards, Johannes -- Sam Spilsbury ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Thu, Mar 26, 2009 at 1:07 AM, Owen Taylor otay...@redhat.com wrote: On Wed, 2009-03-25 at 20:54 +0900, Sam Spilsbury wrote: On Wed, Mar 25, 2009 at 12:47 AM, Owen Taylor otay...@redhat.com wrote: On Tue, 2009-03-24 at 16:17 +0900, Sam Spilsbury wrote: On Tue, Mar 24, 2009 at 8:18 AM, Johannes Schmid j...@jsschmid.de wrote: Hi! 2) Mutter could be renamed as a project to mutter (binary, GConf schemas, etc. Presumably, the internals would stay Meta*) and imported into GNOME version control independently of metacity. The uncomposited and RENDER code paths would gradually be removed leaving just a Clutter based WM/CM. The main disadvantage of this approach is that any ongoing maintenance of Metacity would not feed from or to this project automatically. Actually I am bit in favor of this approach. Having the window manager and the shell separated has the advantage that they can be used independently. Think about things like Gnome Mobile or Netbooks - probably you want a composited wm here but you don't want GNOME Shell (but probably another shell that is based on a mutter-plugin). Definitely. If the WM and the shell were integrated, it would mean that a severe chunk of functionality would be lost when using other window managers like compiz with GNOME. It's totally possible to separate the shell and the WM and instead abstract calls to the WM with DBUS. That way compiz can have a plugin to support functionality required by gnome-shell. To try and make GNOME Shell integrate with multiple window managers would either greatly constrain the user interface vision or greatly increase the amount of work involved. The power of the GNOME shell approach is that we are working within the desktop scene graph of the window manager/compositor. Hi, I'm not going to deal with a later remark about compiz, because I don't feel that this is what this discussion is about (Even though I am a compiz developer). We at compiz actually had a discussion over the phone with all the developers, including those at Novell about the future direction of our project and what our place would be (especially with the recent KWin and GNOME-Shell projects). It would be difficult to have any sort of position within the desktop if those two projects were to take hold, however it would be very disappointing to see a lot of code be dropped, especially considering that it may not see a life in KWin or Mutter/Metacity-Clutter/GNOME-Shell. We decided that KWin was not going to be a huge issue for us - it is perfectly up to the user to decide which WM they want to use, and if they used either, we believe there would be no significant loss in functionality. GNOME-Shell on the other hand is a far greater issue for us. While I believe the panel will be kept around until 3.2, after that point, 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. A lot of window managers are starting to tinker with compositing, and the functionality as far as I can see is easily achievable with any window manager. If GNOME-Shell were made into a library, then it would be possible for normal compositing window managers such as Mutter and Compiz to hook into events generated by that library and do all the effects themselves. This is certainly a much better approach than what we had originally planned - which was duplicate code from GNOME-Shell into a compiz plugin so that users don't lose functionality. I understand that GNOME-Compiz relations have been rather sour recently (and it has been, up until last year, a dilemma we face with KDE), however working together on this one would be a great step forward between a productive relationship between the two projects. GNOME Shell is an integrated window manager, compositor, and application launcher. This integration isn't some coincidental thing,it is basic requirement of the user interface thing GNOME Shell depends on two things: I haven't had a chance to look at the code so far - so please correct me if I am wrong. - Metacity's basic window management code: property fetching, stacking, etc, etc. Do you use standard X.org functions for this or do you communicate directly with metacity? Ideally, unless the former functions are broken, it would be nice to use them as they work with any window manager. - The Clutter OpenGL scene graph I can say that one chunk of code compiz will need is something to handle the scene graph model. We have plans to implement a clutter backend, but that looks far into the future - we could also have some code to convert between the scene-graph and the vector*matrix system that we use currently. I'm not
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Tue, Mar 24, 2009 at 8:18 AM, Johannes Schmid j...@jsschmid.de wrote: Hi! 2) Mutter could be renamed as a project to mutter (binary, GConf schemas, etc. Presumably, the internals would stay Meta*) and imported into GNOME version control independently of metacity. The uncomposited and RENDER code paths would gradually be removed leaving just a Clutter based WM/CM. The main disadvantage of this approach is that any ongoing maintenance of Metacity would not feed from or to this project automatically. Actually I am bit in favor of this approach. Having the window manager and the shell separated has the advantage that they can be used independently. Think about things like Gnome Mobile or Netbooks - probably you want a composited wm here but you don't want GNOME Shell (but probably another shell that is based on a mutter-plugin). Definitely. If the WM and the shell were integrated, it would mean that a severe chunk of functionality would be lost when using other window managers like compiz with GNOME. It's totally possible to separate the shell and the WM and instead abstract calls to the WM with DBUS. That way compiz can have a plugin to support functionality required by gnome-shell. I also like that mutter would only keep that code that is based on clutter. The RENDER stuff is mostly taken care of by compiz and metacity is for non-composited Desktops. All three have their use-cases. Compiz never used RENDER and has always been a traditionally OpenGL compositing manager. While there is support to add a RENDER backend in compiz (it is one of our goals), the likelyhood is that it would not support the majority of our functionality. That said, besides testing from time to time (which is restricted by the state of current open-source api drivers vs. bad performance on my intel-graphik netbook) I am not very involved in gnome-shell development. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Sam Spilsbury ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Tue, 2009-03-24 at 00:18 +0100, Johannes Schmid wrote: Hi! 2) Mutter could be renamed as a project to mutter (binary, GConf schemas, etc. Presumably, the internals would stay Meta*) and imported into GNOME version control independently of metacity. The uncomposited and RENDER code paths would gradually be removed leaving just a Clutter based WM/CM. The main disadvantage of this approach is that any ongoing maintenance of Metacity would not feed from or to this project automatically. Actually I am bit in favor of this approach. Having the window manager and the shell separated has the advantage that they can be used independently. Think about things like Gnome Mobile or Netbooks - probably you want a composited wm here but you don't want GNOME Shell (but probably another shell that is based on a mutter-plugin). In my mind, the Javascript + gobject-introspection approach is the right way to go for all of these use cases. Just use different Javascript. Resource consumption is not significantly higher than with a C-based plugin, and it's much easier to achieve the customization at that level. But that being said, there is current development with Mutter (what Mutter was originally written for) that don't use Javascript and gobject-introspection. Respecting that and not creating a fork is why this option seems like the appropriate choice at the moment. I also like that mutter would only keep that code that is based on clutter. The RENDER stuff is mostly taken care of by compiz and metacity is for non-composited Desktops. All three have their use-cases. (Actually, compiz is GL-based like Mutter/gnome-shell.) - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Tue, 2009-03-24 at 16:17 +0900, Sam Spilsbury wrote: On Tue, Mar 24, 2009 at 8:18 AM, Johannes Schmid j...@jsschmid.de wrote: Hi! 2) Mutter could be renamed as a project to mutter (binary, GConf schemas, etc. Presumably, the internals would stay Meta*) and imported into GNOME version control independently of metacity. The uncomposited and RENDER code paths would gradually be removed leaving just a Clutter based WM/CM. The main disadvantage of this approach is that any ongoing maintenance of Metacity would not feed from or to this project automatically. Actually I am bit in favor of this approach. Having the window manager and the shell separated has the advantage that they can be used independently. Think about things like Gnome Mobile or Netbooks - probably you want a composited wm here but you don't want GNOME Shell (but probably another shell that is based on a mutter-plugin). Definitely. If the WM and the shell were integrated, it would mean that a severe chunk of functionality would be lost when using other window managers like compiz with GNOME. It's totally possible to separate the shell and the WM and instead abstract calls to the WM with DBUS. That way compiz can have a plugin to support functionality required by gnome-shell. To try and make GNOME Shell integrate with multiple window managers would either greatly constrain the user interface vision or greatly increase the amount of work involved. The power of the GNOME shell approach is that we are working within the desktop scene graph of the window manager/compositor. Using Compiz to create a GNOME desktop using GNOME applications, the GNOME control-center, and so forth will of course remain possible. We have no current plans to create hard dependencies on GNOME Shell within the GNOME desktop (just as there are no hard dependencies on gnome-panel now.) - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On 03/24/2009 08:47 AM, Owen Taylor wrote: Using Compiz to create a GNOME desktop using GNOME applications, the GNOME control-center, and so forth will of course remain possible. We have no current plans to create hard dependencies on GNOME Shell within the GNOME desktop (just as there are no hard dependencies on gnome-panel now.) Yeah, but I can still use gnome-panel in compiz. I understand the reasoning here, and don't have any suggestions or anything, but it's a bit disappointing that the new desktop experience will be so tied to the window manager. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Tue, 2009-03-24 at 10:28 -0700, Sandy Armstrong wrote: On 03/24/2009 08:47 AM, Owen Taylor wrote: Using Compiz to create a GNOME desktop using GNOME applications, the GNOME control-center, and so forth will of course remain possible. We have no current plans to create hard dependencies on GNOME Shell within the GNOME desktop (just as there are no hard dependencies on gnome-panel now.) Yeah, but I can still use gnome-panel in compiz. I understand the reasoning here, and don't have any suggestions or anything, but it's a bit disappointing that the new desktop experience will be so tied to the window manager. Asking to leave all the compiz goodness will be a tough sell :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Tue, Mar 24, 2009 at 12:33 PM, Xavier Bestel xavier.bes...@free.fr wrote: On Tue, 2009-03-24 at 10:28 -0700, Sandy Armstrong wrote: On 03/24/2009 08:47 AM, Owen Taylor wrote: Using Compiz to create a GNOME desktop using GNOME applications, the GNOME control-center, and so forth will of course remain possible. We have no current plans to create hard dependencies on GNOME Shell within the GNOME desktop (just as there are no hard dependencies on gnome-panel now.) Yeah, but I can still use gnome-panel in compiz. I understand the reasoning here, and don't have any suggestions or anything, but it's a bit disappointing that the new desktop experience will be so tied to the window manager. Asking to leave all the compiz goodness will be a tough sell :) There is nothing good about compiz other than as a spectacle and general proof of concept. It has myriad application compatibility issues and configuring it is a usability nightmare. It tried to be desktop agnostic, so now it has four configuation backends and three window decorators--all of which are half-baked. The community around it very nearly died about a month ago. I would encourage you to try gnome-shell before you lament compiz. You'll see that already it is quite functional and there's lots of bling for those who care about such things. And since it's based on Metacity, all the app. compatibility bugs in compiz are gone. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Tue, 2009-03-24 at 18:33 +0100, Xavier Bestel wrote: On Tue, 2009-03-24 at 10:28 -0700, Sandy Armstrong wrote: On 03/24/2009 08:47 AM, Owen Taylor wrote: Using Compiz to create a GNOME desktop using GNOME applications, the GNOME control-center, and so forth will of course remain possible. We have no current plans to create hard dependencies on GNOME Shell within the GNOME desktop (just as there are no hard dependencies on gnome-panel now.) Yeah, but I can still use gnome-panel in compiz. I understand the reasoning here, and don't have any suggestions or anything, but it's a bit disappointing that the new desktop experience will be so tied to the window manager. Asking to leave all the compiz goodness will be a tough sell :) What in particular would you miss? We're not looking to take goodness away from you, we are looking to replace it with better goodness (*). - Owen (*) Better here means, in particular, better integrated with GNOME. Hopefully more concentrated on consistent design and usability. Probably not quite as pretty, at least initially. Though there's no inherent reason we can't match Compiz bling for bling; we have access to the same hardware capabilities and a better programming environment. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Tue, 2009-03-24 at 12:46 -0500, Jason D. Clinton wrote: There is nothing good about compiz other than as a spectacle and general proof of concept. Eh, for now compiz is working and is the reference WM for linux (and more). gnome-shell would be the proof of concept :) It has myriad application compatibility issues and configuring it is a usability nightmare. It tried to be desktop agnostic, so now it has four configuation backends and three window decorators--all of which are half-baked. The community around it very nearly died about a month ago. True, but all of this would be implementation details, sort-of. I would encourage you to try gnome-shell before you lament compiz. You'll see that already it is quite functional and there's lots of bling for those who care about such things. And since it's based on Metacity, all the app. compatibility bugs in compiz are gone. The problem isn't just with me - who cares ? After a few linux installs I can reasonably say compiz is addictive for newcomers, and these people don't care about configuration or backends or community behind the product (yet). But I don't want to sound negative or start a flamewar at all. I'll try gnome-shell if it's not too time-consuming, instead of babbling. Thanks, Xav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On 03/24/2009 11:30 AM, Xavier Bestel wrote: On Tue, 2009-03-24 at 13:53 -0400, Owen Taylor wrote: On Tue, 2009-03-24 at 18:33 +0100, Xavier Bestel wrote: On Tue, 2009-03-24 at 10:28 -0700, Sandy Armstrong wrote: On 03/24/2009 08:47 AM, Owen Taylor wrote: Using Compiz to create a GNOME desktop using GNOME applications, the GNOME control-center, and so forth will of course remain possible. We have no current plans to create hard dependencies on GNOME Shell within the GNOME desktop (just as there are no hard dependencies on gnome-panel now.) Yeah, but I can still use gnome-panel in compiz. I understand the reasoning here, and don't have any suggestions or anything, but it's a bit disappointing that the new desktop experience will be so tied to the window manager. Asking to leave all the compiz goodness will be a tough sell :) What in particular would you miss? We're not looking to take goodness away from you, we are looking to replace it with better goodness (*). - Owen (*) Better here means, in particular, better integrated with GNOME. Hopefully more concentrated on consistent design and usability. Probably not quite as pretty, at least initially. Though there's no inherent reason we can't match Compiz bling for bling; we have access to the same hardware capabilities and a better programming environment. Admittedly I never tried gnome-shell. When I first tried compiz, I found the bling really just that: bling. I used it for a while, then came back to metacity - oh the horror ! Once you're accustomed to wobbly windows and workspaces-on-a-cube, there's no going back. The feeling of a solid desktop, with tangible windows is true usability, not just eye candy. There's more: non-computer-savvy people can't really grasp the workspace concept with metacity, whereas with compiz's cube (or one of its variants) it's obvious to them. Yes, metacity has a compositor. It's better but still far away. Of course I'm open to other ways to map my mind to the multiple applications running on my desktop, like most. But if gnome-shell feels clunky, if it looses the objects-I-can-touch feeling that compiz has, it's gonna be a tough sell. I agree completely with Xav. I have come to rely greatly on the Scale plugin (like Expose in OS X). There are also several animations that are either helpful directly or at least add to that tangibility Xav describes: * Animations on Window open, close, minimize, and maximize * Animations on appearance and disappearance of menus * Animation when moving a window between desktops I have tried switching to Metacity because I do occasionally experience unrecoverable hangs with Compiz's Scale plugin, but I lose too much productivity. I am looking forward to trying out gnome-shell soon so I can give more specific feedback. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Mon, Mar 23, 2009 at 4:41 PM, Owen Taylor otay...@redhat.com wrote: 2) Mutter could be renamed as a project to mutter (binary, GConf schemas, etc. Presumably, the internals would stay Meta*) and imported into GNOME version control independently of metacity. The uncomposited and RENDER code paths would gradually be removed leaving just a Clutter based WM/CM. The main disadvantage of this approach is that any ongoing maintenance of Metacity would not feed from or to this project automatically. I'd like to toss in here: 4) o Import mutter as a branch of metacity o When built, it installs its binary by default by default as metacity-compositor o We share a common GConf schema subset (even if e.g. compositor has a few more keys) o We share the bugzilla name metacity o Replay some of the non-compositing changes like GObject-ification and introspection support on to mainline to reduce the divergence There are some tradeoffs here, but I'd like to avoid creating a distinct mutter brand and forking the GConf keys, even if the display technology is changing a lot. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Mon, 2009-03-23 at 17:02 -0400, Colin Walters wrote: On Mon, Mar 23, 2009 at 4:41 PM, Owen Taylor otay...@redhat.com wrote: 2) Mutter could be renamed as a project to mutter (binary, GConf schemas, etc. Presumably, the internals would stay Meta*) and imported into GNOME version control independently of metacity. The uncomposited and RENDER code paths would gradually be removed leaving just a Clutter based WM/CM. The main disadvantage of this approach is that any ongoing maintenance of Metacity would not feed from or to this project automatically. I'd like to toss in here: 4) o Import mutter as a branch of metacity o When built, it installs its binary by default by default as metacity-compositor o We share a common GConf schema subset (even if e.g. compositor has a few more keys) o We share the bugzilla name metacity o Replay some of the non-compositing changes like GObject-ification and introspection support on to mainline to reduce the divergence There are some tradeoffs here, but I'd like to avoid creating a distinct mutter brand and forking the GConf keys, even if the display technology is changing a lot. A branch in the (future) Metacity git repository is an interesting idea, in that it allows changes to be moved somewhat more conveniently between the trees. But it could also be confusing, and unless you are going to keep on merging Metacity wholesale into mutter, there's not a big advantage in having them in the same repository. 'git cherry-pick' has no special intelligence over just applying a patch. How would you see packaging and installation working with your scheme? I don't see how different programs (metacity and metacity-clutter) could share the same GConf schema keys. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Mon, Mar 23, 2009 at 5:11 PM, Owen Taylor otay...@redhat.com wrote: But it could also be confusing, and unless you are going to keep on merging Metacity wholesale into mutter, there's not a big advantage in having them in the same repository. 'git cherry-pick' has no special intelligence over just applying a patch. Right, it's mostly a branding thing. How would you see packaging and installation working with your scheme? OS vendors would need to ship separate metacity-compositor packages. metacity-compositor would Depend: metacity. I don't see how different programs (metacity and metacity-clutter) could share the same GConf schema keys. What problems do you see? Basically mutter would depend on the metacity schemas being installed from mainline. Thinking about this a bit more, the end of this path is that the schemas, translations etc. are removed from the compositor branch, and it's really a separate project that depends on metacity installed. It just has a fork of the core code and installs a distinct binary name. Anyways I'm not opposed to any of 1) 2) or 3), I just wanted this option out there on the table to think through. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Mon, 2009-03-23 at 17:23 -0400, Colin Walters wrote: On Mon, Mar 23, 2009 at 5:11 PM, Owen Taylor otay...@redhat.com wrote: But it could also be confusing, and unless you are going to keep on merging Metacity wholesale into mutter, there's not a big advantage in having them in the same repository. 'git cherry-pick' has no special intelligence over just applying a patch. Right, it's mostly a branding thing. In my mind, the brand is GNOME Shell. I don't think we need to brand the bits of GNOME Shell that are written in C separately. metacity-compositor is more descriptive, so probably better for an unbranded component, but I'm not sure enough better to switch back again. How would you see packaging and installation working with your scheme? OS vendors would need to ship separate metacity-compositor packages. metacity-compositor would Depend: metacity. Hmm, from the desktop vendor point of view, that's fine, especially for GNOME-2.28, though I do see more pendantic distros splitting metacity-schemas out of metacity. Not so good for the embedded case. I don't see how different programs (metacity and metacity-clutter) could share the same GConf schema keys. What problems do you see? Basically mutter would depend on the metacity schemas being installed from mainline. The problem I was referring was that two different projects can't install .schemas files with the same keys. If you didn't install the metacity schemas again, that would help. One conceivable problem is that it isn't clear to me that there's going to be a nice split of: A) Shared keys for Metacity and Mutter B) Mutter-specific keys After a while you might get to the point where it was pretty hard to guess what key was where... historical keys would be in one place, more recently added keys in another. Thinking about this a bit more, the end of this path is that the schemas, translations etc. are removed from the compositor branch, and it's really a separate project that depends on metacity installed. It just has a fork of the core code and installs a distinct binary name Splitting translations is going to be much more of a problem than schemas - how would you know if a string in mutter should be marked for translation or not looking at the code base? You wouldn't. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
Hi! 2) Mutter could be renamed as a project to mutter (binary, GConf schemas, etc. Presumably, the internals would stay Meta*) and imported into GNOME version control independently of metacity. The uncomposited and RENDER code paths would gradually be removed leaving just a Clutter based WM/CM. The main disadvantage of this approach is that any ongoing maintenance of Metacity would not feed from or to this project automatically. Actually I am bit in favor of this approach. Having the window manager and the shell separated has the advantage that they can be used independently. Think about things like Gnome Mobile or Netbooks - probably you want a composited wm here but you don't want GNOME Shell (but probably another shell that is based on a mutter-plugin). I also like that mutter would only keep that code that is based on clutter. The RENDER stuff is mostly taken care of by compiz and metacity is for non-composited Desktops. All three have their use-cases. That said, besides testing from time to time (which is restricted by the state of current open-source api drivers vs. bad performance on my intel-graphik netbook) I am not very involved in gnome-shell development. Regards, Johannes signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
