New module for 2.28: gnome-bluetooth
Heya, This is a proposal for gnome-bluetooth to be integrated in the Desktop release for GNOME 2.28 Purpose: Device management for Bluetooth devices Target: Desktop (Linux-only) Dependencies: to achieve a full feature set: nautilus-sendto, BlueZ 4.34 (plus a few patches), obex-data-server, gvfs obexftp backend, obexd (optional) Resource usage: Everything is hosted on the GNOME servers (bugzilla, SVN, source downloads, website), mailing-list is the historical gnome-bluetooth mailing on Edd Dumbhill's servers Adoption: Right now only Fedora, I expect it to replace bluez-gnome in all the distributions for the next versions GNOME-ness: very :) License: GPLv2+ for the applications, LGPLv2+ for the widget library More information at: http://live.gnome.org/GnomeBluetooth Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module for 2.28: gnome-bluetooth
Hi there. On Mon, Apr 6, 2009 at 2:52 PM, Bastien Nocera had...@hadess.net wrote: Heya, This is a proposal for gnome-bluetooth to be integrated in the Desktop release for GNOME 2.28 I rarely write something here, but I feel the need to write some words :). I vote for this great application which fill a gap in the bluetooth area, and seen a lot of improvementS (with a big S) over bluez-gnome (from which gnome-bluetooth originate), and furthermore, it completes the module gnome-user-share which brought Bluetooth sharing (it was accepted in the 2.26 cycle). Oh, and by the way, this module should have its documentation done soon (http://bugzilla.gnome.org/show_bug.cgi?id=575424) so as you expect I give my +1 for this if it matters :) (who said I'm biased ???) Regards -- Baptiste Mille-Mathias Les gens heureux ne sont pas pressés (merci vuntz) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.
Andre Klapper schrieb: Ahoj, a draft for the GNOME 2.27 2.29 schedule is now available at http://live.gnome.org/TwoPointTwentyseven . The schedule also includes a plan to clean up the platform by getting rid of deprecated modules. Maintainers can see the GNOME 3 readiness of their modules on Frederic's awesome status page at http://www.gnome.org/~fpeters/299.html . Comments discussion welcome. I woner what we will do with gnome-canvas? I don't think we should deprecate it without an official alternative and some migration support/guide. Stefan Notes: * 2.30.0 is planned to be 3.0.0, if the QA agrees (For a general GNOME 3 debate, please see other threads like Vincent's recent posting at http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg4.html and http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg5.html ). I don't plan to cover everything+1 in this schedule, it's just that I concentrated on platform streamlining.) * Only two maintenance releases for 2.28.x * Early module freeze for 2.30 * More earlier 2.29.x releases than normally (better testing) * Two weeks hardcode freeze before 2.30.0 - late release at the last day of march 2010 * Still to discuss: dconf vs gconf. This is not yet covered by this plan, but crucial to discuss (as gconf depends on Bonobo) - robtaylor and/or desrt will probably elaborate its current state. * Still to discuss: a11y plan for GNOME3 - see http://live.gnome.org/Accessibility/BonoboDeprecation Already know some 2.28 plans for the module you maintain? Add them to http://live.gnome.org/RoadMap now! andre ___ 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
Eye of GNOME branched for 2.26
Hey! Just wanted to let you know that I branched the stable tree off into the gnome-2-26 branch. trunk will be used for development again. The MaintainersCorner page says I should give a little Roadmap. Well, of course we'd like to get as much done as possible as time permits. ;-) See Claudio's writeup[1] of our FODEM meeting for a few ideas we'd like to focus on in the near future. Regards, Felix [1]: http://mail.gnome.org/archives/eog-list/2009-February/msg7.html ___ 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: Planning for GNOME 3.0
On Fri, 2009-04-03 at 14:31 +0200, Vincent Untz wrote: Le jeudi 02 avril 2009, à 11:44 -0400, Willie Walker a écrit : For developers local to the Boston area, I'm happy to take a visit to your sight to go over accessibility considerations and to discuss your new UI's with you from an accessibility standpoint. I promise to focus solely on accessibility considerations and will avoid general armchair HCI quarterbacking. For those outside the Boston area, we can try to find someone to visit you for a face-to-face and/or we could do conference calls with screenshots or just shared desktops via VNC. Wow, this is an awesome proposal! Note that we can also arrange a special session during GUADEC or the Boston Summit for this if there's interest! +1 from me. I find with accessibility things I tend to guess more than I'd like. I'd really love to know that I'm doing it right. A session which talks about the various issues would be golden. --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: Planning for GNOME 3.0
On Thu, 2009-04-02 at 13:17 +0200, Vincent Untz wrote: There's one obvious question related to those potential changes: what will happen to the old way of doing things? For example, will we still make the GNOME Panel available if, for some reason, people are not immediately happy with GNOME Shell? There's no obvious answer to this, and this will have to be discussed. Some of us believe that it would be a good thing to keep providing the old elements for a limited time, to ease the migration. That being said, doing that would obviously take some development resources and slow down work on what should be the future. Not an easy choice, of course. However, it's worth noting that distributors and other community members using GNOME to build enterprise products will most certainly help maintain the GNOME 2.x shell for quite some time, and the project will support that to the greatest reasonable extent. I'm a little worried that this amounts to forking GNOME. Yeah, they'd all be in the same VCS, etc, etc, but at the end of the day there'd be two different user experiences. Currently, most distros that ship GNOME have it customized in various ways, but you can still spot a GNOME Desktop when you see one. You know it's GNOME. I'm worried that in the GNOME 3.0 world, for various technical and social reasons, that won't be the case. I'm worried that amounts to making GNOME a set of libraries and as recognizable on the Desktop of the Future(tm) as it is in a Nokia Tablet or a Garmin GPS today. --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: GNOME 3.0 Schedule draft; Streamlining of the Platform.
Le lundi 06 avril 2009 à 17:10 +0300, Stefan Kost a écrit : Andre Klapper schrieb: Ahoj, a draft for the GNOME 2.27 2.29 schedule is now available at http://live.gnome.org/TwoPointTwentyseven . The schedule also includes a plan to clean up the platform by getting rid of deprecated modules. Maintainers can see the GNOME 3 readiness of their modules on Frederic's awesome status page at http://www.gnome.org/~fpeters/299.html . Comments discussion welcome. I woner what we will do with gnome-canvas? I don't think we should deprecate it without an official alternative and some migration support/guide. If nothing uses it anymore in the official gnome modules (btw, did something used it?), deprecate it. It is almost unmaintained, AFAIK. Of course, there is no official alternatives, but I don't think there will be one in a foreseeable future. Just defining what it should do will be quite difficult since there seems to be so many divergent opinions among the community. And even if somebody is able to write a multipurpose canvas, it might not fulfill everybody's needs. For my use case, I tested libccc and goocanvas, and in the end it took me less time to write a new widget from scratch with all the features I need and just these. Best regards, Jean Stefan Notes: * 2.30.0 is planned to be 3.0.0, if the QA agrees (For a general GNOME 3 debate, please see other threads like Vincent's recent posting at http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg4.html and http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg5.html ). I don't plan to cover everything+1 in this schedule, it's just that I concentrated on platform streamlining.) * Only two maintenance releases for 2.28.x * Early module freeze for 2.30 * More earlier 2.29.x releases than normally (better testing) * Two weeks hardcode freeze before 2.30.0 - late release at the last day of march 2010 * Still to discuss: dconf vs gconf. This is not yet covered by this plan, but crucial to discuss (as gconf depends on Bonobo) - robtaylor and/or desrt will probably elaborate its current state. * Still to discuss: a11y plan for GNOME3 - see http://live.gnome.org/Accessibility/BonoboDeprecation Already know some 2.28 plans for the module you maintain? Add them to http://live.gnome.org/RoadMap now! andre ___ 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: Planning for GNOME 3.0
On Mon, Apr 6, 2009 at 11:11 AM, Ted Gould t...@gould.cx wrote: On Thu, 2009-04-02 at 13:17 +0200, Vincent Untz wrote: There's one obvious question related to those potential changes: what will happen to the old way of doing things? For example, will we still make the GNOME Panel available if, for some reason, people are not immediately happy with GNOME Shell? There's no obvious answer to this, and this will have to be discussed. Some of us believe that it would be a good thing to keep providing the old elements for a limited time, to ease the migration. That being said, doing that would obviously take some development resources and slow down work on what should be the future. Not an easy choice, of course. However, it's worth noting that distributors and other community members using GNOME to build enterprise products will most certainly help maintain the GNOME 2.x shell for quite some time, and the project will support that to the greatest reasonable extent. I'm a little worried that this amounts to forking GNOME. Yeah, they'd all be in the same VCS, etc, etc, but at the end of the day there'd be two different user experiences. Currently, most distros that ship GNOME have it customized in various ways, but you can still spot a GNOME Desktop when you see one. You know it's GNOME. I'm worried that in the GNOME 3.0 world, for various technical and social reasons, that won't be the case. I'm worried that amounts to making GNOME a set of libraries and as recognizable on the Desktop of the Future(tm) as it is in a Nokia Tablet or a Garmin GPS today. I think there's a point at which owners of vintage hardware understand they will not be targeted for new development any longer. Granted there is hardware that doesn't have accelerated graphics support under GNU/Linux but let's encourage companies to add support by producing rocking software and encouraging users to buy hardware that has support already. Our focus on multiple platforms, especially on mobile ones, will keep us lean and mean so that we aren't encouraging hardware requirement creep. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
2009/4/6 Adam Schreiber sa...@clemson.edu: On Mon, Apr 6, 2009 at 11:11 AM, Ted Gould t...@gould.cx wrote: On Thu, 2009-04-02 at 13:17 +0200, Vincent Untz wrote: There's one obvious question related to those potential changes: what will happen to the old way of doing things? For example, will we still make the GNOME Panel available if, for some reason, people are not immediately happy with GNOME Shell? There's no obvious answer to this, and this will have to be discussed. Some of us believe that it would be a good thing to keep providing the old elements for a limited time, to ease the migration. That being said, doing that would obviously take some development resources and slow down work on what should be the future. Not an easy choice, of course. However, it's worth noting that distributors and other community members using GNOME to build enterprise products will most certainly help maintain the GNOME 2.x shell for quite some time, and the project will support that to the greatest reasonable extent. I'm a little worried that this amounts to forking GNOME. Yeah, they'd all be in the same VCS, etc, etc, but at the end of the day there'd be two different user experiences. Currently, most distros that ship GNOME have it customized in various ways, but you can still spot a GNOME Desktop when you see one. You know it's GNOME. I'm worried that in the GNOME 3.0 world, for various technical and social reasons, that won't be the case. I'm worried that amounts to making GNOME a set of libraries and as recognizable on the Desktop of the Future(tm) as it is in a Nokia Tablet or a Garmin GPS today. I think there's a point at which owners of vintage hardware understand they will not be targeted for new development any longer. Granted there is hardware that doesn't have accelerated graphics support under GNU/Linux but let's encourage companies to add support by producing rocking software and encouraging users to buy hardware that has support already. Our focus on multiple platforms, especially on mobile ones, will keep us lean and mean so that we aren't encouraging hardware requirement creep. This sounds as a good idea to me as well, but I'm afraid reality won't play as we expect. There's going to be some penalty for focusing on a smaller segment of the population and you may very well be underestimating the rate at which that segment will grow. Also, I believe there's much more growth potential in taking the lower end of the market (including the emergent economies) from MS than in competing with Apple for the higher end. Maybe this will change in 10 years, who knows. That said, I truly believe that is strategically crucial for GNOME to invest in alternatives to the traditional desktop, not only Sugar but also stuff like GNOME Shell and Zeitgeist. Regards, Tomeu ___ 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
Gnome 3 and Documentation
Gnome 3 presents us with a wonderful opportunity to get documentation right. I believe documentation will be very important to the success of a new user experience. Furthermore, I believe that we have a rare chance to bring out new documentation with a bang. If we do it right, people will take notice and begin to trust in the documentation again. This email outlines my view on what we need to accomplish and how we can accomplish it. This is based on my years of experience not only with Gnome documentation, but in the commercial publications sector as well. This is a long email. Here's a table of contents: * The Importance of Documentation * What Documentation We Need * Task-Oriented Documentation * It's a Big Job * But Somebody's Got to Do It * Insert Motivational Message Here The Importance of Documentation Nobody reads the documentation anyway. People do, in fact, read good documentation. Well-written, task-oriented documentation can actually be an enjoyable learning experience. What people won't read are interface descriptions. Documentation is sometimes the first exposure users will have to our software. After seeing some marketing blurbs and release notes, many users will browse the documentation to see what the software is really capable of. These users are unlikely to read the documentation in depth, but if the documentation is done right, it can serve as an excellent marketing tool. Good user interfaces shouldn't need documentation. New user interfaces, no matter how well-designed, are scary. Good documentation can help acclimate users to the interface, showing them how they can make effective use of the software to do things they actually care about. Documentation serves as a safety net, making users feel more comfortable and more willing to explore. This only works if users feel they can trust the documentation. Documentation also helps create more experienced users. More experienced users are more likely to continue being users. Casual users are easy to lose. By creating more experienced users, we open the door for more enthusiasts. This, in turn, can help us get more contributors. Experienced writers involved early in the development cycle can help create more user-centric interfaces. By focusing on how to present the interface to users in ways they care about, writers can help discover ways the software itself could be improved. They're like surrogate designers. Remember that the users who complain to us are a very small minority of dissatisfied users. They're the ones we have a chance of keeping. Most users will just silently stop being users when they're stumped. Though most users won't read the documentation before using the software, many will do so before giving up. Our job is not to fail them. What Documentation We Need It's very important that we have a replacement for the aging user guide. A new user guide is our opportunity to showcase what users can get done with our desktop. Without a new user guide, we risk alienating lots of potential users. Application-specific help is, of course, also important. But the reality is that we will have to prioritize some things lower to get anything done at all. Applications that have simple or very traditional interfaces are less important. It is critical that we have developer documentation for any wicked new developer technology we want to promote. We're not just talking about API references here, although those are absolutely important. If we're going to push GJS/Seed as the next big thing, then we need expository documentation that shows first-hand how to use it to get stuff done. The same applies for any other new technologies, including any cool new GTK+ hotness. If we're to change the way documentation is done, then we need to produce a new writing manual and a new style guide. These can safely slip by at most one stable release. If we're exploring new user interface ideas, then we need an updated HIG. I'd say this can slip by a release if we have a draft or development version available by Gnome 3.0. Task-Oriented Documentation To open a file, choose File ▸ Open. Our current documentation reads like stereo instructions. When they have any real information at all, it's either purely descriptive of the interface or a regurgitation of the internal design of the software. The documentation isn't designed to teach anything. We have no plans, so we just pour everything we know into DocBook. Too much information gets in the way of learning. Good documentation starts with good planning. Most people have heard me talk about Mallard, the project I've had in the works for some time now. Mallard is a documentation format designed to support task-oriented
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
